I'm learning about X509 certs used in client-cert authentication to https endpoints. If I have an OCSP checker (Python script that creates, submits, decodes OCSP responses), do I need to check the not-valid-after date on a client cert?


  • Client makes request to my https endpoint
  • I check the client's certificate CA's OCSP endpoint to see if the cert has been revoked
  • Do I also need to check the client cert dates or does an OCSP revocation occur immediately if the not-valid-after date has been reached?

No. Revocation is an active event, not something that passively or automatically happens. Expiration is passive, though. An expired cert is no longer valid, so there's no need to stick it in a CRL or update OCSP.

If the purpose of your checker is only to parse OCSP, then no, you don't need to check the dates on the cert, because that's not part of OCSP. If the purpose of your checker is to answer the question "is this cert valid?", then you absolutely need to check the validity dates (both start and end).

EDIT: As eckes points out, for your typical client-identification or server-identification cert (or any other kind not used for long-term signatures), once it's expired you can actually take it off revocation lists, which helps keep their size down.

  • 11
    Actually expiration is also a mean to keep revocation lists short. After a cert is expired is does no longer have to be listed in the CRL for this sub-ca. Things are a bit more complicated for signature validation, especially long term signatures like archives or CAs where other trust models and timestamps are needed. But for normal TLS Server certificates no client should trust or check them if outside the validity period. – eckes Feb 16 at 17:54

You MUST check the expiration date first. You can do that locally, without creating a connection to the OCSP server and spending network resources at both your end and OCSP server's end. (And yes, I regularly deal with overloaded OCSP servers.)

And no, an expired certificate is not automatically revoked. In a lot of cases (as in dealing with timestamped signatures) it is important to know if the cert was valid at the very moment of the signature creation, even if it is expired and/or revoked right now. That's why asking the OCSP for an expired cert is a valid action by itself, but the server may answer that the cert is not revoked even if it is expired.


Think about it like this. You go to the grocery store to buy milk. Would you check for recalls on milk to see if the milk is expired? No! You'd just check the expiration date. You know it's expired by the expiration date alone. It's the same case with certificates. You should be checking the date to see if it is expired. If it has not expired then you can see if it's been revoked prematurely.

(This isn't the best metaphor because shoppers wouldn't check for recalls, but I think it helps to illustrate the point.)

  • 1
    Thanks for the explanation. Helps my understanding. – ericOnline Feb 17 at 15:58

TL;DR I would say Yes, expired certificates are considered to be implicitly revoked, though of course that relies on the crypto library correctly doing the expiry check when validating a certificate.

RFC 5280 (X.509 and CRL) section 5 (emphasis mine):

A full and complete CRL lists all unexpired certificates issued by a CA that have been revoked for any reason.

Also RFC 6960 (OCSP) section 4.4.4 (emphasis mine):

An OCSP responder MAY choose to retain revocation information beyond a certificate's expiration.

So once a certificate has reached its Not-After date (aka "the cert is expired"), then you actually can't revoke it because it's illegal to put expired certs on a CRL.

For OCSP, the responder can respond with one of these codes:

   CertStatus ::= CHOICE {
       good        [0]     IMPLICIT NULL,
       revoked     [1]     IMPLICIT RevokedInfo,
       unknown     [2]     IMPLICIT UnknownInfo }

OCSP software may allow you to continue tracking expired certs, but most OCSP responders will likely start giving unknown once a cert has reached its Not-After date.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.