Why do public certificates expire? | Hacker News Reader

Why do public certificates expire?

A cert is in valid day 0 and day 0 + 1. Why is it valid day 730 but not day 730 + 1?

(No smart-asses, you now what I mean)

From Let's Encrypt:

> 1. They limit damage from key compromise and mis-issuance. Stolen keys and mis-issued certificates are valid for a shorter period of time.

https://letsencrypt.org/2015/11/09/why-90-days.html

---

For the same reason, having different certificates per server, when non-stateful balancing is an option, mitigates the decryption of all the traffic of a particular user on a given period. In other words, an adversary hoarding encrypted traffic has to break more certificates.

From: https://blog.uidrafter.com/isolated-tls-certificate-creation...

“They limit damage from key compromise and miss-issuance. Stolen keys and miss-issued certificates are valid for a shorter period.”

I don’t buy this. Either it is secure day zero and day 10000000 or it is not secure. Why would I trust something day 730 and not day 731? That is basically a two-year period that someone can misuse something. Also, I would guess that more certs are compromised during changes than from actual installations.

Do you agree with the following?

As hardware gets more powerful, the easier it is to break older encryption standards. In other words, the algorithms and their key strength recommendations are related to the computational power available at a given time.

Here is a more complete set of reasons:

Section 5.3 Cryptoperiods

https://csrc.nist.gov/publications/detail/sp/800-57-part-1/r...

1. Limits the amount of information that is available for cryptanalysis to reveal the key (e.g. the number of plaintext and ciphertext pairs encrypted with the key);

2. Limits the amount of exposure if a single key is compromised;

3. Limits the use of a particular algorithm (e.g., to its estimated effective lifetime);

4. Limits the time available for attempts to penetrate physical, procedural, and logical access mechanisms that protect a key from unauthorized disclosure;

5. Limits the period within which information may be compromised by inadvertent disclosure of a cryptographic key to unauthorized entities; and

6. Limits the time available for computationally intensive cryptanalysis.

So, the 2-year rule is a guess-work. Is that the conclusion I should make? There should be a way to remove public CA:s if they are as worthless as they seems to be. I trust my local vaults (which I have to trust anyway) more than a public CA. It seems a bit stupid for two intelligent parties to trust a common moron more than each-others.

Yes, but it's for more than that. For instance, think of design issues with the algorithms. At any rate, 2 years is way too long, change them at least monthly.

===

BTW, I think I see your scenario, are you using TLS for connecting to a database between servers you own? If that's your case, use symmetric encryption instead. e.g., with spiped [1] or some other tunnel.

[1] http://www.tarsnap.com/spiped.html

Privately you can always rotate at any speed or do whatever. Typically fully automated. The Q is about public certs. I never seen a fully automated cert upgrade outside fully manged services.

It's doable with certbot[1] or using other scripts. But I don't recommend it for the reasons explained in the blog post[2] I mentioned in the first comment:

[1] https://github.com/certbot/certbot

[2] https://blog.uidrafter.com/isolated-tls-certificate-creation

Thanks for your input. I appreciate it. Apparently, a bit annoyed yesterday. Had to handle certs in my spare time. :)

I agree about certbot. Worked with a setup that had it in a container in a cluster. Not very secure.

Reply on news.ycombinator.com