TLS证书验证优先级疑问：先查信任库还是OCSP/CRL？

Great question! This is a common point of confusion for folks diving deep into TLS, so let's break down the standard flow clearly.

Step 1: Validate the Trust Chain (Check the Trust Store) #

Before even touching OCSP or CRL, your system will first verify that the incoming certificate belongs to a trusted chain of trust. Here's what this involves:

• Start with the end-entity certificate (the one sent by the server you're connecting to).
• Check if it’s directly signed by a root CA certificate in your system’s trust store. If not, use any intermediate CA certificates provided by the server to build a chain that leads up to a trusted root.
• Verify the digital signature of every certificate in the chain using the issuer’s public key.
• Also validate basic certificate attributes: expiration date (is it still within its valid window?), hostname match (does it correspond to the server’s domain?), and key usage flags (is this certificate allowed to be used for TLS server authentication?).

If any part of this step fails—like the chain can’t reach a trusted root, the certificate is expired, or the hostname doesn’t match—the verification process stops immediately, and the TLS handshake fails. OCSP/CRL checks won’t even run at this point.

Step 2: Perform Revocation Checks (OCSP/CRL) #

Only after the entire trust chain is confirmed valid will the system move on to check if the certificate has been revoked. This is where OCSP or CRL comes into play:

• CRL: The system fetches the Certificate Revocation List from the URL specified in the certificate’s CRL Distribution Points extension, then scans the list to see if the certificate’s serial number is marked as revoked.
• OCSP: Instead of downloading a full list, the system sends a targeted request to the OCSP responder URL (found in the certificate’s Authority Information Access extension) asking for the specific status of this certificate.

Which method is prioritized often depends on your system’s configuration (some favor OCSP for faster, targeted checks, others default to CRL), but the critical takeaway is: revocation checks always come after trust chain validation.

Why This Order Makes Sense #

It’s inefficient and unnecessary to check revocation status for a certificate that’s already untrusted, expired, or intended for a different server. Trust chain validation acts as a basic gatekeeper to filter out obviously invalid certificates before spending resources on revocation checks.

内容的提问来源于stack exchange，提问作者korayguney