What is the problem with long lived certs? Is the cryptography behind PKI considered weak nowadays, that you can collect enough material on cert that you can derive privkey? Is there other fundamental cryptographic weakness?
I understand problem of still-valid certs after domain expiration, but mere rotation strikes me as similar to password rotation ... which is currently discouraged.
The main issue is lack of a working revocation mechanism.
Servers get compromised sometimes, people do stupid things with keys, etc.
We dont have a really good way of revoking keys after something bad happens. We have some bad ways, but they kind of suck.
An additional reason might be making it easier to punish a misbehabing CA (CAs are often too big to fail, you cant ban them without breaking half the internet)
No kidding. Where I use to work, certs are a nightmare.
For example, some sites were closed and we asked the site owner to revoke their cert. We got "What does that mean ?", they had lost their private key.
Also other departments had certs that expired, they had no idea what to do. I left over a year ago, and someone who knows more about certs that I do left not long afterwards. I know many certs are due expire soon, good luck to them.
The point of this is I can see 45 day certs being a huge issue for that company. When I left they were looking into non-expiring certs. I have no idea what they ended up doing.
* Certs come with secrets. Long-lived secrets are riskier than short-lived ones because of window of opportunity if they're compromised in an undetected way.
* Less frequent cert rotations mean that the rotation process is inherently riskier. The old adage of "request a 2-year cert, and you're scheduling an outage 2 years from now" has a lot of truth to it. More frequent rotations increases the incentive to automate, which reduces the service risk.
Your second point is crucial in my opinion. In most organisations, there'll be a rush to get some new web service configured and an overworked admin is likely to set up the initial certificate. Without a short expiry date, you can almost guarantee that the admin hasn't got around to monitoring, automating or documenting the process and might not even still be working there in 2 years time.
Privilege escalation and Dev Ops rot. Long-lived certs often get compromised when privilege escalations happen and someone gets access to an account or computer that has private keys on it.
One example scenario for privilege escalation: let's say a hacker gets access to one of your employee's or vendor's machines and associated accounts using a zero-day, or phishing, or some other method that goes undetected for some time. The attacker, as part of this attack, successfully gets access to your cert's private keys through some way or another without drawing attention to themselves.
Some time later, your firm makes several security updates. When doing this, you unknowingly patched the attacker out of your network. The attacker is now in a race against time if they want to do something with the cert before it expires, and in this kind of situation, the sooner that cert expires, the better, because the attacker gets less time to do something with it. In a perfect world, the cert expired exactly when they got patched out, but because we're not guaranteed to know if there's an attacker in the first place, "keeping the expiration time as short as is reasonably possible without impacting service reliability" is what things seem to be moving towards, to limit the blast radius during access leaks.
As for Dev Ops rot, speed has a tendency to change requirements in favor of automation. Generally, certificate rotations tend to be a pain point - they break management panes, they take down websites, they throw browser errors, they don't get updated in pipelines, and other woes happen when they expire that demand people keep track of a ton of localized knowledge and deadlines that's easy to lose or forget. However, paradoxically, the longer the time between rotations, the more painful they tend to be, because once rotations are sufficiently fast, it becomes unmanageable to do them manually: demanding speed forces people to build anti-fragile rotation systems. Making the requirement be shorter is in some sense an attempt to encode into managerial culture "you need to automate this", as a bulwark against swapping your certs out being anything besides automated or one click rotations.
I'm by no means an expert, but the difference between passwords and certs is that certs can be used without any interaction with the authority.
A leaked password will reveal itself to the authority when used. You have to connect to something to use it and when doing so, can be flagged.
A long lived certificate and key can be used with no interaction with the authority, so how do you know that it is being used maliciously? The renewal is the interaction with the authority which could pick up malicious activity, so making it more regular is beneficial.
100 year certs require a consultant when the 100 years are up on any certificate and no one has any idea how the system was set up. They require a consultant when there's a security breach and you have to figure out which of the many certs you have ever used is compromised, or let the attackers in.
The hope is that 45 day certs don't require consultants because if you don't set it right you'll find it right away... and of course the risk of leak is much lesser.
It's very easy to use free certificates (e.g. LetsEncrypt) that can use a free script to automate the renewal of them. There's also plenty of free guides on how to use them for various web servers etc. That comes to a grand total of nothing.
If you'd rather pay someone else to do it for you, then that's your own issue and not really anything to do with the length of certificate validity.
>but mere rotation strikes me as similar to password rotation ... which is currently discouraged.
Cargo culting strikes again. Forcing password rotation is bad because it causes people to choose passwords with a given pattern (eg. password1, password2, etc.), which defeats any security benefit. Rotating certificates have no such issue, because the key is (presumably) randomly generated.
I think it’s the same mentality as “change all your passwords every 6 months”, just a useful principle “change your password if you think you need to” because a ridiculous rule of thumb and hammer slap everything is a nail. A reasonable rule like “update your cert at least once a year” becomes “by extension wouldn’t updating your cert once a month better?”
What happened to personal freedom of letting people choose for themselves how long a certificate should last? Not really liking this trend of large companies making decisions for others and then forcing them on everyone.
I'm not sure how you think certificates work? It's not for 'yourself' - the certificate is an assertion to billions of users worldwide, called relying parties. If you don't care about those, then you can use a private CA. If you do care (and want anyone's browser to work) then it's not a 'personal freedom'.
I find it interesting that all of the arguments seem to be about the merits of whether pushing this on everyone is good or not, and they all take for granted that personal freedom does not matter anymore.
I dislike not being able to choose my SSL lifetime for the same reason I do not like a web browser deciding for me if I can use my own CA. In both cases choices are being made for me, whether I like them or not.
And making ourselves completely dependent on those certificate authorities handing out certs. Dystopian, a couple of mega corps deciding who gets a cert and who doesn't.
Nothing stopping you running your own CA and issuing your own certs.
Your actual problem is that the browser vendors (who decide which certs should live in the root store) have certain criteria which CAs need to meet in order to be trusted.
Why should Firefox / Chrome / etc. have to honour your desire that your arbitrary-length lifetime certs are trusted by default in their browsers? You still have the personal freedom of installing your own CA root if you like.
The networked environment of today is rapidly phasing-out anything not passing through big bulky systems (most of the time these are for-profit firms). While we wait for the moment one of them (like Let's Encrypt or Sectigo or some BS from FAANGs) will become a SPoF and mess up services anywhere, you can always roll a private CA, use SSH tunnels or SOCKS proxies.
This talk of automation is all well and good for systems that are permanently connected to the internet.
Let's say I've got a system on a vessel that will be at sea for two months with unreliable, or no internet connectivity. I want to allow passengers and crew to use this system with their own devices.
What do I do then? Use self signed certs, and just tell users to click through the warnings?
Mixed comments in the github issue. I can definitely see how shorter lifetimes provide better security, but I have also run into my fair share of issues caused by cert expiry. Do we have good data around the lead time between someone’s signing keys being compromised and their use in an attack? The shorter that lead time the less useful this change is.
>Do we have good data around the lead time between someone’s signing keys being compromised and their use in an attack?
Given how fast it is to set up a phishing proxy, such "lead time" is probably measured in hours rather than days. Even something like a 1 week expiry will provide security benefits.
We need more safetyism culture. We need to ban root access completely by 2030. 10-factor security for login. 256 digit OTP and you must insert a drop of blood to login.
so cool, if there was some startup to give you a full health info with that. Imagine - with your login attempt it comes a proper analysis if you are fit for purpose.
If we're going this route then maybe drop HTTPS all together, go back to port 80 and instead PGP encrypt each file with a different key and add the cool peoples public keys. This would keep malicious people and bots away from the content.
There have been proposals about shortening much further: in fact, the long-standing practice in the PKI community is that renewing certificates every 7 days is short enough that no revocation service is necessary at all. However, trying to move the entire IT industry to a 7-day renewal window is a bridge too far at this point!
Instead, I would surmise this is the first step in that process by introducing a window short enough to act as a forcing function on automating certificate issuance & renewal. It's short enough to strongly encourage leveraging automation everywhere possible, but not so short that one could argue it's impossible to do manually for things that still just can't do this automatically, of which there are still a disappointingly significant number.
Once we begin to get below 30 days, however, I suspect there will be a lot more scrutiny around the data suggesting exactly how small a window is sufficient. From a risk standpoint, if we're arguing shorter-is-better, then we should go as short as possible: someone will need to pull together the data that suggest exactly how small a window appropriately balances the various risks involved. (And then 15 others will need to argue about the validity of the data, whether the data actually suggest that, whether the data were assembled with an agenda in mind, etc., etc., etc.).
3 days is far too short. The certificate supplier could have a crucial piece of equipment or software stop working and 3 days might be too tight a timeline to get it fully resolved which then leads to lots of people having invalid certificates and the certificate supplier would be out of business shortly afterwards.
What does reducing validity actually solve? The same private key is presumably used by all certificates and CSRs - if the private key is compromised then a renewed cert doesn’t solve anything.
The only thing I can think of is domain expiry. Someone could get a certificate, sell their domain, then continue using the cert until the certificate expires.
My tinfoil hat says it's about control. Forcing people to return for another blessing from the central authority, more often. The same reason church is once a week, and not once a year.
* there is no robust revocation mechanism, so just minimizing the validity of a compromised cert is the most effective - and technically simple - tool. OCSP is not viable for myriad reasons discussed over the years. OCSP stapling is optional and browsers have to consider it such explicit (opt in) policies.
* extended lifetime means rolling certificates is a complex ceremony that means rapid response is off the table, and can take companies days if not weeks to do.
* following from that: long lived certs also breaks distrust of CAs as they (or site owners) return with “we can’t perform the task we agreed to because we’ll break our customers” (CAs often fail to understand that their primary customers are end users not site owners).
Readit News
I understand problem of still-valid certs after domain expiration, but mere rotation strikes me as similar to password rotation ... which is currently discouraged.
Servers get compromised sometimes, people do stupid things with keys, etc.
We dont have a really good way of revoking keys after something bad happens. We have some bad ways, but they kind of suck.
An additional reason might be making it easier to punish a misbehabing CA (CAs are often too big to fail, you cant ban them without breaking half the internet)
For example, some sites were closed and we asked the site owner to revoke their cert. We got "What does that mean ?", they had lost their private key.
Also other departments had certs that expired, they had no idea what to do. I left over a year ago, and someone who knows more about certs that I do left not long afterwards. I know many certs are due expire soon, good luck to them.
The point of this is I can see 45 day certs being a huge issue for that company. When I left they were looking into non-expiring certs. I have no idea what they ended up doing.
FWIW, this is a fortune 500 company.
Why would there be. If the key is 'revokable' that is a weakness in it self.
* Certs come with secrets. Long-lived secrets are riskier than short-lived ones because of window of opportunity if they're compromised in an undetected way.
* Less frequent cert rotations mean that the rotation process is inherently riskier. The old adage of "request a 2-year cert, and you're scheduling an outage 2 years from now" has a lot of truth to it. More frequent rotations increases the incentive to automate, which reduces the service risk.
Privilege escalation and Dev Ops rot. Long-lived certs often get compromised when privilege escalations happen and someone gets access to an account or computer that has private keys on it.
One example scenario for privilege escalation: let's say a hacker gets access to one of your employee's or vendor's machines and associated accounts using a zero-day, or phishing, or some other method that goes undetected for some time. The attacker, as part of this attack, successfully gets access to your cert's private keys through some way or another without drawing attention to themselves.
Some time later, your firm makes several security updates. When doing this, you unknowingly patched the attacker out of your network. The attacker is now in a race against time if they want to do something with the cert before it expires, and in this kind of situation, the sooner that cert expires, the better, because the attacker gets less time to do something with it. In a perfect world, the cert expired exactly when they got patched out, but because we're not guaranteed to know if there's an attacker in the first place, "keeping the expiration time as short as is reasonably possible without impacting service reliability" is what things seem to be moving towards, to limit the blast radius during access leaks.
As for Dev Ops rot, speed has a tendency to change requirements in favor of automation. Generally, certificate rotations tend to be a pain point - they break management panes, they take down websites, they throw browser errors, they don't get updated in pipelines, and other woes happen when they expire that demand people keep track of a ton of localized knowledge and deadlines that's easy to lose or forget. However, paradoxically, the longer the time between rotations, the more painful they tend to be, because once rotations are sufficiently fast, it becomes unmanageable to do them manually: demanding speed forces people to build anti-fragile rotation systems. Making the requirement be shorter is in some sense an attempt to encode into managerial culture "you need to automate this", as a bulwark against swapping your certs out being anything besides automated or one click rotations.
A leaked password will reveal itself to the authority when used. You have to connect to something to use it and when doing so, can be flagged.
A long lived certificate and key can be used with no interaction with the authority, so how do you know that it is being used maliciously? The renewal is the interaction with the authority which could pick up malicious activity, so making it more regular is beneficial.
It is like credit cards. The more problem the more money is to be made by middlemen.
The hope is that 45 day certs don't require consultants because if you don't set it right you'll find it right away... and of course the risk of leak is much lesser.
If you'd rather pay someone else to do it for you, then that's your own issue and not really anything to do with the length of certificate validity.
Cargo culting strikes again. Forcing password rotation is bad because it causes people to choose passwords with a given pattern (eg. password1, password2, etc.), which defeats any security benefit. Rotating certificates have no such issue, because the key is (presumably) randomly generated.
Additionally, short renewal periods encourages automation which is more secure than a manual process.
Password rotation is discouraged because usually it means that users will create weaker passwords.
These "large companies" put restrictions on what certificate authorities are allowed to do so that they can keep their users safe.
Dead Comment
I dislike not being able to choose my SSL lifetime for the same reason I do not like a web browser deciding for me if I can use my own CA. In both cases choices are being made for me, whether I like them or not.
What browser does not allow you to load your own trusted CA?
"You can't install that, it might be a virus!"
other decisions they've made on this topic that you can disagree with if you care:
- ciphers
- hashes
- CAs
- revocation systems
etc
And what about the right for users to privacy and security, when there's no drawback on the host other than their misguided sense of "freedom"?
Your actual problem is that the browser vendors (who decide which certs should live in the root store) have certain criteria which CAs need to meet in order to be trusted.
Why should Firefox / Chrome / etc. have to honour your desire that your arbitrary-length lifetime certs are trusted by default in their browsers? You still have the personal freedom of installing your own CA root if you like.
Let's say I've got a system on a vessel that will be at sea for two months with unreliable, or no internet connectivity. I want to allow passengers and crew to use this system with their own devices.
What do I do then? Use self signed certs, and just tell users to click through the warnings?
Given how fast it is to set up a phishing proxy, such "lead time" is probably measured in hours rather than days. Even something like a 1 week expiry will provide security benefits.
45 days ? So much ? Why not expire the next day ?
At least, we’ll be super secure!
so cool, if there was some startup to give you a full health info with that. Imagine - with your login attempt it comes a proper analysis if you are fit for purpose.
ǝʞoɾ ǝᴉzzo uɐ s,ʇɐɥʇ sǝʎ
OSCP stapling except without the oscp stapling part.
Instead, I would surmise this is the first step in that process by introducing a window short enough to act as a forcing function on automating certificate issuance & renewal. It's short enough to strongly encourage leveraging automation everywhere possible, but not so short that one could argue it's impossible to do manually for things that still just can't do this automatically, of which there are still a disappointingly significant number.
Once we begin to get below 30 days, however, I suspect there will be a lot more scrutiny around the data suggesting exactly how small a window is sufficient. From a risk standpoint, if we're arguing shorter-is-better, then we should go as short as possible: someone will need to pull together the data that suggest exactly how small a window appropriately balances the various risks involved. (And then 15 others will need to argue about the validity of the data, whether the data actually suggest that, whether the data were assembled with an agenda in mind, etc., etc., etc.).
Am I missing something here?
That's a choice. Certbot changes the private key with every renewal by default. I suppose in principle CAB might start disallowing key reuse.
Dead Comment
* there is no robust revocation mechanism, so just minimizing the validity of a compromised cert is the most effective - and technically simple - tool. OCSP is not viable for myriad reasons discussed over the years. OCSP stapling is optional and browsers have to consider it such explicit (opt in) policies.
* extended lifetime means rolling certificates is a complex ceremony that means rapid response is off the table, and can take companies days if not weeks to do.
* following from that: long lived certs also breaks distrust of CAs as they (or site owners) return with “we can’t perform the task we agreed to because we’ll break our customers” (CAs often fail to understand that their primary customers are end users not site owners).