Does OSB 10gR3 Support OCSP and CRL checks?

Seems like a simple question, but like in most things security, the devil is in the details.

The use case here is that a SOAP request made over 2-way SSL is also signed and encrypted. Let's for the sake of maximum complexity, assume that the client certificate at the transport level is different than the signer of the SOAP message.

Can OSB make CRL and OCSP checks for both certificates to ensure the validity of the message?

WebLogic server has a little known security provider called a CertPath Provider. This security provider, like the other security providers, is configured as part of the realm and can be used to extend/configure the security behavior for WebLogic Server. The default CertPath Provider does a lot of thing to ensure the validity of certificates:

From WebLogic Server Documentation

The WebLogic Server CertPath provider also checks the signatures in the chain, ensures that the chain has not expired, and checks that one of the certificates in the chain is issued by one of the trusted CAs configured for the server. If any of these checks fail, the chain is not valid. Finally, the provider checks each certificate’s basic constraints (that is, the ability of the certificate to issue other certificates) to ensure the certificate is in the proper place in the chain.

Well, this is not exactly OCSP or CRL checking. Good, but not the same as those standards. Well wait, WebLogic has another OOTB CertPath provider - the CertificateRegistry. In this provider, you store the list of valid certificates - think of it as a Certificate Allowed List (CAL?). All of this can be managed via WebLogic Console. This is also good, and a workable solution for a small number of certificates, but not quite meeting the requirements.

So, looks like we need to create a custom CertPath provider. The really interesting think about this provider is that it also has to implement the java.security.cert.CertPathBuilderSpi

Really, all the WebLogic CertPath provider is a wrapper around the standard JDK interfaces.

So, the really good news is that starting inJDK 1.5 has built in support of CRL and OCSP checking through its default PKIX provider

This means that even though there is no OOTB OCSP and CRL checking in OSB/WLS OOTB, the custom CertPath provider is just a simple wrapper around an already existing JDK provided implementation.

Like most providers, at runtime the CertPath provider does get passed a ContextHandler - which in the case of an OSB Proxy Service - has all sorts of information about the request and the requestor in it. If you want to get really crazy, you could have different behaviors by resource - for example, different OCSP responders, or different trustedCAs and a per endpoint basis.

The other good news is that Web Services security uses the CertPath provider automatically to validate certificates. By default, SSL does not, but can be simply configured to do so by going to the Advanced tab of the SSL on the server, and set Inbound SSL Validation to Built In SSL Validation and CertPath Validators