8 ms·

I have always wondered a bit what is the purpose of expiration dates. For certificates or GPG keys alike. Once they expire it often enough creates some problems

I have always wondered a bit what is the purpose of expiration dates. For certificates or GPG keys alike. Once they expire it often enough creates some problems. Either because renewal has just been forgotten or because there are some technical issues, like in the Let's Encrypt / Android case. If you have a security incident you can't wait for the expiration date anyway, you need to revoke. And hopefully users have a mechanism to note the revocation in time. So expiration dates help to avoid using weak algorithms forever. But does that need to be done on a fixed date per certificate? Wouldn't that be a more gradual approach in the libraries? And of course they are not updated they get less secure as time goes by. And sooner or later compatibility issues will do the job. E. g. most Nokia Symbian phones don't do https any more, because all they can handle is SHA-1 certificate signatures. That was a gradual decline in functionality.

_jal 6y ago
Things are moving in the other direction. Browser vendors have forced certificates used for browsers to a max life of 398 days. There are multiple reasons, but you seem focused on the certificate management side. One advantage of doing things more frequently is they are forced to become more routine or automated. So shorter expirations should actually make expiration failures less likely over time. Of course the transition sucks.
- tialaramex 6y ago
  Apple eventually clarified, and other root trust stores followed, by making longer-lived new certificates a policy violation rather than just not working on a Mac / iPhone. That's a meaningful distinction. Certificates which lack SCTs (the proof that they were shown to Certificate Transparency logs before you) don't work in some popular browsers, but those certificates are not policy violations, they just don't work in browsers so you probably should not use them on a web site. In a handful of cases such certificates exist for legacy reasons (e.g. industrial environment that doesn't know anything about the "Web"), in other cases they're minted but not intended to be seen yet, for example Google's front end facing systems can do this. When Google accidentally made some of those certificates live with insufficient SCTs they just did not work in Chrome - which is embarrassing but it was not a policy violation, the subsequent root cause analysis was Google's choice not mandated by the other root trust stores and there was no threat that anybody's trust would get revoked.
- thayne 6y ago
  That lifetime is for domain certificates. CA certificates, which is what matters for the Let's Encrypt issue have much longer lifetimes, like 10 years.
krupan 6y ago
I had a co-worker who was pushing for certs that were only valid for a day, or for hours or even minutes. It would solve the whole problem of revocation.
- dotancohen 6y ago
  Is he not aware of OCSP Stapling? It's very much a solved issue, as the same CA authorization can be presented to multiple clients.
- t0astbread 6y ago
  You have to draw the line somewhere. Daily certs would probably increase the load for CAs by a lot. Also, energy consumption for certificate management would increase.
  - easton 6y ago
    How compute intensive is a CA, anyway? I’d think that a few Raspberry Pi-ish devices would be enough to do it for an entire enterprise (or maybe even one, but fault tolerance).
    - t0astbread 6y ago
      In general I would assume when you shorten certificate validity from 90-ish days to one the computational resources required for issuance will increase to about 90x of what it was before. So it would be a lot more expensive to run. Also, unrelated to that argument but I think the most expensive part in a CA is not issuance but rather OCSP since an OCSP query could happen with every TLS connection (although stapling exists to solve that). OCSP would not be affected by a shortening of validity periods.
- algesten 6y ago
  When I've implemented JWT in the past (yes, I know, "don't use JWT"), I've opted for public/private signatures. The public cert I would publish on some URL for all consumers of the JWT to use. The rotation of certs there was a matter of hours. It would hold 3-4 of the last certs (depending on JWT lifetime).
necheffa 6y ago
In order to revoke a certificate, you first must at least suspect it has been compromised. An expiration date can help limit the impact of compromises you don't suspect.
- segfaultbuserr 6y ago
  It's also important to see that the SSL/TLS system does not allow you to revoke a certificate with 100% certainty, the revocation mechanism is flawed - it's often practically impossible to reliably revoke a certificate after someone has compromised your private key. The only feasible workaround is early expiration to reduce the window of vulnerability. * CRL is a list of revoked certificates, it must be downloaded and manually applied to all clients, which only occurs once in a while as a new update, and many hate system updates. The huge lists of revoked certificate have size, performance and scalability problems, currently they are considered obsolete and mainly replaced by OCSP. * In OCSP, clients ask a CA's OCSP server to determine the validity of a certificate. It operates out-of-band from the main TLS connection, and networks and CA servers are not reliable, especially in the early days. Timed out OCSP requests were common. If you are a web browser, you don't want a failed OCSP request to block/DoS HTTPS, thus OCSP becomes essentially "optional". Browsers reject bad certificates when the connection goes through, but if it times out, nothing happens. An attacker can simply block the OCSP server to bypass the revocation check. There's also the problem of privacy - you have to send the name of every website you visit to third party servers. * In OCSP Stapling, the webserver acts like a proxy - it hosts a cached copy of the OCSP response for itself (it cannot be forged because it's signed by the CA) and sends it to clients in-band, via normal TLS channel. Because now the client no longer asks CA's OCSP servers for a response, but instead simply asks the webserver itself, it eliminates the problem of third-party OCSP servers, solves the reliability and privacy issues. However, there's nothing to prevent an attacker to run a server with a compromised certificate with OCSP Stapling turned off. * In OCSP Must-Staple, you can get a certificate from a CA that says "you must use OCSP Stapling, otherwise this certificate is null and void." Hence, if a browser sees a certificate with "OCSP Must-Staple" enabled, it must see whether the webserver supports OCSP Stapling, and via OCSP Stapling, the certificate's validity will be determined. If OCSP Stapling is not supported by the webserver, the connection is rejected. Thus, an attacker who uses a compromised certificate has to either disable OCSP Stapling and be rejected, or to enable OCSP Stapling and gets caught. Finally the problem of reliable revocation is solved. But this is an optional feature and is only used by a tiny percentage of sysadmins. Also, it's only supported by webservers and browsers, other TLS-based applications like VPN, FTPS, SMTP, IMAP, XMPP, IRC servers/clients, etc, usually don't support OCSP Stapling at all. Thus, it's often practically impossible to reliably revoke a certificate in SSL/TLS after someone has compromised your private key. The only feasible workaround is early expiration to reduce the window of vulnerability, an unrevokable certificate that expires within 90 days is less dangerous than a zombie certificate that lasts two years.
t0astbread 6y ago
I assume expiration protects against the case where a valid certificate is forgotten and a bad actor gets their hands on it and abuses it without the domain owner noticing. Similar to how some sites enforce session expiration.
- dotancohen 6y ago
  That is beginning to appear to be a very corner case. But we didn't know that when the standards were being written.
  - t0astbread 6y ago
    Maybe because certificates are treated as an ephemeral resource that needs to be managed? If a business had "the certificate" for all its lifetime I imagine it would be easier to forget revocation when it's not needed anymore.
  - stjohnswarts 6y ago
    However lots of corner cases end up being weak points to be hacked if not properly accounted for
vbezhenar 6y ago
You can remove expired certificates from the list of revoked certificates. Without expiration time that list could grow limitless making it impractical.
- Causality1 6y ago
  I know the concept is offensive to us who love optimization and efficiency, but would it actually be impractical, though? A root certificate is a couple of kilobytes. How much space would you need to store every single certificate in history for the next hundred years?
  - anfilt 6y ago
    For root certs probably not too much space, but for all certs.... That depends on the number of certs issued, and more people and things are using TLS and such so it probably be more than just linear growth. 100 Years seems a bit extreme just even look back 20 years for the terms of hardware and such. Also think about how much common MD5 was then and SHA1, both of which are broken for a lot use cases.
    - reaperhulk 6y ago
      A good example of how rapidly a CRL can grow in size is Apple's WWDRCA CRL. Current size: 224MB despite only containing revocations back to Feb 2020. http://developer.apple.com/certificationauthority/wwdrca.crl http://developer.apple.com/certificationauthority/wwdrca.crl
      - Laforet 6y ago
        I chuckled a bit when I clicked on your link and got a browser warning that crl cannot be downloaded securely over http.
      - Dylan16807 6y ago
        What in the world? Why are there millions of revoked certificates? What is creating all of these?
8organicbits 6y ago
I agree with the sentiment that cert expiry is a frequent cause of outages. I think short lived certs and automated cert management are a better fix versus certs that never expire (for that issue). If you don't have an expiry then you'd need to keep certificate revocations around forever, so your CRL grows without bound. Currently the certificate revocation list can remove expired certificates as clients won't use them. There's also lots of clients that don't check CRLs. Those clients would be forever vulnerable to a stolen certificate if we removed expiry. Imagine if you inherited the infrastructure for a company where the previous admin created certs, lost track of them, and used questionable methods for securing them. I believe you'd struggle to find and revoke every previously issued certificate. The expiry ensures that gets cleaned up, eventually. I don't have a good solution to the Nokia Symbian problem. I suspect if the device only supports SHA-1 then there are other unpatched security issues. Does anyone know if that's the case? If so, this seems more like a support and patching issue.
- usr1106 6y ago
  > I don't have a good solution to the Nokia Symbian problem. I told that mostly as an anecdote. I don't think a solution is really expected. The devices I referred to (made 2005 - 2007) worked rather well for about 10 years. I guess that's a satisfactory achievement.
- thayne 6y ago
  > There's also lots of clients that don't check CRL This is in part due to the difficulty of doing so. On linux at least there is generally not a central location for CRLs, or anything to keep them up to date. Each application is responsible for maintinging CRLs it cares about itself. And then there is the fact that a full set of CRLs is pretty big. OCSP fixes some of that, at the cost of more latency during the TLS handshake. OCSP stapling is probably the best existing solution, but I don't think it is widespread enough that you can rely on it yet.
  - bawolff 6y ago
    OCSP stapling always felt a little hacky to me. It feels like just having super short lived certificates but with extra steps. Why not just have super short lived certificates instesd?
tialaramex 6y ago
For leaves and everything else below a root, the expiration (notAfter in X.509) tells us when the issuer ceases to be responsible for the contained assertion being true. For example take a 90 day Let's Encrypt certificate. When it was issued ISRG had recently (likely seconds earlier) verified that the subscriber apparently had control over all the names listed. Suppose a month later one of the names has been sold to you. You're entitled to have that certificate revoked. Since you control the name, you can just do the Let's Encrypt proof-of-control dance and get it revoked, issue a new one instead, whatever you want. They issue millions of certificates every day, so they don't want to remain indefinitely responsible for the ones from last July, from 2018, and so on. Ninety days later, having expired, ISRG has no opinion about whether the holder of the certificate still controls those names, and if you call that revocation API it will refuse, there isn't anything to revoke because it has expired. Now, if the certificate you're shown is 15 seconds expired, is it so much more likely that it's really because they don't control this name any more than it was a minute earlier? Not really, but we must draw a line in the sand somewhere, or else a 10 year old certificate for "www.microsoft.com" is still valid right? For the root the argument is a bit trickier, after all they could just issue themselves a new certificate with the same keys but a different expiry date - and some root CAs have done this in the past. In this case (for roots) as we see with Android not every system actually enforces expiry. Out of the box OpenSSL doesn't for example I think. But the argument as to why expiry matters for roots goes like this: If we are actively managing the trust store, clearly a trusted CA which wants us to continue trusting them should send us a new or updated root in plenty of time. If they forgot we can hardly have confidence in their other processes. If they decided not to we certainly should cease to trust their root when it expires as this signifies they presumably do not intend to obey policy any more, for this root at least. For example, if you have a Firefox that you just decide not to ever update, I believe it won't enforce expiry of roots. Newer Firefox builds will, like clockwork, remove expired roots entirely. But the old build will continue to trust roots that have notionally expired if you are still running it.
hannob 6y ago
> If you have a security incident you can't wait for the expiration date anyway, you need to revoke. And hopefully users have a mechanism to note the revocation in time. This is the key issue. For a long time there was no working revocation mechanism. With a combination of OCSP, OCSP stapling and the muststaple extension you can get there, but this isn't in widespread use yet. Revocation is a difficult problem.
- iso947 6y ago
  Even then it still relies on knowledge that the certificate has been compromised.
hedora 6y ago
I just always assumed it was like the rest of SSL: It’s well-documented NSA saboteurs infiltrated the standards board. They forced through a bunch of bad proposals with the intention of making it overly complicated. The idea was to encourage misconfiguration and implementation bugs.
- gallegojaime 6y ago
  Where did you read this?
  - vlovich123 6y ago
    He’s referring to the leaks about NSA putting back doors into algorithms that Snowden leaked. Those algorithms were suspect from the beginning and avoided. It’s possible ones have gone undetected but that’s pure speculation without any kind of proof at this time. It’s also wholly irrelevant to this discussion and just pure FUD. Certificate expiration is needed to make certificate revocation perform well. Otherwise you need to keep the list of all certificates ever revoked whereas with expiration you can ignore checking expired certificates and more importantly revocation lists you download can prune certs that are otherwise expired anyway. If anything, now that everything is connected to the internet you want shorter revocations (like days, weeks or months). That way the potential for abuse is shorter and the path for renewal is better trodden by organizations (ie less likely to forget about an expiring cert). [1] https://www.theverge.com/2013/12/20/5231006/nsa-paid-10-million-for-a-back-door-into-rsa-encryption-according-to https://www.theverge.com/2013/12/20/5231006/nsa-paid-10-mill... [2] https://en.m.wikipedia.org/wiki/RSA_BSAFE https://en.m.wikipedia.org/wiki/RSA_BSAFE [3] https://en.m.wikipedia.org/wiki/Bullrun_(decryption_program) https://en.m.wikipedia.org/wiki/Bullrun_(decryption_program)
    - hedora 6y ago
      I wasn’t referring to the cryptosuite weakening. I was referring to unnecessary complexity in the SSL protocol itself, such as the whole certificate chain parsing mess, the countless opportunities to implement things vulnerable to downgrade attacks, and the overly-broad attack surface of the whole thing.
grishka 6y ago
I can understand the purpose behind the expiration dates on the SSL certificates you get issued for your domain — domains change hands, things happen. But why do root certificates have to expire at all? Relying on the system to be updatable and requiring constant maintenance doesn't feel very sustainable, and generally causes all kinds of problems. Modern Android versions treating user-installed root CAs as second-class don't exactly instill confidence either.
fpoling 6y ago
Yet consider if root certificates would expire in max 1 year. That by itself long time ago forced if not the phone vendors but at least app developers to deal with the need to update the root certificate DB. And the LetsEncrypt issue would not exist.
marcosdumay 6y ago
Certificate revoking has a completely different level of reliability from the normal certificate management. There are theoretical flaws that can not be fixed.

_jal 6y ago

Things are moving in the other direction. Browser vendors have forced certificates used for browsers to a max life of 398 days. There are multiple reasons, but you seem focused on the certificate management side. One advantage of doing things more frequently is they are forced to become more routine or automated. So shorter expirations should actually make expiration failures less likely over time. Of course the transition sucks.

tialaramex 6y ago
Apple eventually clarified, and other root trust stores followed, by making longer-lived new certificates a policy violation rather than just not working on a Mac / iPhone. That's a meaningful distinction. Certificates which lack SCTs (the proof that they were shown to Certificate Transparency logs before you) don't work in some popular browsers, but those certificates are not policy violations, they just don't work in browsers so you probably should not use them on a web site. In a handful of cases such certificates exist for legacy reasons (e.g. industrial environment that doesn't know anything about the "Web"), in other cases they're minted but not intended to be seen yet, for example Google's front end facing systems can do this. When Google accidentally made some of those certificates live with insufficient SCTs they just did not work in Chrome - which is embarrassing but it was not a policy violation, the subsequent root cause analysis was Google's choice not mandated by the other root trust stores and there was no threat that anybody's trust would get revoked.
thayne 6y ago
That lifetime is for domain certificates. CA certificates, which is what matters for the Let's Encrypt issue have much longer lifetimes, like 10 years.

krupan 6y ago

I had a co-worker who was pushing for certs that were only valid for a day, or for hours or even minutes. It would solve the whole problem of revocation.

dotancohen 6y ago
Is he not aware of OCSP Stapling? It's very much a solved issue, as the same CA authorization can be presented to multiple clients.
t0astbread 6y ago
You have to draw the line somewhere. Daily certs would probably increase the load for CAs by a lot. Also, energy consumption for certificate management would increase.
- easton 6y ago
  How compute intensive is a CA, anyway? I’d think that a few Raspberry Pi-ish devices would be enough to do it for an entire enterprise (or maybe even one, but fault tolerance).
  - t0astbread 6y ago
    In general I would assume when you shorten certificate validity from 90-ish days to one the computational resources required for issuance will increase to about 90x of what it was before. So it would be a lot more expensive to run. Also, unrelated to that argument but I think the most expensive part in a CA is not issuance but rather OCSP since an OCSP query could happen with every TLS connection (although stapling exists to solve that). OCSP would not be affected by a shortening of validity periods.
algesten 6y ago
When I've implemented JWT in the past (yes, I know, "don't use JWT"), I've opted for public/private signatures. The public cert I would publish on some URL for all consumers of the JWT to use. The rotation of certs there was a matter of hours. It would hold 3-4 of the last certs (depending on JWT lifetime).

necheffa 6y ago

In order to revoke a certificate, you first must at least suspect it has been compromised. An expiration date can help limit the impact of compromises you don't suspect.

segfaultbuserr 6y ago
It's also important to see that the SSL/TLS system does not allow you to revoke a certificate with 100% certainty, the revocation mechanism is flawed - it's often practically impossible to reliably revoke a certificate after someone has compromised your private key. The only feasible workaround is early expiration to reduce the window of vulnerability. * CRL is a list of revoked certificates, it must be downloaded and manually applied to all clients, which only occurs once in a while as a new update, and many hate system updates. The huge lists of revoked certificate have size, performance and scalability problems, currently they are considered obsolete and mainly replaced by OCSP. * In OCSP, clients ask a CA's OCSP server to determine the validity of a certificate. It operates out-of-band from the main TLS connection, and networks and CA servers are not reliable, especially in the early days. Timed out OCSP requests were common. If you are a web browser, you don't want a failed OCSP request to block/DoS HTTPS, thus OCSP becomes essentially "optional". Browsers reject bad certificates when the connection goes through, but if it times out, nothing happens. An attacker can simply block the OCSP server to bypass the revocation check. There's also the problem of privacy - you have to send the name of every website you visit to third party servers. * In OCSP Stapling, the webserver acts like a proxy - it hosts a cached copy of the OCSP response for itself (it cannot be forged because it's signed by the CA) and sends it to clients in-band, via normal TLS channel. Because now the client no longer asks CA's OCSP servers for a response, but instead simply asks the webserver itself, it eliminates the problem of third-party OCSP servers, solves the reliability and privacy issues. However, there's nothing to prevent an attacker to run a server with a compromised certificate with OCSP Stapling turned off. * In OCSP Must-Staple, you can get a certificate from a CA that says "you must use OCSP Stapling, otherwise this certificate is null and void." Hence, if a browser sees a certificate with "OCSP Must-Staple" enabled, it must see whether the webserver supports OCSP Stapling, and via OCSP Stapling, the certificate's validity will be determined. If OCSP Stapling is not supported by the webserver, the connection is rejected. Thus, an attacker who uses a compromised certificate has to either disable OCSP Stapling and be rejected, or to enable OCSP Stapling and gets caught. Finally the problem of reliable revocation is solved. But this is an optional feature and is only used by a tiny percentage of sysadmins. Also, it's only supported by webservers and browsers, other TLS-based applications like VPN, FTPS, SMTP, IMAP, XMPP, IRC servers/clients, etc, usually don't support OCSP Stapling at all. Thus, it's often practically impossible to reliably revoke a certificate in SSL/TLS after someone has compromised your private key. The only feasible workaround is early expiration to reduce the window of vulnerability, an unrevokable certificate that expires within 90 days is less dangerous than a zombie certificate that lasts two years.

t0astbread 6y ago

I assume expiration protects against the case where a valid certificate is forgotten and a bad actor gets their hands on it and abuses it without the domain owner noticing. Similar to how some sites enforce session expiration.

dotancohen 6y ago
That is beginning to appear to be a very corner case. But we didn't know that when the standards were being written.
- t0astbread 6y ago
  Maybe because certificates are treated as an ephemeral resource that needs to be managed? If a business had "the certificate" for all its lifetime I imagine it would be easier to forget revocation when it's not needed anymore.
- stjohnswarts 6y ago
  However lots of corner cases end up being weak points to be hacked if not properly accounted for

vbezhenar 6y ago

You can remove expired certificates from the list of revoked certificates. Without expiration time that list could grow limitless making it impractical.

Causality1 6y ago
I know the concept is offensive to us who love optimization and efficiency, but would it actually be impractical, though? A root certificate is a couple of kilobytes. How much space would you need to store every single certificate in history for the next hundred years?
- anfilt 6y ago
  For root certs probably not too much space, but for all certs.... That depends on the number of certs issued, and more people and things are using TLS and such so it probably be more than just linear growth. 100 Years seems a bit extreme just even look back 20 years for the terms of hardware and such. Also think about how much common MD5 was then and SHA1, both of which are broken for a lot use cases.
  - reaperhulk 6y ago
    A good example of how rapidly a CRL can grow in size is Apple's WWDRCA CRL. Current size: 224MB despite only containing revocations back to Feb 2020. http://developer.apple.com/certificationauthority/wwdrca.crl http://developer.apple.com/certificationauthority/wwdrca.crl
    - Laforet 6y ago
      I chuckled a bit when I clicked on your link and got a browser warning that crl cannot be downloaded securely over http.
    - Dylan16807 6y ago
      What in the world? Why are there millions of revoked certificates? What is creating all of these?

8organicbits 6y ago

I agree with the sentiment that cert expiry is a frequent cause of outages. I think short lived certs and automated cert management are a better fix versus certs that never expire (for that issue). If you don't have an expiry then you'd need to keep certificate revocations around forever, so your CRL grows without bound. Currently the certificate revocation list can remove expired certificates as clients won't use them. There's also lots of clients that don't check CRLs. Those clients would be forever vulnerable to a stolen certificate if we removed expiry. Imagine if you inherited the infrastructure for a company where the previous admin created certs, lost track of them, and used questionable methods for securing them. I believe you'd struggle to find and revoke every previously issued certificate. The expiry ensures that gets cleaned up, eventually. I don't have a good solution to the Nokia Symbian problem. I suspect if the device only supports SHA-1 then there are other unpatched security issues. Does anyone know if that's the case? If so, this seems more like a support and patching issue.

usr1106 6y ago
> I don't have a good solution to the Nokia Symbian problem. I told that mostly as an anecdote. I don't think a solution is really expected. The devices I referred to (made 2005 - 2007) worked rather well for about 10 years. I guess that's a satisfactory achievement.
thayne 6y ago
> There's also lots of clients that don't check CRL This is in part due to the difficulty of doing so. On linux at least there is generally not a central location for CRLs, or anything to keep them up to date. Each application is responsible for maintinging CRLs it cares about itself. And then there is the fact that a full set of CRLs is pretty big. OCSP fixes some of that, at the cost of more latency during the TLS handshake. OCSP stapling is probably the best existing solution, but I don't think it is widespread enough that you can rely on it yet.
- bawolff 6y ago
  OCSP stapling always felt a little hacky to me. It feels like just having super short lived certificates but with extra steps. Why not just have super short lived certificates instesd?

tialaramex 6y ago

For leaves and everything else below a root, the expiration (notAfter in X.509) tells us when the issuer ceases to be responsible for the contained assertion being true. For example take a 90 day Let's Encrypt certificate. When it was issued ISRG had recently (likely seconds earlier) verified that the subscriber apparently had control over all the names listed. Suppose a month later one of the names has been sold to you. You're entitled to have that certificate revoked. Since you control the name, you can just do the Let's Encrypt proof-of-control dance and get it revoked, issue a new one instead, whatever you want. They issue millions of certificates every day, so they don't want to remain indefinitely responsible for the ones from last July, from 2018, and so on. Ninety days later, having expired, ISRG has no opinion about whether the holder of the certificate still controls those names, and if you call that revocation API it will refuse, there isn't anything to revoke because it has expired. Now, if the certificate you're shown is 15 seconds expired, is it so much more likely that it's really because they don't control this name any more than it was a minute earlier? Not really, but we must draw a line in the sand somewhere, or else a 10 year old certificate for "www.microsoft.com" is still valid right? For the root the argument is a bit trickier, after all they could just issue themselves a new certificate with the same keys but a different expiry date - and some root CAs have done this in the past. In this case (for roots) as we see with Android not every system actually enforces expiry. Out of the box OpenSSL doesn't for example I think. But the argument as to why expiry matters for roots goes like this: If we are actively managing the trust store, clearly a trusted CA which wants us to continue trusting them should send us a new or updated root in plenty of time. If they forgot we can hardly have confidence in their other processes. If they decided not to we certainly should cease to trust their root when it expires as this signifies they presumably do not intend to obey policy any more, for this root at least. For example, if you have a Firefox that you just decide not to ever update, I believe it won't enforce expiry of roots. Newer Firefox builds will, like clockwork, remove expired roots entirely. But the old build will continue to trust roots that have notionally expired if you are still running it.

hannob 6y ago

> If you have a security incident you can't wait for the expiration date anyway, you need to revoke. And hopefully users have a mechanism to note the revocation in time. This is the key issue. For a long time there was no working revocation mechanism. With a combination of OCSP, OCSP stapling and the muststaple extension you can get there, but this isn't in widespread use yet. Revocation is a difficult problem.

iso947 6y ago
Even then it still relies on knowledge that the certificate has been compromised.

hedora 6y ago

I just always assumed it was like the rest of SSL: It’s well-documented NSA saboteurs infiltrated the standards board. They forced through a bunch of bad proposals with the intention of making it overly complicated. The idea was to encourage misconfiguration and implementation bugs.

gallegojaime 6y ago
Where did you read this?
- vlovich123 6y ago
  He’s referring to the leaks about NSA putting back doors into algorithms that Snowden leaked. Those algorithms were suspect from the beginning and avoided. It’s possible ones have gone undetected but that’s pure speculation without any kind of proof at this time. It’s also wholly irrelevant to this discussion and just pure FUD. Certificate expiration is needed to make certificate revocation perform well. Otherwise you need to keep the list of all certificates ever revoked whereas with expiration you can ignore checking expired certificates and more importantly revocation lists you download can prune certs that are otherwise expired anyway. If anything, now that everything is connected to the internet you want shorter revocations (like days, weeks or months). That way the potential for abuse is shorter and the path for renewal is better trodden by organizations (ie less likely to forget about an expiring cert). [1] https://www.theverge.com/2013/12/20/5231006/nsa-paid-10-million-for-a-back-door-into-rsa-encryption-according-to https://www.theverge.com/2013/12/20/5231006/nsa-paid-10-mill... [2] https://en.m.wikipedia.org/wiki/RSA_BSAFE https://en.m.wikipedia.org/wiki/RSA_BSAFE [3] https://en.m.wikipedia.org/wiki/Bullrun_(decryption_program) https://en.m.wikipedia.org/wiki/Bullrun_(decryption_program)
  - hedora 6y ago
    I wasn’t referring to the cryptosuite weakening. I was referring to unnecessary complexity in the SSL protocol itself, such as the whole certificate chain parsing mess, the countless opportunities to implement things vulnerable to downgrade attacks, and the overly-broad attack surface of the whole thing.

grishka 6y ago

I can understand the purpose behind the expiration dates on the SSL certificates you get issued for your domain — domains change hands, things happen. But why do root certificates have to expire at all? Relying on the system to be updatable and requiring constant maintenance doesn't feel very sustainable, and generally causes all kinds of problems. Modern Android versions treating user-installed root CAs as second-class don't exactly instill confidence either.

fpoling 6y ago

Yet consider if root certificates would expire in max 1 year. That by itself long time ago forced if not the phone vendors but at least app developers to deal with the need to update the root certificate DB. And the LetsEncrypt issue would not exist.

marcosdumay 6y ago

Certificate revoking has a completely different level of reliability from the normal certificate management. There are theoretical flaws that can not be fixed.