# 90 day expiration **URL:** \ **Category:** Feature Requests\ **Created:** [February 23, 2025, 4:38pm UTC](https://community.letsencrypt.org/t/90-day-expiration/234104 "2025-02-23T16:38:01Z")\ **Posts on this page:** 13\ **Page:** 2
**Author:** ![Bruce5051](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bruce5051/32/76576_2.png) [@Bruce5051](https://community.letsencrypt.org/u/Bruce5051)\ **Post date:** [February 24, 2025, 10:01pm UTC](https://community.letsencrypt.org/t/90-day-expiration/234104/21 "2025-02-24T22:01:11Z")
Out of a set of 94 characters each character represents about 6.55 bits of entropy where of a set of 64 characters each character represents about 6.0 bits of entropy and of a set of 32 characters each character represents about 5.0 bits of entropy So yes length is more important than complexity and frequency, still best to keep a nondeterministic method for selecting the next character to be used. ---
**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\ **Post date:** [February 25, 2025, 12:16am UTC](https://community.letsencrypt.org/t/90-day-expiration/234104/22 "2025-02-25T00:16:39Z")
IMHO the discourse about key rotation and security is irrelevant. The keys do not have to be rotated every 90 days by the ACME spec or by LetsEncrypt/ISRG. The 90 day rotation "single use" key is just the default behavior of Certbot and several other popular clients. Nearly every client that I know of supports re-using keys (including Certbot), and Posh-ACME reuses them by default. As others have said - 90 day expiration is important because of deficiencies in the certificate revocation system; the short lived certs will be ever better. You can implement whatever key rotation policies you want, just change clients if yours does not support your preferred security policy. ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [February 25, 2025, 12:24am UTC](https://community.letsencrypt.org/t/90-day-expiration/234104/23 "2025-02-25T00:24:20Z")
I suppose I ask a naïve question, but if a private key is not compromised (i.e. not in the possession of someone who does not legitimately control a domain name or IP address or whatever identifier), for what purpose is revocation? I just don't see how a leaf certificate can be of any functional use to anyone (legitimate or otherwise) without possession of its private key. Am I missing something? To me, this all seems like a key management problem. Perhaps I should phrase it this way: IMO other than meeting some possibly arbitrary and/or esoteric requirements (i.e. clerical error) about date stamps or such, to me the entire "controversy" around revocation comes down to whether or not a private key should be considered "legitimate" for a leaf certificate. ---
**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\ **Post date:** [February 25, 2025, 12:40am UTC](https://community.letsencrypt.org/t/90-day-expiration/234104/24 "2025-02-25T00:40:29Z")
> [@griffin](#): > > I suppose I ask a naïve question, but if a private key is not compromised (i.e. not in the possession of someone who does not legitimately control a domain name or IP address or whatever identifier), for what purpose is revocation? In terms of security and sometimes legal/contractual compliance, Revocation ensures the above can not happen. If you consider the mere existence of an unexpired ancillary certificate a liability and potential security concern, revocation ensures that any backups of a "destroyed" private key are unusable. ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [February 25, 2025, 12:45am UTC](https://community.letsencrypt.org/t/90-day-expiration/234104/25 "2025-02-25T00:45:14Z")
To me that sounds like "potential" key compromise, otherwise said key could simply be used to issue another certificate with the same functional use as the revoked certificate, right? In essence, it sounds like the key is what is being revoked, not the certificate, in a sense. ---
**Author:** ![9peppe](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/9peppe/32/31596_2.png) [@9peppe](https://community.letsencrypt.org/u/9peppe)\ **Post date:** [February 25, 2025, 1:21am UTC](https://community.letsencrypt.org/t/90-day-expiration/234104/26 "2025-02-25T01:21:12Z")
Not all revocations are the same, we like to say it's only ever needed in case of keyCompromise but there's [other](https://wiki.mozilla.org/CA/Revocation_Reasons) possible reasons that invalidate the signature but not the key itself like keyCompromise does. ---
**Author:** ![petercooperjr](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/petercooperjr/32/84698_2.png) [@petercooperjr](https://community.letsencrypt.org/u/petercooperjr)\ **Post date:** [February 25, 2025, 3:14pm UTC](https://community.letsencrypt.org/t/90-day-expiration/234104/27 "2025-02-25T15:14:03Z")
A private key and cert could have been valid at one point, but then the domain/IP gets controlled by another party. So the key isn't "compromised" in the sense that someone else has it, but the holder of the key could in theory intercept packets and spoof to a client that they still control the name, even though they actually no longer do. Other than the subscriber agreement saying that a holder is obligated to revoke once they no longer control the name, there isn't really any technical constraints to stop that sort of thing other than moving to shorter-duration certificates. ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [February 25, 2025, 4:08pm UTC](https://community.letsencrypt.org/t/90-day-expiration/234104/28 "2025-02-25T16:08:22Z")
I forgot about this case. 🤔 Thanks for reminding me. A lifetime greater than zero will still, of course, allow this situation, but at least a shorter lifetime will reduce the window of vulnerability. I wonder how small the window needs to be to determine that revocation is no longer needed. ---
**Author:** ![Nummer378](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/nummer378/32/49862_2.png) [@Nummer378](https://community.letsencrypt.org/u/Nummer378)\ **Post date:** [February 25, 2025, 4:42pm UTC](https://community.letsencrypt.org/t/90-day-expiration/234104/29 "2025-02-25T16:42:48Z")
> [@griffin](#): > > I wonder how small the window needs to be to determine that revocation is no longer needed. I vaguely remember some discussions about this, either here or on mdsp. In an ideal world, a certificate would only be valid for _a single connection_, i.e. it is issued in real time and used as a nonce. Its "validity" would thus be use-constrained and not time-constrained, with its real time of use being only a handful of milliseconds. This provides the best security against compromise. However, this ideal world doesn't scale in the real world: Asking CAs to perform real-time validations for billions of TLS connections per second is just not feasible at all (both in terms of server capacity and latency considerations). Thus, we have to compromise: How much time do you want to allow, before the downsides of a short lifetime outweigh the benefits? Determining this isn't an exact science: These decisions are based mainly on uptime considerations: An admin should have an opportunity to fix an issue. Back in 2015, Mozilla decided that they [do not care about revocation](https://blog.mozilla.org/security/2015/11/23/improving-revocation-ocsp-must-staple-and-short-lived-certificates/) for certificates valid for less than 10 days. Later this was formalized into the shortlived servercert-wg proposal, where discussions resulted in a figure that decided on a 7-day value - which is now what's being used by major root programs. The discussion around the exact value to use, and its implications has been going on since at least 2014: [https://groups.google.com/g/mozilla.dev.security.policy/c/T11up58JkFc/m/Nph-8cFiuEMJ](https://groups.google.com/g/mozilla.dev.security.policy/c/T11up58JkFc/m/Nph-8cFiuEMJ) ---
**Author:** ![FITS](https://avatars.discourse-cdn.com/v4/letter/f/df788c/32.png) [@FITS](https://community.letsencrypt.org/u/FITS)\ **Post date:** [February 25, 2025, 9:46pm UTC](https://community.letsencrypt.org/t/90-day-expiration/234104/31 "2025-02-25T21:46:49Z")
I am not a cryptographer so my apologies if this is a dumb question. Isn't the initial key exchange and authentication the most susceptible phase of the whole process? So by shortening the lifetime you are increasing the risk by adding this step more frequently? ---
**Author:** ![Nummer378](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/nummer378/32/49862_2.png) [@Nummer378](https://community.letsencrypt.org/u/Nummer378)\ **Post date:** [February 25, 2025, 10:32pm UTC](https://community.letsencrypt.org/t/90-day-expiration/234104/32 "2025-02-25T22:32:25Z")
The question isn't dumb, and there is indeed _some_ truth to it. However, it isn't the full picture either. It is true that the handshake (key exchange + authentication) is the fundamental basis on which the second phase (transport encryption+authentication) is built. If the handshake is broken, then you cannot rely on anything else that follows after. However, there is no (direct) relationship between the lifetime of a certificate and the frequency of handshakes. A TLS handshake is usually\* performed every time a new TCP connection is established, e.g. every time the user visits a website they haven't visited in the last few minutes. TLS handshakes are a very common operation anyway, even if your cert is three years valid the full process has to be run every time, to establish fresh cryptographic keys for the subsequent session. Thus the lifetime of the certificate has little to no relevance to the TLS handshake security model. The security model of transport security protocols like TLS is such that the number of handshakes performed has only negligible impact on security. The main thought in cryptographic protocols is that "if you can break one, you can break all". Thus, the security level is held up so high such that the handshake can (ideally) never be broken, therefore it also doesn't matter how many handshakes are executed. There is some mathematical degradation over time, i.e. if you were to theoretically perform 2^128 handshakes you suddenly have a non-negligible probability of secret value collisions, which is a problem. But even if you were to execute 1 quintillion (10^18) handshakes per second, it would take you 780 \* the current age of the universe to reach those numbers - the sun will be long, long gone before you need to worry about these numbers. To sum up, there is no _risk_ (as in, a probability that is relevant over the lifetime of a human being) that would increase. * * * \*Ignoring TLS resumption here, but resumption lifetimes are much smaller than certificate lifetimes and typically also unrelated. ---
**Author:** ![FITS](https://avatars.discourse-cdn.com/v4/letter/f/df788c/32.png) [@FITS](https://community.letsencrypt.org/u/FITS)\ **Post date:** [February 25, 2025, 11:03pm UTC](https://community.letsencrypt.org/t/90-day-expiration/234104/33 "2025-02-25T23:03:54Z")
Thanks for the clarification. ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [March 27, 2025, 11:04pm UTC](https://community.letsencrypt.org/t/90-day-expiration/234104/34 "2025-03-27T23:04:40Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed. [Previous page](https://community.letsencrypt.org/t/90-day-expiration/234104.md?page=1)