12

In Firefox, if I view the Verisign Universal Root Certificate Authority, I notice that it expires in 2037.

(Settings tab -> advanced -> view certificates -> VeriSign Universal Root Certification Authority -> View.)

Why does it have a lifetime of 23 years?
Why wouldn't they set it to expire earlier? Or later?

Improve this question
1
  • 5
    Like the answer says, to avoid having to replace the root certificate for as long as possible. Someone probably put a 25 or 30 year expiry on it, because it's a pain to have to replace those, and doesn't provide any benefit. Odds are that long before it expires, it'll have to be replaced by one with a longer key (and maybe different crypto algorithm, for that matter). I do the same with our internal SSL certificates, just because I don't want to ever have to install another certificate to $[crappy_printer]. Set the expiry period to longer than the life of the device, and problem solved.
    – HopelessN00b
    Commented Feb 11, 2014 at 20:03

3 Answers 3

Reset to default
14

The expiry was set in 2037 to avoid the possibility of running into the Unix year 2038 date problem. Basically in early 2038 Unix dates will no longer fit in a signed 32bit integer so using a date just before then avoids triggering any code not yet updated to fix the problem.

Root certificates take all chained certificates with them when they expire so from a practical perspective need to expire after any chained certificates.

Improve this answer
7

If I understand your question, replacement root certificates would need to be redeployed to the clients. So odds are, their lifetime is set far enough out where there is little or no chance of the root cert expiring.

Improve this answer
3
  • 4
    As for "Why 2037" (or more broadly "Why not a 100 year expiry time?") -- There may be technical constraints at play, but at least on a recent OpenSSL (0.9.8y, on a 64-bit system) this wasn't an issue so it's probably just "I made it last for ## years")
    – voretaq7
    Commented Feb 11, 2014 at 20:15
  • 1
    @voretaq7 it's not (only) the problem with processing libraries, the problem is that the standard, well tested format for dates before 2038 is using UNIX epoch. If you want to set dates after it you need to use different date format, and it may not be supported by other/older libraries.
    – Hubert Kario
    Commented Feb 11, 2014 at 22:20
  • 1
    @HubertKario Yeah, I recall OpenSSL previously having an "issues" with dates past the Y2038 red line. They appear to have resolved said issues, at least as far as my test case went (I created a cert that expires 100 years from today and it didn't complain) :-)
    – voretaq7
    Commented Feb 11, 2014 at 22:34
0

I've definitely seen 32bit SSL implementations run into the 2038 bug, so that almost certainly accounts for "why 'only' 2037".

As for why not expire sooner? Well, one of the original purposes of expiry was to save a compromised cert being valid for too long - but in all honesty that doesn't gain you a great deal. Now of course we have certificate revocation lists, so we can fairly easily invalidate a cert that's causing us trouble, so there's no real compulsion to have a short time to live.

Improve this answer

You must log in to answer this question.

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