Pros and cons of 90-day certificate lifetimes


[Moderator’s note: If you would like to express your support for longer certificate lifetimes, please ‘like’ (:heart:) this thread rather than posting a +1 comment, per Community Guidlines].

Let’s Encrypt certificates currently have a ninety-day lifetime. Web standards do not require any minimum certificate lifetime. As of 2015, the Baseline Requirements specify a maximum certificate lifetime of 39 months.

The Technical Advisory Board, chose a 90-day certificate lifetime to start with, with an expectation that people will want to auto-renew at the 60-day mark. As with most decisions, it’s possible that the TAB could recommend otherwise in the future: If so, it would be based on balancing pros and cons, and looking at whether the current approach is working well.

We’ve had a previous thread on the topic, which became quite long and unfortunately flame-y. As a reminder: please be agreeable, even when you disagree.

In this thread, let’s build a list of concrete pros and cons of a 90-day ceiling on certificate lifetimes. I’ve tried to summarize the salient, non-rebutted points from the earlier thread.


  • When an attacker compromises a certificate’s private key, they may bypass revocation checks and use that certificate until it expires. Shorter lifetimes decrease the compromise window in situations like Heartbleed.
  • Offering free certificates with a shorter lifetime provides encouragement for operators to automate issuance. Automated issuance decreases accidental expiration, which in turn may reduce warning-blindness in end-users.
  • Let’s Encrypt’s total capacity is bound by its OCSP signing capacity, and LE is required to sign OCSP responses for each certificate until it expires. Shorter expiry period means less overhead for certificates that were issued and then discarded, which in turn means higher total issuance capacity.


  • Automated issuance is not yet supported in lots of popular web servers (Azure and IIS in particular).
  • Common non-HTTPS servers (IRC, mail, VPN) may require a restart to load new certificates. Ninety-day certs mean six server restarts per year instead of one, interrupting long-lived connections more frequently.
  • Automated deployment of renewed certificates to routers, firewalls, and Internet of Things devices is difficult.
  • Some operators choose not to run any automated renewal software on their servers. Manually renewing every 60 days is burdensome.
  • More frequent renewals increase the chance that a renewal may fail repeatedly for 30 days while an operator is unavailable, leading to an outage.
  • The official client’s renewal implementation still needs work.
  • Some people consider encouraging automated issuance and renewal to be scope creep for Let’s Encrypt.

Add your own pros and cons below. As always, please follow the Community Guidelines: be kind, stay on topic, and provide useful feedback. An example of useful feedback: “ISO standard 1337 prohibits unattended server config reloads, and 10,000 websites representing 1M monthly visits are subject to those requirements.” An example of unuseful feedback: “I refuse to use 90-day certificates” or “I agree” (please ‘like’ the thread instead). Examples of inappropriate feedback: “Anyone who uses unattended server reloads is an idiot.”

My web hosting provider won't allow letsencrypt client to be installed
Increase certificate lifetime
It's a Landslide
Increase certificate validity to 6 months
Maximum (and minimum) certificate lifetimes?
Maximum (and minimum) certificate lifetimes?
Extend Certificate lifetime to one year
Extend Certificate lifetime to one year
Certificate is not being generated
CDN Providers who support Let's Encrypt
Avoid Renewal once a month
Wildcard Certificates Coming January 2018
Installing a renewed certificate on hostgator shared server
Organizational Assurance

Two points.

  1. The additional expirations and renewals associated with short lifetime certificates very well may be just as likely to increase accidental expirations.
  2. LE’s objective should be quantity (widespread adoption and deployment of encrypted communications), not behavioral and business policy and process driving.

1a) Effect of accidental expirations is between user and site operator. Should not be an LE driver. I for one want to know when a site operator is not being attentive to their site. It’s a red flag that the site is not being appropriately attended too and it’s condition should not be trusted. People who go warning-blind, that is their problem. Not mine or LE’s.

2a) I view the use of short lifetime certificates to drive automation (customer policy and process) to be inappropriate scope.


There are two sources to look what lifetimes are used in the wild.

  1. Certificate Transparency LOG
  2. Mozilla Telemetry (
    This can be used to look what people currently use for lifetime.

Maybe someone here will “download” the full set of certificates from CT-pilot. There are 10.mio certificate.
This would be around 4gb base64 data.

  1. Then we can filter what certificates are valid
  2. For each FQDN only take the newest.
  3. Create to diagrams:
    a) Number of Certificate x Lifetime in Weeks
    b) Number of (News per Domains (according to public suffix list)) x Lifetime in Weeks
    Then we have an representative list of demanded certificates.


This is true but I don’t think it should be a selling point - It may encourage some users to not fix their servers, which we definitely do want them to do. Maybe the LE client can do a quick version check on the servers it supports and warn about insecure versions? Then again, if it’s automated, users are unlikely to see that…[quote=“tlussnig, post:3, topic:4621, full:true”]
There are two sources to look what lifetimes are used in the wild.1) Certificate Transparency LOG2) Mozilla Telemetry ( can be used to look what people currently use for lifetime.

Maybe someone here will “download” the full set of certificates from CT-pilot. There are 10.mio certificate.This would be around 4gb base64 data.1) Then we can filter what certificates are valid2) For each FQDN only take the newest.3) Create to diagrams:a) Number of Certificate x Lifetime in Weeksb) Number of (News per Domains (according to public suffix list)) x Lifetime in WeeksThen we have an representative list of demanded certificates.

Hasn’t this been done already? I remember some people quoting some figures in the last thread.


I had a suggestion in a previous thread

Why not default to 1yr expiry out of box. But for your automated + installable authentication methods allow the client to auto renew every 60 days. This would allow for

  1. LE client automated methods to auto renew every 60 days. But offer a fallback safeguard if for unforeseen reasons auto renewal fails to run properly. LE client to be coded to only update the web server’s SSL cert, key files if auto renewal succeeds. If auto renewal fails, the SSL cert still has potentially another 10 months max on it. Then you can let the LE clients own auto renewal process to try again in the next 60 days or via user manual intervention.
  2. Users of manual, standalone or webroot authentication methods which don’t have automation at the web server level, will have longer default 1yr expiry and strongly encourage them LE integrators and users to script and code their own auto renewal levels at shorter intervals i.e. every 60 days. This is what I have done with LE webroot authentication integration into my Centmin Mod LEMP stack (nginx) - latest version checks LE SSL cert every 9 days via cron to see if SSL cert expiry date is less than 30 days to go and auto renewals via webroot authentication if <30 days left
  3. This would also maximise adoption of SSL and HTTPS usage which would be one of the goals of Letsencrypt. Folks whose OS and systems work with LE default auto installable authentication methods can easily adopt the default LE client 60 day auto renewals. While folks stuck on manual, standalone or webroot authentication methods have the option of 1yr expiry and if they can, code their own auto renewals at 60 days etc.

Once LE has some production months in use and users are more trusting and comfortable with LE auto renewal every 60 days for auto installed methods of LE client authentication, they will then see the benefits of such. By then, the manual, standalone or webroot authentication method users will also have spurned a variety of ingenius and clever LE integration/clients and they too could take advantage of and script their own auto renewal processes with more confidence in the process. Those folks will by then have a clearer big picture overview of what 3rd party LE clients and integrations are out there as well so one or more of those choices may have auto renewal at shorter intervals too.

Edit: oh had another thought to add, to motivate 3rd party LE client and integrators to also use 60 day auto renewals on base 1yr SSL expiry certs, you could offer to officially list those 3rd party LE client and integrators on your official web site if they offer auto renewals at intervals <= 60 days :smiley:


That exactly contradicts the pros. Why not go for <= 90 day certificates for those who can easily automate the process (the number of people should grow in the near future, hopefully). An easy fix would be to tell the “signer” that one needs a longer expiration time (e.g., by using a different server for that).

I’ve another con: DNSSEC TLSA records need to be updated (here also TTLs have to be considered which makes this process more error prone)


Honestly, supporting both and defaulting to either one of them seems like the best way to solve that kind of thing. Flexible software is often a great thing, and giving users a choice here would encourage adoption of the system.


Please note that fixing a system is only possible after a vulnerability has been known. In case of Heartbleed you couldn’t know if your private key has been exposed and even if you patched as quickly as possible your private key may have been leaked. This doesn’t lead to people not fixing their servers, but reducing the damage in case of a second Heartbleed.


I guess need Letsencrypt to have greater partnership with OpenSSL and LibreSSL and various vendors, Redhat, Debian, Ubuntu, CentOS, Fedora etc for such security notifications ?


I’d like to add an additional concern: availability.

In a case where Let’s Encrypt is unavailable for a prolonged amount of time (say, due to a severe DDoS attack), the sites whose certificates have been issued by Let’s Encrypt are going to be affected.

  • When using revocation lists of some kind, there exist possible technical means for mitigating this issue - such as caching or out-of-band propagation, whether using a current or a new protocol - even when failing closed.
  • When using short-duration reissuance, it is literally not technically possible to mitigate this, as issuance is fully and inevitably dependent on the available of Let’s Encrypt’s infrastructure.

Therefore, the choice to favour short-duration certificates over revocation infastructure could turn out to be a significant single point of failure, especially for services that use HSTS (as every service should), where unavailability of a valid certificate results in what is effectively a total loss of availability.

I do still feel that shorter defaults are a good idea. But if an operator wishes to request a certificate for a longer duration, then that should be possible, for the above reason and all the other cons that have been mentioned.

People do not generally deviate from defaults unless they have a concrete reason, so this should not significantly impact adoption of automation.

EDIT: I also just want to remark that I’m happy that this was picked up by the Let’s Encrypt team. The radio silence on the previous thread had me worry for Let’s Encrypt’s future.


If you consider absolutely everything, I think the proprietors chose an excellent compromise at 90 days.

Especially since the points you mention above may as well serve for the automation to garner better support in those platforms where things are not yet running smooth, and may as well be seen as a pros for this project.

What would be nice to see is an indication of the long term plan and thinking, once the ecosystem is mature.


Goes without saying: For people who want manual updates or longer certs, they have 100+ certification authorities to choose from.


If I’m signing my own bank check, I’ll do it with the minimum expiration, one day, so if I lose I will have no problems, I can re-sign other.

But you’re going to sign a check for me, I prefer that the date is long, if it is one day and I have not received, I will have problems, or have to go back to ask you to do me another.

The same with a $100 bill, if you’ll give me, better not expire, do not worry, I’ll take care not to lose, but if I print, better expire soon.

There is no advantage at all in a short expiry date on the certificates unless you are yourself which signatures.

I think they are excuses, not reasons… the real reason is that they do not want responsibility, or lack the resources to higher expiration.

If indeed it is an advantage for us, and want to help us… given the option of expitación of 90 days or a year.

Note: Although I appreciate it, I do not need anyone educate me on automate task, or as I do my work.


Is there a concern that Let’s Encrypt will hit its maximum capacity during general availability? Are OCSP responses such a burden that a 1-year validity period is technically impossible at LE’s current capacity?


There is actually a flaw in this assumption. Looking at whats in the wild will not be representative of what people have demanded. Commercial CAs give very little flexibility here. Look at any of the major CAs out there - they offer 1,2, or 3 year validity.

Unless you run your own sub CA, like Google, you have to use a 1-3 year cert. While I have not checked your suggested sources, my own educated guess is that 1-year certificates are the most popular, but again, thats not so important.

The only other customers who would be able to control their validity periods are ones who dont mine asking CAs to reduce their validity below a year, but thats quite a luxury as I bet you they would still be charged for the full year each time.

Another pro not mentioned by JSHA is that short lifetimes reduce the work needed to implement new standards. When the SHA-2 migration was announced it posed a huge problem for CAs who had literally hundreds of thousands of certificates that needed to be manually reissued and reinstalled on end-users servers. Even just contacting all those users is a major effort. Same goes for migration from 1024 -> 2048 bit keys. Now the real problematic certs in these situations are the 2+ year certificates, however a 90-day certificate certainly solves the problem.


@jsha You said that LE ist limited because of OCSP signing. I know that it is required that the OCSP response is not longer than around 4 days valid. With 90 Days Lifetime this means around 20 times signing each OCSP response for one certificate. What would happen if you change the policy and say that only the last certificate for an FQDN will be available via OCSP maybe later one per key type. That will more effective limit the number of required signature than if you limit the lifetime. Also it would force that the user will take more care what they do with their certificates.
This will limit the same as if you say only 4 certificate per 90 days and fqdn.


tlussnig, there is one issue with that idea. In situations where you have multiple servers with the same host (a web farm), you may legitimately want each server to have its own certificate with a unique private key. This would reduce damage if one server is compromised, as you only have to revoke that certificate and none of the other nodes are affected. It’s not a common setup, but it is a legitimate setup that should be considered if you’re going to limit the certificates signed for a single CN.


Remember that a big part of our strategy is to write an API that anyone can implement and interoperate with. We expect lots of people to be implementing that API in the next few months. I personally think the majority of issuances, long-term, will come from hosting providers who have integrated our API. Starting with short certificate issuances means implementers are more likely to emphasize automation, and automation is one of our key principles.

Another pro: both Let’s Encrypt and its Subscribers need to gain operational experience with automated issuance. This is a new thing we are doing, and it will take practice to get good at it. With renewals once a year, it would take many years for the TLS ecosystem, on both sides, to get good at automating issuance. Renewing six times a year gives everyone more practice, and we will get good at it more faster.

Like any good web service, we plan to scale to keep ahead of our growth, and we have a very generous window for the first year or two. But of course, we are a non-profit with limited funds, and highly dependent on ongoing funding in order to grow. And we may very well wind up issuing certificates for a large percentage of the web within a few years. Without going to far off-topic, my main concern when I talk about capacity is making sure that the capacity we have is allocated fairly and not spent on unused certificates, which is a big risk for a free service. There’s a whole other thread to be had here!

Yes, this is definitely an important benefit. As Eric Mill put it, we need to turn issuance and installation from an emergency into the routine. That’s a big part of why Let’s Encrypt cares so deeply about automation.

This isn’t a policy we can change. It’s established by the Baseline Requirements, and for a good reason. If an earlier certificate was revoked due to key compromise, it would be important that clients be able to get that information. And, as @motoko said, some deployments use a unique private key per frontend.


Are you going to revoke certificates that you think are not used?


@jsha As far as i understand the baseline requirement the ca have to sign an positive response every 4 days.
But this is clear because it can revoked after 7 days.
But if an certificate was revoked, i would say the negative answer can be valid for the rest of the cert lifetime.
Because it is not like an physical key there i can say i want to use him again.

I know this leaves the point from @motoko with multiple sides. But with the same automation argument you can say they should automate the key distribution and if one server has an compromised key they should change change all with the same fqdn.

Since i am an java coder and can implement the cert reneval inside the keymanager it is no problem for me.
But there are lot of hosters that provide only webgui for cert deployment to their customers. So i can see why many people like longer duration.