SSL certificate lifetimes are going down. Dates proposed. 45 days by 2027
github.com
github.com
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)
Why would there be. If the key is 'revokable' that is a weakness in it self.
???
Why?
At least perceived censorship risk is why the archive.is guy always uses HTTP links and not HTTPS links for his site, iirc.
I don't really get the argument behind using HTTP links to avoid the censorship risk with HTTPS - just provide both and get the best of both worlds. Also, using HTTP is far more prone to being interfered with in transit - I recall BT (or their ISP business department) trialling that and injecting adverts into HTTP pages. I can't recall any instance of HTTPS being censored by restricting certificates.
The majority of CAs are in the US.
I guess it decreases the lead time of censorship. That seems pretty minor though.
What??
This does not make sense. Keys are revocable in most crypto systems.
Ish. The threat of that is part of a different risk model, and probably less serious.
A long-lived certificate that ends up being able to be used by a malicious party (perhaps due to a leak of the private key) could be serious for many users if the certificate can't be reliably revoked, which they currently can't be.
A mistaken or malicious revocation if someone were to manage that could be an issue to the service operator (users can't get in) but this is a safer failure than users connecting to a malicious shadow service due, for example, to an accidentally exposed private key and a DNS poisoning attack.
As others have mentioned: if revocation worked better currently, this would be less of an issue.
A few older crypto mechanisms were designed around trusting one thing totally. For example, everything's secure until the end of time provided that the user keeps a private key totally private at all times, with no interruption, ever, and if the user lapses then the overall mechanism breaks really badly.
They were complicated mechanisms held together by a screw made of a metal which was assumed to be infinitely strong.
The current fashion is to trust thing in a more limited way, and to design systems such that they won't blow up spectactularly if something breaks. Being able to revoke keys is part of that, it is a weakness that helps to avoid a really bad weakness.
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.
But to set it all up in F500 size company, that is totally different discussion and not only TLS certs but all kind of other cert auth that happens there.
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.
* 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.
Personally, I don't see the problem with short expiry dates, though less than a month would be too short in my opinion.
Their users are "people using browsers", not "people asking for cert signatures".
Plus, this concept that short expiration times increase security is suspect at best. If the private key leaked, 45 days is far too long, you'd need to reduce this to hours to actually help as a revocation strategy. And even then, chances are that the new key will leak as well right away, as it's most likely that the key was stolen by some undetected malware. And if the key didn't leak, a two year old cert is just as secure as a two minute old one.
I disagree. The smooth running and ease of automation of TLS certs benefits the entire ecosystem, including the end-users. Remember when the only sites that had TLS certs were the ones that could afford it?
> If the private key leaked, 45 days is far too long, you'd need to reduce this to hours to actually help as a revocation strategy.
This is a good example of the Nirvana Fallacy.
> And even then, chances are that the new key will leak as well right away, as it's most likely that the key was stolen by some undetected malware.
No certificate expiry control can protect against continuous, undetectable data exfiltration. Meanwhile, a one-time access that grants me the ability to impersonate you for 2 years is a significantly worse situation than one that only grants me that ability for a few weeks.
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.
It is like credit cards. The more problem the more money is to be made by middlemen.
And I could argue that lower prices implies money is made somewhere else. Like how Cloudflare infested half the internet with their free MITM.
But, ye, I should chill a bit on topics like these. I have hard time not ending up in a 'Google etc. is coming for me' rant.
It's particularly bad to do this when you're knowledgeable and (let's assume) correct on a topic, because then the bad parts of your comment (such as personal attacks) end up discrediting the truth. That doesn't help anyone. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
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.
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.
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.
However, there is the https-only movement to prevent web browsers from viewing my website, because it it not https and therefore not 'safe'.
This movement overlaps pretty well with the people who don't accept other different certificate authorities.
Like i said, nothing is stopping you from doing whatever you want other than the fact that other people might not like it, and might choose to treat your website differently. Just like you can choose not to use https, other people can choose not to like sites that don't use https. Freedom goes both ways.
There is a big difference between "nothing is stopping you from starting an exercise program" and "nothing is stopping you from being the ruler of the planet" even though the construction is the same.
Certificates are particularly painful because it sometimes seems that every program that needs them has its own way to find them. I can't just install in one OS-wide store and say that it should work just like the certificates from the major certificate authorities.
No, I have to install it in Chrome and Firefox. Oh and I've got some Python scripts and some Perl scripts and some PHP scripts that need it, so I've got to put it where they want. And let's not forget curl and wget. And how about thing I'm running in a VM or under Docker? Or database clients.
These "large companies" put restrictions on what certificate authorities are allowed to do so that they can keep their users safe.
No such law is being proposed. The cops aren't going to bust down your door for generating a 3650 day certificate using openssl.
Passport max validity length is set by the ICAO not the government.
Contracting states are free to do whatever they like but for the most part, they choose to follow the Recommended Practices.
https://www.icao.int/WACAF/Documents/Meetings/2018/FAL-IMPLE...
The depends where you live, and what the government means. In some places the validity of a passport is written in a law, voted by the parliament; in other it's a operation decision by the government (e.g. the ministry of the internal affairs).
Where I live it's a law voted by the parliament.
Also TLS fingerprints and biometrical data are "hashed" data, if that's what you mean about having in common.
They're both centrally revokable, attested assertions of identity, where the attestation can be validated with the attester offline.
If you try and come up with a design for any system that includes this type of assertion, you'll end up in a place where you'll probably want it to expire and need re-validation at some point. That expiry is a property of the attestation, and is therefore controlled by the person/group doing the attestation. In the case of a passport, this happens to be the government. For a cert, it's the CA.
Oddly enough, virtually all passport/personal ID checks around here are... online. Airports, police, any shop... all of them are all online.
The CAB forum is not a company (although it is made up of some) and the government does not set passport max validity lengths (they can make it shorter than 10 years, just like CAs can make certs shorter, but there is a reason no country gives out passports longer than 10 years)
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.
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.
"You can't install that, it might be a virus!"
What browser does not allow you to load your own trusted CA?
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"?
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!
ǝʞoɾ ǝᴉzzo uɐ s,ʇɐɥʇ sǝʎ
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.
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.
* 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).
You are not the only user of the software that you use.
I just don't want my garage door integration with my car to stop working because its certificate broke. I'd argue these privately deployed single use dedicated certificates are actually better off self-signed and issued on a TOFU basis than using public key infrastructure. It's how bluetooth and many other things work, so why on earth are browsers so bent against it.
Plus, this is yet another blow to using TLS for networks not connected to the Internet. Asking users to go through some pain of accepting a new self-signed cert every three months, which was already worse than once a year, is going to get almost untenable at 45 days. And no one is offering any realistic alternatives.
I don't get it, is the domain extra susceptible to misissuance during the renewal process? If not, I don't see how this is a relevant point.
If someone hijacks your domain they can get a certificate right away, no matter how long the existing certificate was valid for.
> Asking users to go through some pain of accepting a new self-signed cert every three months, which was already worse than once a year, is going to get almost untenable at 45 days.
Are you experiencing the former right now? I thought these policies had no impact on self-signed certs at all.
Also, if there's a non-internet connected network or device that uses TLS, it shouldn't be using public/webPKI certificates. Use a private CA, get the root on the managed devices that connect to it, and the problem goes away. That's always been an option.
I still think more enforcement and standards around IoT SSL are the way to go, with shorter timelines not necessarily more beneficial.
Let's face it, whoever is renewing every 90d is going to be renewing every 45d just fine. It's the devices and companies that use yearly expiries (and still PAY FOR CERTS!) or don't use SSL at all that are the problem.
How does it help? A lot of cert would expire prematurely and the folks will learn to accept expired cert as a norm.
People seem to be under the misapprehension that Let's Encrypt / ZeroSSL certificates are "free". They are not — it's that the consumer is not the one paying the bill.
It costs tens to hundreds of thousands of dollars a year just to get the audits required to operate a public CA, much less pay for the infrastructure and staffing required. That bill has to get paid somehow. Yes, pricing on certs in the past has been questionable, but operating a public CA is -not- free, so CAs have sold certificates to pay for that service operation. That has introduced some issues of its own in terms of profit motives, although I would observe that for the majority of public CAs their public TLS certificates are frequently a loss-leader service and not a massive source of income. Put short (too late!), there's nothing wrong with the practice of paying for certificates in and of itself.
What makes me very concerned about the current model funneling everyone to "free" CAs is that those bills are being paid at the moment through donations to ISRG and other organizations. I like that ISRG is making efforts to broaden their donation base to reduce reliance on single sources! However, I'd much prefer to be paying them a monthly subscription fee for their certificate service and not have my ability to leverage it be dependent on the largesse of large corporations that frequently abruptly decide services like this should either cost money or pay up in user data. (Note that I explicitly do not think the user-data thing is happening right now, only that I'm concerned it becomes a problem in the future.)
Maybe some kind of traffic based tax would be better - just have the biggest ISPs pay for all of the free CAs.
There is no reason for kozubik.com to be served with SSL … But browser behaviors, and changing social norms force me to do it.
I also worry a bit about the amount of the Internet that now depends on Let's Encrypt, including a number of large enterprises. That didn't go very well the last time we had an 800-pound gorilla in the CA space, not to mention the availability problems that will occur if everyone depends on a single CA that then has an outage, a mass revocation problem, or has a disagreement with the browsers over issuance rules.
For public internet yes, shorter is not entirely unreasonable.
Again, all of these devices are theoretically under your (intermittent) influence
The other benefit of DNS validation is that you don't need to run it on the web server itself (e.g. if it doesn't have internet connectivity), but you can have an ordinary PC/laptop request the certificate and then copy it to where it's needed.
I was surprised by a customer yesterday who was looking to migrate thousands of manually renewed 1 year certs, I had no idea people were still using 1 yr certs to such a broad degree.
This seems to have started around August 2020.
So instead they will sell "subscriptions" where you get a new certificate on expiry. So technically they will still sell you multiple years, but as a subscription.
90 days is a good compromise between encouraging autorenewal and allowing services to be down for a couple of days without really impacting anyone. It's short enough so that the person who set up the automation is probably still employed and thus they have an incentive to fix any issues.