[Moderator’s note: This thread is continued at Pros and cons of 90-day certificate lifetimes. If you’d like to express your support for longer certificate lifetimes, please ‘like’ (
) that thread.]
What will the minimum (such as if I want to explicitly request a short lifetime) and maximum lifetime for certificates be?
At launch all certificates will have a lifetime of exactly 90 days. Post launch we will possibly offer more options, but they will likely be on the shorter side rather than the longer side. Part of the rationale for the 90 day number is that when certs are renewed only once a year, a lot can change. The person in charge might forget how to do it, or leave the organization, or change email addresses, etc. A shorter lifetime will hopefully encourage people to automate the renewal process, and we’ll provide tools to help with that.
Will you allow for requesting much shorter lifetimes for testing?
Not at launch, no. We’re going to be evaluating the approach we want to take to very short lived certificates as we move forward from there.
Wow 90 days! I was hoping for something a bit longer, like in the multiple of years, in fact why does it need to expire at all, wasn’t that just a money making scheme?
This could be a bit of a drag for those of us who want/need to do it manually.
A 90 day lifetime is good in theory, but it will effectively make Let’s Encrypt certificates impossible to use in any environment that cannot (yet) be automated. Also, with such a short lifetime, the automation must be extremely robust and reliable.
Every 90 days a critical process kicks off that could nearly paralyze an organization if something goes wrong. I can already see the disaster on the horizon. In the middle of the night, the certificates expire and the automation fails, taking down the website, the mailserver, the RADIUS server, etc. That admin is going to have a very bad day.
I hope there is a half life technique like in DHCP so that the cert gets renewed BEFORE it expires. And if renewal fails there is plenty of time to resolve the issue BEFORE the current cert expires.
Is certificate renewal something we can automate with the letsencrypt client tool (that sort of defeats the point, doesn’t it?) or will it require manual labor on the part of users?
90d is really, really short. CAcert does 6 months for unverified accounts and even that has been a pain for me.
The default behavior of the Let’s Encrypt client is to automatically renew all certs that it has installed in a server (so not certs obtained in standalone or manual mode, but generally other certs).
There are a couple of reasons for the short lifetime. Our goal is to increase HTTPS usage on the Internet. Part of that goal is decreasing the incidence of avoidable certificate errors, like expiration. Since expiration errors are very commonly caused by human failure, we want to encourage people to automate renewal of their certificates. A ninety day certificate lifetime is a part of that encouragement.
However, for people who still would like to manage certificates manually, I think there is a good argument that a person gets better at a task they have to do six times a year than one they have to do once a year. People are less likely to make mistakes, and more likely to set up reminders and make sure there is backup for when they are on vacation.
@questiontradition: The stock Let’s Encrypt client is configured to attempt renewal at the sixty day mark, with thirty days left before expiry. If it fails, it will send email and the system operator will have a month in which to intervene and correct any problems.
Would like to recommend and request a positive renewal confirmation as well. If a renewal fails, the cause may be common to causing an email notification failure as well. So absence of a confirmation is a heads up that human action is needed to resolve an issue.
And when will it revoke the old certificate?
And what about domain revalidation? Is this done at every renewal (so every 60-90 days) or only once a year e.g.?
And is this completely automated too in this case?
In this case, the old certificate will just be allowed to expire at its original expiration date. The CA will not revoke the prior certificate as a result of the issuance of the new certificate. Revocation is treated as an exceptional case, not a routine case, so it should happen when something bad or improper takes place, or when the client explicitly requests it.
Thanks for the fantastic explanation! This would be good to mention on https://letsencrypt.org/howitworks/ or https://letsencrypt.org/howitworks/technology/.
Certificates need to expire because domains change hands all the time. If certificates did not expire, there would be a huge number of certificates out there controlled by people who no longer owned the domains.
Hmm, couldn’t it be revoked in such situations?
How would you know? The scary thing about the CA trust model is that any CA can issue a certificate for your domain and you will probably never know until it is too late.
Edit: Of course, if you assume a rogue CA, a short validity period will not help you anyway. The point is that there is no way of knowing if any other certificates for your domain exist. At least until everyone implements certificate transparency.
What about issuing certificates for one or two years, but WHOIS lookup the domain to check when the domain is going to expire and let the certificate expire a day before the domain’s expiration if it is shorter than one or two years.
Personally, I think that the 90-day renewal is a great idea. The current renewal process is pretty messed up; people regularly forget to do it. (A Discourse forum just had its certificate expire today, even though I’ve been trying to bug them for the past week.) If we have an automated certificate process, then renewing every 2 months will help make sure that (a) people catch a messed-up configuration before it’s too late, (b) it becomes a routine process.