90 days is very short for manual updates. It would be nice if the default would be 1 year, so that those who have to manually request and update certificates have less work to do. It would also not be much of an issue to use the 1 year period for websites where security issues are less critical.
You can then let people specify via a commandline option if they want shorter periods (90 days, 120 days etc.) for those who have bigger security concerns and who use automation.
Why would you default for the longer lifetime? The idea behind Let’s Encrypt is automation. If for some reason your server or your policy doesn’t work with that, you are the outlier here. It would stand to reason that if Let’s Encrypt would implement a longer certificate lifetime, this longer lifetime would be optional, not the default.
What would be the current liability for LE to support the scenarios listed in the cons? I suppose if something bad does happen later on for the more complicated/risky/uncommon scenarios that are harder and more complex to support, it would burden and harm the reputation of LE, so considering the early stage of the project, and as a user who can already benefit from automated 90-day certs, I would rather have them focus on making the existing policy as solid as possible (and not winning over existing customers of paid certs)
In the mean time, the respective niche communities can still work with LE to explore ways to utilize/automate the existing process, until it improves to the point when supporting non-mainstream devices is deemed not so risky and can be done with minimal burden to LE.
In summary, longer duration certs (for the convenience of supporting a wide range of uncommon scenarios, e.g. non-webservers with limited exposure to internet) should have lower priority given early stage of the project.
There are ways to automatize this. For example python has the mechanize module, which can act like a browser. So uploading a https-certificate would be possible. You need to run this every 60 days on some workstation, though.
People will waste more time in pursuit of trying to automate due to the short cert life time, and dealing with automation issues, than they would manually renewing once a year for the next 20 years.
I think it's more like several similar discussions on meta.discourse.org - there is no good answer, anything you say will be used against you. So you just don't answer. You skim the replies when they come in, and then move on.
Personally, I don't see how the supposed backdoor is supposed to work on a technical level.
There seems to be a lot of valuable input in this thread. I’d love to see a response from the LetsEncrypt staff addressing the possibility of longer cert lifetimes.
I suggest an incremental system, first time maximum 3 months, first renewal maximum 6 months. the following maximum 12 months.
Many will have no intention to keep the certificate in time, so will not have a cost of resources since they will only have a life of 90 days, but really interested can opt them for a more comfortable set of 12 months.
On the other hand, I think the first renewal should necessarily be manual and not automatic, to prevent malicious systems.
If your plan is to provide maximum HTTPS coverage, then duration select (1 day - 39 months) should be available during certificate generation.
We would love to use LetsEncrypt in our projects, but many of them run on shared hostings, where there is no possibility to automate generation, and default (unchangable) 90 days expiration period is just way too short.
This leaves us with two options: buy a proper cert, or serve by HTTP. Guess, which one was selected by our client? Yep, the free one - do not use a certificate.
So the rationale is that people can forget how to do things in a year, or the way to do things can change.
But if we automate, then we can all but guarantee that people will forget how to do things, or will have moved on. And we still haven't solved that the way to do things can change.
By automating it, we can all but guarantee that the process was documented through actual, working code. If something changes, you use that as a starting point (which, unless we’re talking about a complete overhaul, is better than “It’s been almost [1-3] years since I last did this …” or “How did my predecessor do this? I can’t find any documentation.”).
This is one of the key advantages of the DevOps way of doing things.
All of which are issues created and allowed to exist by poor management.
Automation is a poor substitute for good management and proper documentation and procedures. All of which are better addressed by management that automation.
The automation argument to address management issues is a fallacy.
If predecessor not detail oriented enough to document then odds are they did wrong/poorly anyway. Better off cutting losses and doing it properly and creating good documentation going forward.
I’d say invalid certificates would be a very handy symptom to diagnose such a stupid error in your setup Rather an argument pro short lifetime certificates if you’d ask me… Get certificate errors? Fix your clock!
Not really a problem a CA should be concerned about…
Rather an argument pro short lifetime certificates if you’d ask me… Get certificate errors? Fix your clock!