@kelunik: Currently LE sends emails when a certificate is close to expiration. Our goal is that it will be smart about which certificates have already been renewed*, and not send unneeded emails, but that’s not yet implemented.
*Had a new certificate issued for the same names, under the same account.
+1 for allowing certificate lifetimes for up to a year.
I’m fine with a default of 90 days, especially for those things that have rock-solid automation capability. Makes sense. However, in the world I live in, there may not be free time available to implement automation, change freezes at inconvenient times, difficulties getting maintenance windows, or there simply isn’t any applicable automation capability.
Or I’m simply too darn busy at work and the gear at home gets ignored.
Part of what the EFF stands for is Freedom (its in the name, last I checked) and that includes freedom of choice within reasonable bounds.
Thank you!
maybe make LE ssl certificates 1yr by default for now and encourage 30 day, 60 day or 90 day auto renewals for testing the renewal process.
You can then add some fall back code for auto renewals.If they fail for whatever reason, they can auto redeploy a backed up copy of the original 1yr expiry ssl certificate as fall back. Or other way round is the new auto newed certificate only comes into play on successful auto renews otherwise the existing 1yr ssl certificate is in play.
This would ensure more testing of auto renewals if they knew there’s a fall back to the 1yr ssl certificate so less chance of downtime
Thanks for what you do, that’s important.
But come on guys, if you want people to adopt widely TLS/SSL you can’t keep this weird 3 month rule. I understand your point. With a year cert people are less likely to automate the process, but automating the process means adding a security weakness on a web server. One could run your script in a VM or jail and then automatically move the cert to the web server but that would be a pain.
If the last is about “Freedom” then please let people choose how they want to renew their certs. if they want to do it locally (using some weird script if you like, why not!) and then manually update the cert on the web server they have to be able to do so…
There can be an incentive so that people automate the process and create those strange 3 month certs if they want to. But if they don’t why can’t they choose otherwise?
Because some people believe they are appointed to control the world and everyone else is their subjects who they are charged with saving from themselves.
Graceful restart or config reload, or cert reload is only one part of the issue. And for many a minor part compared to the need of having a human interactive task that has to be done at least every 90 days for those with services that cannot or are not permitted to be automated. Thus, for such services the LE model is unmanageable.
I don't want another, or more frequent, routine. A 1 yr cert routine is fine. Make some notes about the process and it can be completed in just a few minutes.
If a site operator is too inept to maintain their certs and keep them up to date that says a great deal about the site operator and I would just as soon know about it via their broken certs. LE automation removes this very important visibility from the site visitors. 
Only if the process is automated incorrectly. Correct automation is more reliable than manual human intervention.
Interesting logic... we should make security harder and more laborious in order to ensure that the only people able to use it are competent.
Needless to say, I disagree.
No. That is not what I said. Just don't enable them to cover up their incompetence. I want to know when I am dealing with someone, entity, etc. that is incompetent or lacks security focus. Broken certs is a red flag about how a service is being operated.
So here is a summary of the problems so far:
Control Freakery - making choices for others because they think they know best. Sounds like politics.
Mission creep and violation. Swapping/compromising the goal for another for which funds were not donated.
Technical problems and inconvenience. Some are on this thread, more would emerge in practice.
LE want a permanent umbilical cord running to them to solve a problem they create.
Security. I suspect there is more to this.
not really LE has cert transparency, where all certs will be uploaded and that is append-only, meaning you can only ADD data, not remove anything...
Alright, this thread continues to sound like a broken record. Question to LE people: do these complaints help to make some sort of decision to go one way or the other?
In case this thread gets closed, you shouldn’t open another one. This will just result in closing the other, too.
what he meant is that someone probably will open a new thread, he he himself (or she herself)
For what it’s worth (probably not much), I’ll weigh in with my opinion.
90 days expiration period is extremely disappointing, and probably means I won’t be using Let’s Encrypt. As has been mentioned before in this thread (I think joepie91 said it best above), shoving a 90 day cert expiration down people’s throats is serious mission creep and will discourage many people from using Let’s Encrypt, myself included. Responding with “deal with it - write some automation script” is extremely dismissive and I think you guys should re-exmine your attitude toward end-users giving you constructive feedback.
I wouldn’t mind so much if the default expiry were 90 days and you encouraged people to go down that route, but certificates with a year’s expiry should absolutely be available, if your main goal is to get as many people to encrypt as many things as possible.
As well as the legacy software point that has already been made (“use newer software and file bug reports” is extremely dismissive and unrealistic), you argue that automation scripts are better if an admin leaves the company and the new guy doesn’t remember to renew the certificate. Really? Firstly, it sounds like the new guy is just incompetent. Secondly, what happens when the server dies and a new one has to be set up? Will the new guy remember to set up that automation script? Will he understand it? The web will be full of documentation for manual replacement of certs, but that custom automation script will probably have none.
In short: offer 1 year expiry certs if you actually want to achieve your goal, or many people (myself included) will just go on doing what we’re already doing. 90 day maximum expiry is idiotic.
they plan it even shorter? they seem to forget that not everything can be automated and especially with security it sometimes might be better if the admin handles it him/herself.
Do you have an example with TLS which is not automatable? I really think automation is the right way here.
1 everything that isnt (yet) compatible with LE.
2 stuff that cannot/should not be stopped every so often just for cert renewal
also we have 6 times per year a (potential) downtime which may not be acceptable for enough people.
also dont just say “you should update your software” there are probably enough companies and whatever with enough reasons to stay with old software.
by the way in this thread there also should be some other examples.
also I have no Idea when it will be generally compatible, I think as others said that 90 days should be the default with the automated process but that with manual you should be able to make it like a year, it doesnt need to be higher but a year should be possible.