Why are SSL certificates valid only from a certain date?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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)

Answer 4

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.

Answer 5

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.