Why Do SSL Certificates Expire?
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

Why Do SSL Certificates Expire?

Expiration Helps SSL Stay Secure, and No, It’s Not a CA Conspiracy.

One of the most common things we hear from our more skeptical customers is, “why do SSL certificates expire? Isn’t it just a Certificate Authority scam so I have to buy a new certificate and they can make more money?”

Granted, that’s not a totally unwarranted comment. After all, installing an SSL certificate year in and year out can be frustrating. And when you look at all those bills, you may be inclined to think that these companies have created one heck of a racket.

But, the reality is that certificate expiration is incredibly important to the security guarantees of SSL—in fact, without expiration, SSL certificates would be useless.

First, let’s understand how SSL certificates expire: Every SSL certificate has a validity period - a date range during which the certificate is valid and can be used to establish secure connections. After that validity period ends, SSL certificates expire. Browsers and other software stop accepting expired certificates and display a warning when you try to use one. It’s similar to how a government ID or credit card expires.

Certificate validity exists because one of the core features of SSL is server authentication. This allows the client (usually your web browser) to know the identity of the server it is connecting to.

SSL Certificates Expire

Our website's SSL Certificate showing the validity range.

Without server authentication, you would not know if you are connecting to the authentic website, or someone else spoofing that site. Believe it or not, that is incredibly easy to do without the protections of SSL.

Checking if a certificate has expired is part of server authentication, and it’s not just to see if some arbitrary date has come and gone.

Getting an SSL certificate from a publicly-trusted Certificate Authority (CA) like Symantec or Comodo requires that you prove ownership of the requested domain by following industry-standard requirements.

These requirements ensure that you cannot get an SSL certificate for a site you do not own (amongst other things). The CA digitally signs your certificate to tell other devices the information contained in it is accurate, and the validity period tells them how long that information can be relied upon.

Just like a government ID or passport, it’s important that the information is occasionally rechecked. Imagine if you never had to get a passport or driver’s license renewed! Many people would still be carrying around IDs with a picture of them from when they were sixteen and much shorter. Using those IDs for accurate identification would be much harder and far less reliable.

Of course, in the world of technology, things move much faster, so SSL certificate expiration is often done every year instead of every decade. Digital identity is also different from real-world identity. Domains change hands all the time, so you wouldn’t want a previous owner holding onto a nearly-forgotten but still valid certificate. That is a situation ripe for mis-use.

SSL certificates don’t just validate a domain name. OV and EV SSL certificates include the name and location of the company that legally owns them. That information can be used to more precisely identify a website, and it’s important that it stays up-to-date.

On the less malicious side, the longer any file is around the more likely it is to get duplicated all over the place and stored insecurely. When we are talking about encryption keys, that is undesirable.

But It Just Expired Yesterday!

Sure, a certificate that has expired a day ago may seem safe to use. You may question what the harm could be. Unfortunately, with SSL certificates, it isn’t so easy to find out. It’s not like you can just give it the ol’ smell test like you would with that suspicious milk in the fridge.

A certificate that has just expired may still be safe to use. But you have no way of knowing if that private key is still being properly protected, if the domain has changed hands since the certificate was issued, etc. Once a certificate expires, CAs are no longer required to publish the revocation status of that certificate, so you can no longer know if that certificate had been revoked or compromised.

It’s simply too difficult to establish a grace period where it’s still safe to use an expired certificate, and doing so would only lead to the measuring stick being moved more and more over time. First, it would be okay if the cert was just one day past expiration, then slowly we would allow two days, then a week, and on and on. There is a reason certificates have a firm validity period, and we should all stick to it.

Encouraging users to ignore, or “click-through” certificate warnings is bad security hygiene, and risks devaluing the meaning of warnings. This, in turn, puts users at risk of ignoring a warning that’s much more dangerous.

So, while it may be a pain to stay on top of all your certificates, do your users (and the internet) a favor and set up a reminder (most SSL providers let you set up email notifications when renewal is approaching) or put it on your calendar.

New Certificates are Agile Certificates

In the world of technology, legacy is a four-letter word. I’m sure we all know some company or network running Windows XP or some other horribly outdated piece of technology. That's because it is very difficult to force people to upgrade, and supporting those old systems is difficult and often creates security vulnerabilities.

A nice side-effect of certificate expiration is that it helps keep SSL practices modern.

Data taken from Mozilla Telemetry.

There was a point where it was possible to get certificates for five years or more. Today, the limit is three years, and the industry may be looking to reduce it even further.

Shorter certificate validity makes it much easier to update security standards. Last year the entire internet migrated to the new SHA-2 signature algorithm. It was a bit bumpy because of those really old 5+ year certificates out there.

From a policy standpoint, long validity periods are a nightmare. From the day a new policy was enacted, you had to wait up to five years for everyone’s current certificate to expire and start following the new standard, and in the meantime, you needed contingency plans on how to handle those that did not. In some cases that meant forcing users to upgrade mid-cycle.

The CA/B Forum is an industry organization which sets best practices and standards for SSL certificate issuance. They are the ones ensuring that new certificates don't continue to use old security measures. One of the goals the CA/B Forum has been working towards is shorter certificate validity. When SSL certificates expire more frequently, it makes it easier to improve security practices.

Now, that’s not to say that SSL expiration solves every problem. A huge number of servers have SSL configurations that would make most system admin’s blush. But, at least expiration keeps one part of our industry up-to-date.

So, next time you are renewing your SSL certificate, remember that it’s ensuring that all the information in your certificate is accurate, proving to clients that you are still the rightful owner of the domain, and keeping your certificate’s security measures up to date.

SSL Expired?

Buy SSL Certificates or Renew Your Certificate Below.

  • The argument presented here is a little bit circular. That is, you’re saying that the certificate becomes insecure because the CA isn’t required to keep it secure. But were they required to keep it secure, then it would be secure.

    So the question is, why aren’t they required to keep it secure longer than a year? A year is a very short time. Sure domains change hands, but if that’s a problem with a 10 year certificate, it’s also a problem with a 1 year certificate.

    • Hi Patrick,

      The part of my argument you are talking about is only one aspect, and it is actually a secondary point. The focus is on the attestation of identity.

      Let me quickly re-explain: When a CA issues you a certificate, they are doing so after confirming you have control over that hostname (we call it “domain control” in the industry). Usually this is done via practical demonstration (answering an email sent to WHO.IS contact, setting up a DNS A Record, etc).

      This domain control is what allows certificates to provide server authentication, one of two key parts of making a secure connection (the other part is encryption). Certificate expiration and lifecycle revolve around making sure server authentication can be reasonably guaranteed. It is the primary reason certificates expire.

      Industry regulations allow a CA to issue a certificate for up to 3 years after completing such a demonstration. So they are not limited to just a single year, but that is the most popular option (usually because customers do not want to commit to a multi-year certificate. For example, they may not know if they website will still be used in 2-3yrs time).

      As you pointed out, domains could change hands much quicker than a year. Which is why some in the industry think the maximum certificate life cycle should be shorter. Overall the trend is that certificate lifecycle is shortening. There was a point where we had 10 year certificates, then 5, then 4. It keeps getting capped as the industry matures and as certificate deployment becomes easier.

      On to your other point…

      Once a certificate expires, a CA has no obligation to continue supporting it. This means certain security measures – like revocation checks – become useless for expired certificates. Yes, you are right that this is sort of circular.

      But following the logic, once a certificate expires, it means a CA no longer has reasonable assurance about the server’s identity, and therefore has no need to provide additional security measures if the main guarantee is broken.

      Note that a CA must provide these services for the entirety of the certificate lifetime – whether that be 90 days or 3 years.

      The point of mentioning this was to explain that a certificate that has expired even a few hours is not safe to use. I felt it was relevant to mention because a common question we get is “what’s the harm in using a certificate that only expired a few days ago?”

      Another reason to have shorter certificate life times is to make it easy for the ecosystems to move forward. With 10 year certificates it becomes a burden to support them for their entire life time. There will be advancements in cryptography and protocol design that will make those certificates obsolete. Having certificates expire frequently makes it much easier to update them and deploy modern features/security.

      Hopefully this clears things up for you! Remember, the most important reason certificate expiration exists is so that the CA can continually provide guarantees about server authentication.

  • Great Article, i was wondering why an expired certificate suddenly gets unsafe to use.
    Revocation is a great Point. Imagine every CA had to store Data on all Certificate ever created and their revocation status. This would cause huge amounts of data to process and store over time.

  • Even if a domain changes hands, you wouldn’t give away your certificate??? This isn’t a valid argument, and I still haven’t heard a single convincing argument for lowering the validity period. 1 second, 1 year, 3 years, 5 years, they are exactly as (in)secure as the protection of their private keys, and that’s all that matters.

  • The SSL’s major design flaw is its arbitrary validity period. Any validity period greater than a millionths of a second is insecure… The extended period of 90 days, a year, ten years is just fooling oneself with the concept of validity. If the technology becomes weak with age than instantly it becomes a security weakness & validity is just mythology.

    Hence we practice this 1 or 2 year non-sense nuisance assumption that we improved security via re-issuing SSLs. What a complete waste of time with this foolishness of using SSL’s. A better technology standard is needed…

Leave a Reply

Your email address will not be published. We will only use your email address to respond to your comment and/or notify you of responses. Required fields are marked *

Captcha *