1

So when i do a tls handshake with the server, it responds with a cert chain which the browser verifies and which ends at a trusted root CA. In this the browser checks if the cert presented by the server is valid or it has expired/revoked.

So my question is , is this done for each cert in the chain ? or just the leaf ? . Also, how does OS impact the behavior of the browser. I read somewhere that in case of EV certificates, OS settings are overriden, while the os can for revocation checking in other cases. I want a bit detailed understanding of how the chain is validated and what exactly does the CA bundle contain ?

2 Answers 2

1

The theory of X.509 is that revocation checks should occur on all certificates -- not only all certificates in the chain, but also for any extra certificate which was needed to validate the revocation information (CRL, OCSP response...), recursively.

Of course, theory and practice match perfectly only in theory. Some systems (browsers, OS...) will do not check at all. Some will check only the leaf. Some will check revocation status for all certificates in the chain (but not for extra certificates, if these happen to be used). Moreover, the systems differ in their behaviour when revocation status cannot be obtained (e.g. CRL download fails, or no CRL/OCSP URL can be located). Moreover, such behaviour also depends on whether the certificate is supposed to be "EV" or not: EV certificates are called such because they result from agreements between CA and browser vendors; browsers display them with a specific graphic code (which supposedly increases user's confidence and trust) on the basis that they also enforce stricter checks, including a whole-chain revocation status check.

See this page for a discussion of issues and solutions about revocation status checks in the Mozilla family of browsers (i.e. Firefox).

Also, remember that revocation status check is, ultimately, a damage containment feature: when a private key is stolen, and the theft is discovered, then the CA can enforce through revocation an "early expiration", which shortens the time window during which the key thief can leverage his indelicacy. In practice, you would be hard pressed to find an actual case where revocation saved the day. As Peter Gutmann says, stricter revocation checks don't actually prevent anything that attackers really do on non-EV certificates (as observed in the wild).

Even when private keys are actually stolen (this does not happen often), the asynchronism which is inherent to revocation handling means that attackers get at least a few hours of free access. The core point is that revocation is reactive: regardless on how often you issue CRL or update OCSP servers, revocation may occur only after the key theft has been discovered and reported to the CA. In practice, when a private key is stolen and used by attackers, the theft is detected because the attackers have setup a fake site which uses the stolen key.

0

It really just depends on the browser you're using, more specifically its implementation of the protocol. The browser usually checks the validity of all certificates in the chain, but I don't think all browsers fail-hard in case of revocation check failure (especially if it's not for the leaf certificate).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .