Thanks for providing LetsEncrypt for free and securing millions of website in the world.
We are using Lets Encrypt for 1000s of customers in our servers. How ever, Very often once the certificate expired after 90 days, the renewal does not happen immediately. Some time it takes 4 hours or 8 hours to renew. During this time customer website is running without SSL.
Can we expire the SSL certificate after 180 days or 360 days ?
Please let me know if this feature is already supported or not.
Is there any work around so that, the certificate expires after long time?
You're renewing improperly--you'd ordinarily renew the cert after about 60 days, not once it expires.
No, Let's Encrypt certs are only valid for 90 days. If there's any change on this, it would be to an even shorter lifetime--there was talk of this early on, but I haven't seen any discussion in the last couple of years.
This is a subject that's gotten a lot of discussion in the past; the canonical topic is probably this one:
See also:
Edit: But it's kind of interesting, browsing through the first of those (5+-year-old) topics and comparing the situation to today. My router supports obtaining certs from Let's Encrypt automatically. So does my NAS. So does my hypervisor. A great deal of server software, in fact, has support for Let's Encrypt built in. My Mikrotik network switch doesn't, but I have a script that automates deployment to that. My 3D printer doesn't, but it's a simple modification. Whatever my concerns about certbot, its renewal features work quite well. For all the complaints there about the automation, it's actually working quite well.
I'm obviously bored this morning, so I'm reading through those old threads. One repeated canard from one user is, "if automation is so important, why not use 24-hour or 48-hour certs?", with the obvious implication that that's a ridiculous suggestion. But the truth is, the same automation that deals with a 90-day cert can handle a 24-hour cert just as well--I set up a local ACME CA on my LAN a few months ago, and the tools I'm using (mainly Caddy and acme.sh) are dealing perfectly well with 24-hour certs.
@danb35 That wouldn't fare well with temporary failures at renewal. As presented in this thread, it sometimes takes a few moments (for various reasons, I dunno, I don't have experience with failing renewals actually) before the renewal actually takes place. Or what about some #)($#()$ DNS providers where it sometimes takes up to 24 hours for the TXT record to propogate world wide?
TL;DR: what works for you might not work for everybody.
The "temporary failure" issue is addressed by attempting the renewal more often than daily, just as Let's Encrypt recommends running the renewal task more often than every 90 days. SmallStep, whose CA software I'm using, recommends running it every 8 hours or so. And as long as your software can do a graceful reload (or integrates cert management like Caddy does), there's no downtime*.
But granted, such a short lifetime could cause problems in many situations, and many of the existing clients don't have any finer granularity for the cert renewal time than in number of days. And, of course, it would represent a much greater load on LE's signing infrastructure (though a correspondingly lower load on their OCSP infrastructure). It was a silly question, but it can still be made to work well with a minimum of effort.
*One of my use cases is for my TrueNAS server, and that actually does require brief downtime--their nginx configuration doesn't handle the request for /.well-known/acme-challenge, so I've had to write a script to replace its config with a bare-bones one, reload nginx, get the cert, replace the config, and reload again. It's a hack, but it still only amounts to about 5 seconds of downtime.
It sounds like your problem is actually not having good reporting around renewals failing (as said above, renewal should be happening well before expiration), which is really unrelated to the length of the certificates. It's something that I am kind of surprised most ACME clients don't seem to handle better; as a lot will just keep on failing over and over (leading to issues like 80% of HTTP-01 challenges failing), and just logging each time somewhere but to a place that nobody seems to be reading.
Don't forget the CT logs, and monitoring sites like crt.sh. Not just in terms of server load, but also data storage storage. (Certs are small, but when there are billions of them it adds up.)
I know no one is really advocating for 24/48 hour cert lifetimes, but any lifetime shortening should probably take all of these into consideration.
Yeah, it does seem like reporting would have gotten more sophisticated. Certify The Web has had a centralised (hosted) dashboard service and failure reporting notifications (by default) for several years but I've not see many others. Of course you can do webhook notifications etc from most of the big clients.