• caglararli@hotmail.com
  • 05386281520

practical applications and revoked intermediate/issuing CAs

Çağlar Arlı      -    12 Views

practical applications and revoked intermediate/issuing CAs

My mind has been blown by my learning the last few days...it seems that browser handling of CA CRLs and OCSP checking has so much variation present. I'm experimenting with my own root CA, with intermediate CA, and server certificates (like many others have done in the past).

Today, I'm bothered with the lack of a conclusion resulting from this discussion on revoking intermediate CAs:

What happens when an Intermediate CA is revoked?

Logically (and cryptographically), everything is clear. Chains can be verified signed from the end point all the way to the root. This is all very clear.

Practically, it seems that you can revoke an intermediate CA certificate, and as client OCSP checks only seem to check the server certificate (if at all) and doesn't seem to look at the intermediate CA certificate OCSP response. Subsequently the server certificate will validate, and the browser continues on with it's functions. I verified this through many permutations of certificate bundles and Apache configuration (not with nginx yet) and my root OCSP server was never once consulted on the validity of the intermediate CA.

With current browser configuration, how would an end-user know that an intermediate CA was revoked? As browsers use "master CRL" lists like (OneCRL, CRLite, etc.) published trusted roots and their intermediates would eventually find their way onto the CRLs that are produced by the browser vendors. OCSP checks however, wouldn't provide any indication that the server certificate now has a broken chain.