That will force operations to run tip-top. It will force much TLS software to learn to reload certificates automatically.
Most critically, it will mean not needing CRLs or OCSP.
Way back when “Grid computing” was a thing you’d use daily client certificates. You’d be issued a highly restricted signing cert which could only be used to generate extremely short lived certificates with your user CN. Which avoids the whole melting CA issue by having the end user generate them.
As does automatic unvetted certificate signing (because non-repudiation), or automatic instant revocation process. (Denial of service or downgrade)
Pick your poison.
The only way to make sure you don't get bitten by things like certificate expiration is to exercise update path often, and the more often the better.
I've seen advice coming out of companies like Microsoft that password expiration dates are not useful, in part because they encourage insecure practices, and in part because the scenario where someone gets access to your password and doesn't get around to hacking you for 3 months is just not that likely.
Why doesn't that advice apply to certificates?
A company that's setting up renewals might do so in a way that exposes their certificates to more of the workforce than necessary. Setting up automated renewal adds complication over the much simpler model of, "put this special file in a vault and on the production server, and then nobody in the company gets to touch it."
It also doesn't seem likely that a compromised certificate wouldn't be exploited for an entire year.
But the general advice I've seen from security professionals is that LetsEncrypt's renewal policy is helping, and forced password changes are hurting. So it seems like there's some dimension to this that I'm missing, either around how companies are typically implementing auto-renew, or how certificates get leaked and abused.
The need to come up with a new password and memorise constantly a new strong chain of characters is an unrealistic demand for regular users, that results in attempted get arounds (passwords with a correlative number, post it notes, etc). I don't think this kind of risk is present for certificate renovation, where it's safe to think that whoever is in charge of managing it has a security background.
Or even if they don't have a security background, that they'd at least be more secure than the average user. I guess a certificate is also something that you don't need to write down and remember, which could help.
Would a good takeaway be that expiring passwords would be helpful, if users weren't terrible about password management?
I think that's a fair assessment. Passwords are doubly risky in that they're regularly touched by human hands, and often transmitted directly over the network.
I think about security more often than many people I work with, but I recognize that I'm not immune to phishing myself. Rotating passwords sounds like a great idea, but in practice it results in people just choosing terrible passwords. Better to encourage systems that reduce the possibility for human error in the first place IMO (think WebAuthn and friends).
That's the main difference IMHO.
Certs that need some manual procedure to renew already share one of the problems of changing passwords: it's yet another notification that something needs to be done soon(tm), and sometimes it will not happen until it's too late.
That failed system just happens to be the one we have been stuck with, because the solutions are to give users hardware (to prove possession) and/or build hardware into devices (to verify biometrics).
Generally not. The biggest risk with passwords is not that an attacker will magically pull them from the ether, but that they are revealed as part of a security breach.
The best password is not one thats overly complex or that you require the user to change on a set schedule. It's one that is unique.
Of course, once you have a second factor, you can resort back to much simpler, shared passwords and still retain security.
Absolutely, which is why it was considered a good practice in the past. A case of not taking into account the human factor /usability aspect.
Password expirations are insufficient and it has always been a game of cat-and-mouse with people who hate them. Good security is something people willingly use or don't know they're using, so they don't try and work around it.
Certificates are part of a decentralized, delegated trust system. They are effectively a cache of a security decision.
With passwords, the security decision is made each time you log in.
If the statement in a certificate is no longer true, you need a mechanism like OCSP stapling (I suppose - because everything else, OCSP and CRLs, have failed).
If your password is compromised, it just needs to be changed in the database or directory. The password won't be usable anymore.
Now, kerberos tickets based on the compromised password may still be good for a few more hours, but thats another story.
The fact that there is no central point of authority by default that can say "no, it's not good anymore" -- that changes a lot of things, because now your expiration date is effectively the only good way to get rid of the certificate.
That puts LetsEncrypt's 3 month model in a different light -- it's not just aggressive to force people to automate the renewal process, 3 months is literally just way better than a year for security purposes.
Is this desperately insecure?
It doesn't work for everything I guess - online banking, email, work MS password. But if it's only three nonshared passwords it's tolerable.
The safest password is one that is never forgotten, and that has a truly onerous password reset flow, e.g. needing to go in person with ID to get it reset, potentially with someone else to vouch for you (how it works at many companies). Password reset flows are ways to get around the password mechanism itself, and the more often people forget their passwords, the smoother that flow (i.e. password bypass) needs to be.
Not a problem if someone has to do it manually every year or two years, but it becomes a bigger issue if you need to renew a cert every 30 days.
We have a bunch of these like this, so for our "foo.int.example.com" systems, in our public DNS we have a CNAME pointing to "foo.int.dnsauth.example.com", and have set up a new DNS infrastructure so that we can use dns-01 validation of TXT records there:
I had no idea that this functionality existed until fairly recently.
If there's no DNSSEC, this is entirely worthless. DNS is very easy to attack.
There's no way for letsencrypt to issue you a certificate because they can't connect to it from outside.
We gave up and paid for a certificate.
Other automated systems like ACM are very easy, but assume you've bought into a more expensive infrastructure, and often only support their (AWS's in this case) services.
And at the other extreme, there are a plethora of simple web hosting packages that only serve very cookie cutter setups.
That leaves a decent number of smaller organizations or individuals that aren't really able to take advantage of automation because it doesn't support their configuration, or because they don't have the expertise to set it up correctly. So they are often stuck renewing manually.
And every time someone says, can't everyone just use LetsEncrypt, they mean, why haven't they automated it?
ACME is the third kick at the can AFAICT. Some people could perhaps be excused for thinking ACME/LE was just another flash in the pan.
Up until recently, F5's BIG-IP LTM didn't have an automated way to do it either, but since it's an appliance that is basically running on top of CentOS, you can SSH in and get a bash shell and run something like dehydrated (minimal dependencies):
There's stuff out there besides just Apache and Nginx on a Linux system, and it can't all be automated.