Pros and cons of 90-day certificate lifetimes


From a beginner with Let’s Encrypt:
I have been playing with computers since '72, and it’s still my main activity, and hobby.
I have only 2 domains and a mere 13 sub-domains, one at 4th level. (Nothing compared to a major business.)
I use one domain for small business eCommerce activities.
I use shared hosting on Linux/Apache server with cPanel access.
My host has not enabled LE functionality in cPanel, and likely never will. (It would cut into their own cert sales revenue.)
I also host the majority of the sub-domains on my home computer, also Linux/Apache.
I came into this knowing nothing about certs or openssl, etc.
I have 3 certs from LE covering about half the sub-domains, as well as both domains themselves.
I have not tried to use any clients to automate the cert process, and have not scripted any part of the process.
I used for the original certs, and for the renewal - with HTTP verification in all cases.
I have reorganized, renamed, and scrambled my local server’s config multiple times.
I have read this thread from top to bottom.
The time spent, so far, in getting and configuring my certs, plus what renewals and experiments will likely take for the next two years, is less than the time I spent reading this single thread.
I can boil down everything “important” said, on topic, in this thread to one phase: "I’m too lazy to read."
IMHO 90 days is plenty of time for a cert’s lifetime.
I’m sure there are plenty of “edge” cases that could be found - maybe even my own - where 5-6 manual renewals per year is a PITA, but “manual” isn’t what LE is about.
I will automate, if I ever figure out what I’m doing, but manual wasn’t a PITA for me, a rank tyro, so how could it be any harder for those who claim to know what they are doing?
As many “members” have said herein, I have read nothing to justify the need for a longer lifetime, optional or not, manual or not.
Final though: keep it at 90-day lifetime, for now, and possibly reduce to 30 if the automation and LE’s OCSP signing capacity permit it.

Plan to provide a sub domain for non-technical minded web users to manage the install of SHA-2 Certs

You never know when some stupid update or similar breaks your system. I’ve had updates to SAMBA authentication break my media player. With a, typically, 60-day renewal cycle you’ll have a better chance of finding the break than you would if you waited 365 days to renew.

True – if it’s one person automating for one person. if it’s 50 people automating for 100,000 people, it flips the script in favor of automation. If it’s only a handful (5 if you use my hand,) and 250,000 benefit, then it’s even better. Henry Ford knew that a long time ago.


this is something I can sign off. if you can automate, and do so easily, well

well if you use the site yourself, you will find it out anyway. and if you automate the hell out of it it may become a “I wont touch this ever again” system at some places, you know how sadly sometimes IT really runs on a “never change your running system” way. while if you do your renewal manually once a year those ppl may at least think about updating their systems when they are at it anyway.


I would like to point out (what we consider) a MAJOR concern with the short lifetime of these certificates. Recently, Mozilla released a web vulnerability tool called “Observatory”.

One of the recommended security options they tell you to include is called HPKP or public key pinning.

The issue here is this, the “Key Pin” is related to the active cert for a domain and MUST be regenerated at every renewal. Now, we implemented this on a recommendation from our security scanning firm, but having to regenerate these pins at every single renewal involves too much hands on work to justify (And since this key has to be added to httpd.conf for each host every time a cert is renewed, and that in itself requires an apache restart, that step really doesn’t seem to be a candidate for automation)

Doing this once a year (Or really, even once every several years) is a lot more reasonable than allotting time every three months. I wish you would allow users like us to choose how long registration will be for (similar to pretty much every other certificate issuer out there). That way the people who WANT to use shorter lifetimes can, while people who desire to not have this restriction can also go about their business as usual. Just my two cents.


And that’s not everything. Wuth having to change the key every less than 90 days that again means you need to have very short pins (if you are going for auto renewal every 60 days then it’s even shorter) and you pretty much always need the next key online on the machine sobit can do the renewal.
When you can do it yourself like every year, you could safely store the next key offline and/or encrypted for more safety making the pin more secure. Also with such short pins they hardly help rarely visiting people.

But instead of hpkp i woild think tlsa with the “still validate the ca” flag would be better (if it would be supported) because in a worst case you just change the records and don’t have to keep the site down for the rest of the pin’s life.

Just my 2 certs…


HPKP works, as the name indicates, on the public key level, rather than pinning to a specific certificate. It is perfectly acceptable to reuse the same key across multiple renewals. certbot just happens to generate a new key for each renewal by default, as that’s the best choice for anyone not using HPKP (which is the large majority of users). If you’d like to reuse the same key, you can do that using the --csr flag or with one of the other ACME clients. certbot will likely gain a flag to reuse the key during normal (i.e. no --csr) operations in a future release as well, making this even easier.

More details on HPKP and Let’s Encrypt can be found here:


As @pfg has already pointed out, it isn’t the certificate that’s pinned, but the public key (or, more precisely, a hash of the public key), and it’s certainly possible to reuse the same keypair across multiple certificates. Further, it isn’t required (and, in fact, it tends to be discouraged) to pin your “leaf” public key as the only option. It’s often recommend to pin the public key of your CA, and often of a potential backup CA, instead; this will completely avoid the problem you mention.


Only if you’re pinning the public key of your leaf certificate(s). You don’t need to do this, and there are some fairly strong reasons not to (one of which being exactly what you mention). You can also, or instead, pin public keys of your intermediate or root CA.


unless you just so happened to pin for exammple startcom as primary and wosign as backup.

well for intermediate certificates, see them changed, maybe even with a new key -> you’re screwed and even roots wont help when CAs see oblivion, like startssl and wosign. and this is the part where TLSA with PKIX-EE: Service Certificate Constraint mode, in other words the key (or certificate, depending on what you like) must match and the cert must pass CA validation.
the other good thing is, in case of a worst case you can just switch out the records and everything is fine.
and since TLSA runs on DNSSec you can forget manipulation.
sadly TLSA isnt widely supported yet (it really should be, though)


Then you’ve created a different problem. You’ve still avoided the problem @jakepogo mentions (which isn’t true anyway). But the points you raise really go to the question of whether HPKP is really a good idea, not to the relative pros/cons of 90-day certificate lifetimes.


well yeah true, and I think HPKP is a bad idea because there’s no way back.


Ah Yes it seems I must have skipped over the --csr flag at renewal while I was looking at this. Thank you guys you’re a lifesaver!


I personnaly use EE TLSA, storing the sha512 of the cert in a TLSA record and I have an auto renewal scrip that :
1 renew the certificae
2 publish it in the DNS zone and delete the hash of expired certificates
3 wait for a TTL of the dns zone
4 make the cert available for softwares
5 restart/reload softwares using the certificate

It work perfectly fine for more than a year now.

Automation is, has repeated over and over in this thread the key.


well be careful which EE you use, PXIX-EE still requires CA test, and DANE-EE doesnt.

split this topic #453

3 posts were split to a new topic: Java keystore automated renewal challenges


Sorry about the lack of a response for so long. I stopped playing around with certbot and LE for a while because I had other priorities.

I misspoke, and misspoke badly. I have thought about it, and the problem I have is not necessarily the lack of support for automation, but rather, whether or not tools already exist to automate the process for a given server.

And I realized that I have a (possibly unique) situation, and I’m going to have to create my own tools to automate everything. I have a VPS dedicated to running certbot. I have several other VPSes running web servers. Mostly Apache on Ubuntu, but there is at least one running Jetty on Ubuntu – it’s a Java-powered servlet container, so one of the tasks I need to automate is importing the cert into a keystore that the server will read… and then, there’s the one Windows VPS I run, which runs IIS. I want to do all of the certificate management on the certbot VPS and have the web servers rsync the certs over SSH and install them, and restart the web server.

Also, I want to use DNS challenges to validate my certificates. That will require me to create a tool that is able to interface with the DNS Made Easy API, since there are (as far as I can tell) no such tools in existence yet. Most of my scripts will only be useful to me, but once I get the DNS Made Easy scripts written and tested, I plan to stick them on Github so other people can use them.


Also, I’m using certbot now, but I am not sure whether I’m going to continue using it.


@stevesobol I’m slightly biased (having written GetSSL ) but it was designed to do virtually exactly what you want (run on one server, and copy the certs to other servers). Also have a look at some of the other alternative clients


Will definitely check it out…


I was wondering just that - you might be better off with @Neilpang’s or @serverco’s GetSSL.

I’m using Certbot, but my setup is far simpler than yours. Also, Certbot is dependency-heavy, and prone to breakage when a dependency is either not upgraded enough, or upgraded too far. That’s broken my config a few times.

Also, Certbot requires root, whereas other clients can run as an unprivileged user without issues. You might find you don’t need to have the Let’s Encrypt client run in it’s own VPS in the first place.

Good luck! I’m really happy to hear your willingness to share any scripts you write :slight_smile: