Saturday, February 24. 2018

OCSP (Online Certificate Status Protocol) is a recurring topic of the blog. I am certainly not an expert, but I fear that there are very few people that really know about this protocol deeply so, sometimes, I am just the best suited around. There have been two or three times already that I needed to configure the Apache httpd server to deal with OCSP for verifying client certificates (TLS mutual authentication) and, in almost all of them, I have had issues with the setup. In all the occasions we were trying to remove the CRL (Certificate Revocation List) configuration for another one using OCSP. And it's usually not so easy.

The CRL configuration is mainly managed by the option SSLRevocationCheck since version 2.4 which controls how the openssl is called to perform the verification of the client certificate. This way you can configure to check the CRL only over the final client certificate (leaf) or over all the chain of certificates (root and intermediate CAs and the final certificate). Besides there is a very useful flag to let pass a certificate for which the CRL is not found (no_crl_for_cert_ok option). In general the option for configuring CRL is very complete and let you setup almost any situation.

Nevertheless the OCSP configuration is much less rich. The revocation is enabled with the option SSLOCSPEnable (only on or off values) and then there are more options to locate the URL of the responder to call (options SSLOCSPDefaultResponder and SSLOCSPOverrideResponder let you configure a default OCSP responder in case the certificate does not have the proper extension, you can even override that extension and always call the same responder no matter what the certificate says), dealing with signature responses and timeouts. But none of the options controls when the OCSP verification is done, if you enable it all the chain is always validated (no leaf of no_crl_for_cert_ok equivalents here).

This difference in configuration makes sometimes impossible to change from CRL to OCSP. The first time the issue was that the customer just wanted to validate the certificates that had the OCSP extension in it (it's not possible because if you enable OCSP you need a valid responder, if no one is found the certificate is not validated and that's an error). In the next times the problem was that the OCSP responder was only for final certificates, the intermediate CA has no extension to validate it (CRL or OCSP) and, therefore, the CRL was configured to only check leaf but the same cannot be configured using OCSP (the intermediate CA was validated, unknown returned and the certificate was not admitted). So, in summary, if the configuration for revocation is a bit complex (several CAs, intermediates, different responders, certificates with extensions and without them,...) the OCSP is a understatement.

The last weekend I decided to check how difficult was configuring OCSP exactly in the same way than CRL (none, leaf and chain with a flag no_ocsp_for_cert_ok to allow the certificates that has no responder associated to go in). The modifications finally resulted in just a few lines of code so I decided to submit a bugzilla just to know what the apache guys think about it. With the changes the CRL behavior can be more easily mapped to the OCSP one, at least I think that I would have configured all my failed previous attempts. I do not know how many people is interested in OCSP revocation for client certificates (maybe it's a minor issue) but, if somebody is using it, the changes can be interesting.