4 ms·
> The decreasing validity time pushes for the process to be automated, and automation reduces the possible human errors. There are environments and devices whe
by throw0101a 1y ago
> The decreasing validity time pushes for the process to be automated, and automation reduces the possible human errors.
There are environments and devices where automation is not possible: not everything that needs a cert is a Linux server, or a system where you can run your own code. (I initially got ACME/LE working on a previous job's F5s because it was RH underneath and so could get Dehydrate working (only needs bash, cURL, OpenSSL); not all appliances even allow that).
I'm afraid that with the 47-day mandate we'll see the return of self-signed certs, and folks will be trained to "just accept it the first time".
- jraph 1y agoIn these setups, the issue already exists: an appliance would have to renew its SSL certificate when it expires. I believe ssl certificates should already not be used anywhere they can't be renewed.
- throw0101a 1y agoThere's a difference between having to renew annually and having to do it every 47 days: * https://news.ycombinator.com/item?id=43693900 https://news.ycombinator.com/item?id=43693900
- jraph 1y agoFor an appliance, if you embed a 1 year certificate that can't be renewed, the feature will stop working correctly after a year. That's already quite short. And if it can be renewed, then it can also most probably be renewed every month no problem. You linked to a whole thread in which the top comment asks a question that's a slippery slope, and of which the top answer lists advantages of a reduced validity time (while pointing out that too short like 30 seconds poses reliability and scale risks, to address the slippery slope argument). What did you mean to point out?