> 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".
In 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.
For 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).
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".