Each SSL certificate is valid starting from a specific date and up to the expiration date.

What's the point in that "valid from" date? Why do we want a certificate to only be valid after a specific date?

5 Answers 5


Historically, certificates have a start-of-validity date mostly for symmetry: they have an end-of-validity, so the original designers found it appropriate, for unspecified reasons, to include a start-of-validity date as well.

Nowadays, such dates have found a usage, which is past validation. That's what you do when you verify a signature several months/years after the deed. This is a complicated game with time stamps and projecting yourself in the past. The start-of-validity date then plays an important role (although hard to explain in a few paragraphs).

Of course, past validation is not at all the same context as a SSL connection, but they use the same format for certificates (X.509), and the start-of-validity field must be set. Usual CA set the start-of-validity at a few minutes or hours before the issuance date.


Provided that a CA has strong policies such that an issued certificate is never forward- or back- dated, then:

A certificate issued at the NotBeforeDate cannot have been compromised by vulnerabilities that are known to have been fixed before the NotBeforeDate - a certificate that does not exist during the period of a vulnerability cannot have been compromised by that vulnerability.

Conversely, if the existence of a novel vulnerability is discovered, any certificate issued prior to the discovery of new vulnerability might be regarded as suspect.

In other words, for fixed vulnerabilities the NotBeforeDate allows trust to be granted for certificates issued after the fix date. For discovered vulnerabilities, the NotBeforeDate allows trust to be revoked for certificates issued before the discovery date.

  • Do you have an example of such a vulnerability? If none are publicly known how would one nake a vulnerability so that the defence (or identification) relates to a notBefore?
    – Stof
    Nov 14, 2021 at 21:46
  • 1
    @Stof: the same month this was written (April 2014) the Heartbleed bug in OpenSSL was disclosed, and a huge number of webservers needed to patch their software, generate new keys, and get new certificates; for quite a while thereafter, I saw experts advising not to trust a website if their header indicated use of unpatched software or their certificate (and thus key) was dated earlier than the patch availability. Nov 15, 2021 at 3:47
  • Mentioning heartbleed is not a reference to anything related to the question, and i maintain software that evaluates TLS flaws including heartbleed and would never make such a recommendation because the leaf certificate is completely unrelated to the flaw in openssl. So the question remains, what examples do you have? This seems completely unrelated
    – Stof
    Nov 15, 2021 at 8:17
  • 2
    No, Heartbleed is a perfect example. Prior to Heartbleed being fixed, any webserver that was vulnerable to Heartbleed (which was many) could have had their private key compromised - there was simply no way to determine whether a server had been compromised because there was zero trace in the logs of webservers that it had been. As such, any certificate issued prior to the announcement of HeartBleed needs to be regarded as suspect unless you can rule it out on a case by case basis - for example, you know for a fact, the server software involved was not vulnerable to Heartbleed ever.
    – jonseymour
    Nov 15, 2021 at 10:15
  • You're again explaining an issue with a software, specifically a software rarely used in many "products" with a certificate for TLS and a web server software that is not actually part of any certificate at all because all certificates work exactly the same if that software never existed. You're saying a software bug like that is an example of where a notBefore of a cert is a key element? Its an oxymoron
    – Stof
    Nov 15, 2021 at 21:48

In addition to other valid answers; being able validate at a later date is the main use case, and issuance by a CA in advance is a good strategy because they charge far too much money and as a customer you want to optimise the validity period. The misleading answer ill say that was not a valid use is incident response. When a breach occurs the replacement certificate validity period is irrelevant because the replacement certificate literally didn't exist when the breach occurred, so its irrelevant to a breach and only has relevance afterwards making the netBefore validity date simply mean the same as the above points, you are optimising the validity period by NOT backdating the replacement certificate.

My additional answer not yet covered is the notBefore validity date is a fantastic mechanism for keeping a webserver operational when an existing certificate is about to expire. Serving 2 certificate chains is a valid scenario, 1 will be valid until it's not and then the 2nd chain will be. This allows you to be ahead of certificate expiry outage issues, and not require you to do server deployments specifically only to change a certificate over AND you aren't required to have significant crossover of an existing and replaced certificate (because crossover is wasted money)


Edit: This was poorly written years ago. Please look at the answers suggested above for a more accurate response to the question.

It could have several reason,

  • To check the contract/subscription of the client and CA
  • In case of attack, for resolving it could be useful to find out whether the attacker hijacked the data before having the secure connection or after.
  • Can you be specific about these ideas? If you have experience in these it shouldn't be hard to describe them more clearly on how the notBefore is actually used for these benefits in practice. I've worked extensively with these topics and have no idea what you're talking about so please give more details so we can understand your meaning
    – Stof
    Nov 14, 2021 at 21:44
  • Wow, this was some time ago. @Stof my understanding at the time was very limited and I was trying to answer this based on the courses I had and my own perception of the topic. I'm having a hard time reading it myself now years later :). I'll edit and point to your answer which is far more appropriate.
    – Erfan
    Nov 15, 2021 at 22:27

The certificate is part of a trust chain, so it's important that the certificate on a server isn't getting stolen. A certificate with a start date before a web site is hacked means the hacker could steal that certificate and it must not be trusted.

So you wouldn't want to trust that site until they have properly cleaned up the machine and also replaced the certificate with a new. Because if you are sitting on a network where someone can perform DNS spoofing, you may be redirected to a false machine with the stolen certificate installed.

There are also certificate revocation lists where a potentially stolen certificate can be registered, but it seems not all web site owners are taking that step after they have had their server hacked.

  • CRL is not part of the question, and notBefore on a leaf certificate isn't in any way linked to a CRL. The entire answer is based on the notBefore of an existing certificate that is compromised, but fails to make any point at all how the notBefore is a defence mechanism (because it isn't sobyou can't makebthatbpoint even if you wanted) perhaps try cleaning up your answer to be more on topic and less about your own interests that aren't relevant to the question
    – Stof
    Nov 14, 2021 at 21:40
  • "less about my own interests"? What own interests? It really doesn't matter if the CRL is part of the question or not and does not make my answer wrong. When a server gets hacked, that doesn't automatically mean the certificate will be revoked. But the notBefore is relevant to show if the owner has replaced the certificaste or not. Nov 20, 2021 at 17:17
  • the answer isn't very clear if it is valid you would need to make a more factual link to the notBefore of a leaf certificate somehow being linked to a CRL for your answer to make much sense. I can't see the link you're referring to and the new certificate being issued is also extremely separate from any "hack" not involving a compromise of the previous certificate "issuer" because the TLS system relies on the trust of the issuer (not being hacked) and the 'leaf certificate' itself is public and cannot be "hacked"
    – Stof
    Nov 21, 2021 at 1:30

You must log in to answer this question.

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