Should HTTPS Certificates Expire After Just 397 Days? (zdnet.com) 92
Google has made a proposal to the unofficial cert industry group that "would cut lifespan of SSL certificates from 825 days to 397 days," reports ZDNet.
No vote was held on the proposal; however, most browser vendors expressed their support for the new SSL certificate lifespan. On the other side, certificate authorities were not too happy, to say the least. In the last decade and a half, browser makers have chipped away at the lifespan of SSL certificates, cutting it down from eight years to five, then to three, and then to two. The last change occured in March 2018, when browser makers tried to reduce SSL certificate lifespans from three years to one, but compromised for two years after pushback from certificate authorities. Now, barely two years later after the last change, certificate authorities feel bullied by browser makers into accepting their original plan, regardless of the 2018 vote...
This fight between CAs and browser makers has been happening in the shadows for years. As HashedOut, a blog dedicated to HTTPS-related news, points out, this proposal is much more about proving who controls the HTTPS landscape than everything. "If the CAs vote this measure down, there's a chance the browsers could act unilaterally and just force the change anyway," HashedOut said. "That's not without precendent, but it's also never happened on an issue that is traditionally as collegial as this. "If it does, it becomes fair to ask what the point of the CA/B Forum even is. Because at that point the browsers would basically be ruling by decree and the entire exercise would just be a farce."
Security researcher Scott Helme "claims that this process is broken and that bad SSL certificates continue to live on for years after being mississued and revoked -- hence the reason he argued way back in early 2018 that a shorter lifespan for SSL certificates would fix this problem because bad SSL certs would be phased out faster."
But the article also notes that Timothy Hollebeek, DigiCert's representative at the CA/B Forum argues that the proposed change "has absolutely no effect on malicious websites, which operate for very short time periods, from a few days to a week or two at most. After that, the domain has been added to various blacklists, and the attacker moves on to a new domain and acquires new certificates."
This fight between CAs and browser makers has been happening in the shadows for years. As HashedOut, a blog dedicated to HTTPS-related news, points out, this proposal is much more about proving who controls the HTTPS landscape than everything. "If the CAs vote this measure down, there's a chance the browsers could act unilaterally and just force the change anyway," HashedOut said. "That's not without precendent, but it's also never happened on an issue that is traditionally as collegial as this. "If it does, it becomes fair to ask what the point of the CA/B Forum even is. Because at that point the browsers would basically be ruling by decree and the entire exercise would just be a farce."
Security researcher Scott Helme "claims that this process is broken and that bad SSL certificates continue to live on for years after being mississued and revoked -- hence the reason he argued way back in early 2018 that a shorter lifespan for SSL certificates would fix this problem because bad SSL certs would be phased out faster."
But the article also notes that Timothy Hollebeek, DigiCert's representative at the CA/B Forum argues that the proposed change "has absolutely no effect on malicious websites, which operate for very short time periods, from a few days to a week or two at most. After that, the domain has been added to various blacklists, and the attacker moves on to a new domain and acquires new certificates."
Let's Encrypt (Score:2)
Re: (Score:3)
This is now very easy to automate. No more remembering needed.
https://certbot.eff.org/ [eff.org]
Re: (Score:3)
Indeed, possibly with some scripting wrappers depending on your exact setup (in my case running certbot on one machine that NFS exports filesystems to a separate web VM, so things need pushing over). My setup 'attempts' (certbot won't even try if a certificate still has at least 30 days left) renewals once a week to be sure it catches them all in time.
LetsEncrypt's decision early on to have certificates only last 90 days, precisely so that it would force users to implement frequent, almost certainly aut
Re: (Score:2)
Yeah, automated renewals fail often for me. Usually it's something completely idiotic too, like certbot failing to update (it updates itself EVERY FREAKING TIME it tries to renew; I think certbot is the most updated software on the planet) and also them CHANGING THE FREAKING COMMAND LINE OPTIONS so it stops working randomly and you have to edit the renew script.
Don't get me wrong, I love LetsEncrypt, but the Certbot folks need to make their software more reliable. It really should be set and forget for this
Re: (Score:2)
O_o - I've not encountered any such problems with certbot. Maybe once, using it since December 2015, have I had to adjust command-line options for renewals. Are you trying to do something other than a simple "certbot-auto renew" ? That will attempt (after checking current expiry) renewal on all domains that already have a certificate. I'm using a "git clone" of certbot rather than Debian's packaged version, this being on a Debian Stretch system (Buster can wait another few months).
And as I said in an
Re: (Score:2)
Re: Let's Encrypt (Score:1)
Re: (Score:1)
Re: (Score:2)
You also have to distribute and install the certificates. ...
I doubt your certbot has access to the network I have at work
Re: Let's Encrypt (Score:2)
Only if you have a single server.
Re: (Score:2)
Glad it works for your specific use case. Assuming that all the other use cases are the same is a mistake.
Re: (Score:2)
I admit it's kind of a pain to renew certificates every three months. Have to remember to do it.
There are tools from LE that automate updating certs. Check their website.
I was running them for quite a while until my main server had a disk failure, and I realized the decreasing value of self-hosted web services.
I did use https services for about 15+ years first with self-signed certs, then LE. Most useful service was SSH over HTTPS...
Re: (Score:2)
Yeah, but they want a pile of Python to run as root. There's no way to get it to drop privileges for the parts that don't actually need permissions. No way am I allowing that on important servers.
Re: (Score:2)
There are lot of alternative solutions. Some of them even recommends to read entire code (it is fairly small and comprehandable) before deploying.
I use solution based on acme-tiny [github.com].
Re: (Score:2)
You are certainly doing it wrong. The point of short timespan is to push you to automating the renewal. If it's automated, it will happen when it have to and will always work the same way. The script won't forget to renew, or skip some steps.
Just automate it (there are thousands of tools for LE/ACME).
Should HTTPS Certificates Expire After 397 Days? (Score:5, Funny)
Everyone knows it should be 255 days to save on space. (Or 99 if you're using BCD on your EBCDIC mainframe.)
Re: (Score:3)
397 sounds so arbitrary. I guess it's the maximum possible term of 1 year + 1 month (366 days + 31 days). It's pointless to even be as specific as days, when it can be 13 months. I pay the same amount for most services in a non-leap year February as I do in a July - there's really no point in worrying about the potential variation.
Re: (Score:2)
Certificates only encrypt traffic. CA's shouldn't even matter, a properly generated self-signed certificate is much better.
Re: (Score:2)
Re:Should HTTPS Certificates Expire After 397 Days (Score:4, Insightful)
CAs basically prevent a MiTM attack on the first connection
That's not quite correct, the actual statement should be that a CA will possibly prevent a MITM from anyone whose money it refuses to accept.
They however do nothing against phishing and similar attacks, which is what the real threat is.
Re: (Score:2)
which is what the real threat is.
Bah. Phishing is nothing compared to randsomware, which is what the real threat is.
Actually randsomeware is nothing compared to infrastructure attacks, which is what the real threat is.
The problem with that statement is that by ignoring an avenue of crime that avenue becomes desirable to pursue, especially considering how simple MITM are to execute on public infrastructure if you have control over a certificate.
Re: (Score:1)
CAs provide a reasonable amount of trust that a certificate is from the actual owner of the website.
Re: (Score:2)
The issue with self-signed certificates is that anyone can generate a self-signed certificate for your domain. :^)
So? My users will only trust the cert I've given them.
Re: Should HTTPS Certificates Expire After 397 Day (Score:2)
a properly generated AND DISTRIBUTED self-signed certificate is much better.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
CAs already sell certs by the year anyway, i.e. they can issue for less than the maximum time limit but not more.
Shorter maximum cert lifetimes means they can't sell a 10 year cert any more, they have to fight for business every 2 years when the last one expires. It probably increases their support costs too, as they get tickets blaming them for failed cert updates by inexperienced IT staff who forgot to renew until the company website started displaying warnings.
As to why Google cares, it's because certifi
Re: (Score:2)
As to why Google cares, it's because certificate revocation is not all that effective and the longer the maximum lifespan the longer bad certs can be out there.
There's been a pile of research on this as well, the average lifetime of a phishing site is measured in days if not hours. Forcing a cert rollover after a year has no effect whatsoever. It's a variation of why forced password changes were finally dropped after decades of research showing they were a really bad idea, they have no effect on attackers but negatively impact security due to the constant stir of having to roll over credentials.
Shorter life span is a patch not a solution (Score:2)
Also as a user of Let's encrypt, I think even a very short life span, with proper tools, would cause no headache to the market. CAs need to clean up their mess.
Re: (Score:1)
Also as a user of Let's encrypt, I think even a very short life span, with proper tools, would cause no headache to the market. CAs need to clean up their mess.
CAs could improve customer retention by just making certs a monthly fee and forking Certbot to handle their monthly renewals. Very easy integrations into all sorts of existing systems that way with very little modification.
Re: Shorter life span is a patch not a solution (Score:2)
"If cert revocation worked as intended, then CAs wouldn't need to cry about shorter lifespans now. So, it's still CAs fault either way."
As far as I know, fixing revocation is in the software implementers court; too little certificate-using software supports OCSP.
This was quite obvious recently when the issuer of AWS S3's public certificate broke their OCSP signing certificate chain, and almost no-one noticed .
Re: (Score:2)
However CAs has the overall responsibility of the system, as we as the users (either as end user o
Re: (Score:2)
Look at the shiny object! (Score:1)
If you're using "think of the security!" as the root of your argument and you're relying on timeouts of known-to-be-revoked certificates for that security, you're either lying or stupid.
That revoked cert is dangerous enough in days. Cutting from some hundreds of days to some fewer hundreds of days is like weather stripping the screen door on your submarine to reduce leaks...
This is stupid... (Score:1)
more rules and stupidity to try to save people from dumb-asses. You can't save them from them, all you do is make more work for people that are not dumb-asses trying to keep up with the rules.
Not to mention I already hate the Commercial CA fraudulent business model. The Comodo breach is all the proof you need that Commercial CA is nothing but a filthy stinking scam.
Similar problem, similar non-solution (Score:5, Interesting)
Passwords: change them every 14 days because ... reasons.
Certificates: change them every 397 days because ... reasons.
If your password or certificate is compromised then it must be changed immediately.
If your password or certificate is strong and not compromised there's no reason to change it.
Re: (Score:2, Informative)
Re:Similar problem, similar non-solution (Score:5, Interesting)
Major sites still manage to forget to renew certificates (Ubisoft's Uplay PC client couldn't retrieve news a few weeks back because of this). Having shorter certificate lifetimes better forces sysadmins to ensure they're on the ball with the renewal, preferably in an automated (output checked by humans shortly after) manner. LetsEncrpt is great for this.
Or... remove the expiry date entirely.
Other than cash-cow reasons, why do certificates ever expire? They are effectively just keys. Keys don't expire. If a key is compromised, you change the locks, which is the equivalent of revoking a cert. If a key is obsoleted, you upgrade the lock and issue new keys, which is the equivalent of a browser dropping support for legacy certs.
Once a cert is issued, there's no burden on the issuer, so why are we paying repeatedly for the product we already have?
I have similar views with regards to domain names. I mean... yeah, there's some infrastructural costs there but all the real traffic is at DNS. Domain registration should be a decade or two
Re:Similar problem, similar non-solution (Score:5, Informative)
The original reason there is some sort of expiry is to limit the size of the revocation lists. For example, all certificates in revocation that have expired can effectively be removed since they have expired. Without that limitation, every 'revoked' cert must remain on the list forever.
That being said, how many certs are actually revoked, versus certs that are simply abandoned, or the private keys lost. If the revocation lists are small anyway, there is no pressure to implement expiry.
An additional advantage or revocation is to limit the problem of poor data handling (eg. old servers being thrown out, etc) allowing potentially valuable certs to fall (unkowningly) into the wrong hands. Expiry doesn't prevent short term problems, but it does mean that an old system that final gets sent for 'recycling' (ie. landfill) is unlikely to contain anotherwise non-expired cert. Especially if expiry times are as short as 1 year.
Expiry was implemented before revocation, though (Score:2)
Hmmm, as I recall, x.509 certs had expiration dates built in from the original spec, and SSL/TLS capable browsers were always able to detect expired certs, but revocation lists were an afterthought that the browsers took fore
Re: Expiry was implemented before revocation, thou (Score:2)
That is correct. The theory of revocation and the practical implementation were not aligned at the beginning. The design catered to both systems, with expiration being the online and offline usable last line of defence. Also, the clients/servers could simply use the expiration as a suggestion, and how and when they dishonoured the cert was browser specific. This allowed browsers to let the user optionally ignore expired certs and in more recent times allow browsers to force a maximum time limit that might b
Re: (Score:1)
Re: (Score:1)
I'd like to see the GAP analysis of people typing on their phones without the full use of the shift key.
Management principle: write once well, efficiently skimmed many times by people who value their time.
Management principle: write once sloppily, consider yourself lucky to be read by anyone, ever who regards time as a precious commodity.
Re: (Score:1)
because for revocation you have to check again. If you don't have access to the CRL, or actively check, you succeed where you shouldn. Expiry is the "safeer default", as a compromised cert is at most (in let's encrypts case) 90d valid.
Wrong goal (Score:2)
If a key is compromised, you change the locks, which is the equivalent of revoking a cert
The goal is to ideally ensure that the key never gets compromised. To use your analogy imagine you have a lock but lock-pickers are able to work on picking the lock 24/7 without interruption - basically what happens on the internet. Done properly it's more secure to rotate the locks periodically than it is to keep the same lock until it gets picked. If you wait until it is broken to do anything then whatever you were protecting is already taken and it's too late. You are bolting the gate after the horse
Re: (Score:2)
You have a point, but it would take a "standard desktop" (as defined by Digicert) around 1.5 million years to decrypt a 2048-bit cert.
https://www.digicert.com/TimeT... [digicert.com]
Let's be generous and round that down to a cool million years and give the bad guys a 1000 node cluster, and we are looking at 1,000 years to crack a cert. Looking at that, I'm comfortable with protecting low-value sites with a 2 year cert. Banks and credit card agencies should be more paranoid. I'm much more worried about someone compromis
Re: (Score:2)
To scale your lock analogy up to match the complexity of modern crypto... it really doesn't matter whether the lock-pickers can work 24/7 without interruption for one year or three, because it's going to take them a billion years on average to find the right combination.
You're more likely to drop the slip of paper with the new combination on it (or accidentally commit your private keys to a public git repo) than they are to crack the lock.
Re: (Score:2)
Major sites still manage to forget to renew certificates (Ubisoft's Uplay PC client couldn't retrieve news a few weeks back because of this).
Thanks, that is a great argument for upping the certificate lifespan to 50 years. When the certificate finally expires the game is long dead and no-one will notice.
Re: (Score:2)
more so, we already have CRL and OCSP which can be used to verify if the cert has been revoked
Re: (Score:3)
Certificate strength (like passwords) do degrade over time. Without an expiration time, most sites would be happy to never invest in a new certificate since SSL1.0 and they'd still call it compliant because HIPAA and other regulations don't have any technical specifications to follow. The industry has to force the government(s) and large entities to comply with better security standards or your privacy will be off even worse than it is now.
Re: (Score:2)
That is not true there are very big differences:
Passwords: By extending the date for use you allow increased complexity in the eyes of the user's memory and therefore increase security (no post-its under the desk). And the modern day guidelines for this actually reflect this (my own employer just changed password policy from monthly to yearly changes).
Certificates: Well TFS expressly points out the rationale behind reducing the timing. Certificates when compromised are often not easily discovered and when r
Re: (Score:2)
Additionally there's no actual downside to changing certificates regularly as people are unaffected and the processes behind them manage the change automatically.
...Unless those processes are balefully inadequate in their security procedures and thrown together ad hoc. Which a lot of them are.
Also one of the things missed by these engineers is that almost nobody can afford boutique services that cater to non-web-server uses... most people just use certificates they registered as if they were registering a web server certificate. These can be in rather hard-to-automate setups, e.g. burned into flash that needs manual intervention to be altered. So if they want to
Re: (Score:2)
Why not make it three days? (Score:5, Insightful)
Or even one? I mean, if shorter is better why not just move to a regime that requires automated tools like certbot to even work.
I'm still waiting for Google's final play - the one where *they* become the root certifying authority for every site on the web. And it'll somehow tie in with AMP and their ad-revenue regime, all while they proffer some bogus technical justifications for requiring the move...
no star certs and each ipmi / swtich needs it's ow (Score:2)
no star certs and each ipmi / switch needs it's own cert + direct internet access.
Re: (Score:2, Insightful)
An expiry on the order of 3 to 18 months still allows a relatively secure manual renewal system to be implemented. The organisation I work for has a monthly renewal process (certs expire in 3 months). Each month the smart cards are presented to the HSMs to generate the new certs and keys to trigger the renewal from the certificate authority. The monthly process means it doesn't get forgotten, and if a month is missed for whatever reason (eg. hardware or comms problems), then the certs still work for 3 month
Re: (Score:2)
Seven days is about the minimum that developers could sanely use to test things in the preprod/staging environments to test infrastructure changes etc, otherwise you're emailing and swapping about test certificates constantly and things get messy fast. 90 days is probably too long, but three days is too short. You can already import cerbot libraries for all the major programming languages so there's not even external config anymore, assuming you're not just using letsencrypt at the ingress controller level
One problem with this logic... (Score:3, Interesting)
(and not the only one)... is that if 397 days is better than two years then 100 days is better than 397 and 10 days is better than 100 and 1 day is better than 10 and.... why not just treat revoked certs as dangerous rather than trying to second guess how long you can keep trusting one?
Re:One problem with this logic... (Score:4, Interesting)
Ah, the old induction argument. If a man with no hair is bald, and a man with n hairs is bald implies the man with n + 1 hairs is bald, then all men are bald. Put a metric on your induction and it is easy to say that anything below 397 days is too short. The 397 seems arbitrary. Maybe there is some empirical testing that shows this minimizes some metric of bad certs and maximizes some metric of utility, then we can all argue over the metric.
Re: (Score:2)
Indeed - although it seems to be more about flexing muscles and seeing who is actually in control of cert parameters than it is in actually securing the system. Securing the system would best be served with actually properly dealing with revoked certs.
Re: (Score:2)
Re: (Score:2)
The 397 seems arbitrary.
It's not really arbitrary - it's the max number of days in a year + max number of days in one month. I'm guessing the intent was to allow a month's grace period for renewing a one-year cert before it goes bad.
Re: (Score:1)
Re: (Score:2)
and 1 day is better than
Except you are applying a criteria off a single variable to a multivariable system. 1 day is demonstrably not better than 10 for certificates due to reasons completely different to those which mean 100 days is better the 397.
Global warming analogy (because cars are so old-slashdot): We need to reduce global warming, so -0.1C is better than now, and -1C is better than -0.1C so clearly the end game is that we introduce the next iceage for the good of humanity. Of course not, what I said just now is stupid.
ssl cert racket needs thrown in the garbage (Score:2, Insightful)
Alternatives that don't involve paying central authority exist, the world needs that kind.
Let's Encrypt is useless for many important things
Re: (Score:2)
Let's Encrypt is useless for many important things
If you are going to diss the alternatives that exist, at least give your reasons. "Many important things" means nothing. Lets Encrypt fits the purpose for standard server certificates. For things that deserve investment for extra security, you can find a commercial CA. For things you want to keep private, you have the option of running your own internal CA. Seems fair to me.
Increase costs on both ends (Score:2)
If the certificate authority is REALLY doing their job, every renewal involves verifying who people claim they are. Things like Let's Encrypt are special - you don't give a damn who people are, you just want something that enables encryption.
When you have multiple domains that need "real" CA-signed certificates across multiple servers, this is a PITA you want to do as little as possible.
Renewal coming up in 90 days, and the person listed as responsible for the domain is in his office? If you take advantage
Short cert lifetimes are OK with IPv6 (Score:1)
Try that with thousands of certificates. (Score:3, Interesting)
People who want shorter expiry probably don't deal with closed off environments with thousands of certificates that don't have direct access to the CA for signature, over hundreds of different middleware, front ends and backends, all with different renewal procedures, including appliance boxes with no clear automation tools.
Luckily, we're finally trying out a certificate management tool, but it seems it will require a lot of in house scripting for multiple of our environments, as the "out-of-the-box" support is limited in what software products they support.
Re: (Score:2)
If you're in a closed off environment why do you need an external certificate authority to grant you certificates so your 3rd party customers are safe to access a system they can't get to?
i.e. Run your own CA in your closed environment.
Re: (Score:2)
We do run our own CA. You still have to renew certificates, and for some reason, our security audit team doesn't like the idea of 10 year signatures, so we're stuck with 2 years max.
Also, most of the systems don't have direct access to the CA for auto-signature. Our environnement is multi-segmented and isolated. Unless we start running a CA per zone (which would create a ludicrous amount of CA certificates to deploy), there's just nothing feasable about auto-renew solutions as they exist today.
Re: (Score:2)
People who want shorter expiry probably don't deal with closed off environments with thousands of certificates that don't have direct access to the CA for signature
Do these closed environments have access to the relevant CRL/OCSP servers? Or do they just trust that keys are never compromised and certs never revoked?
Re: (Score:2)
The clients do. The servers don't really need to know if their own certificate is revoked, only systems connecting to it.
The CRL/OCSP server is also different from the CA signature environnement so even that wouldn't help.
Certificate expiration is a bad idea (Score:4, Interesting)
I disagree with the notion certificates need EVER expire without specific articulable cause. Relying on time rather than active measures as a pressure valve does not enhance security it's an insane concept that significantly weakens it.
Also disagree with notion of forcing people to use automated software to manage trust relationships.
There are added political dangers in reducing renewal periods makes certificate owners even less power to stand against policy whims of those with power of control issuance.
Reducing renewal periods makes configuring systems to trust specific certificates rather than undeserved blanket trust of third parties more difficult to achieve.
Unnecessary rotation is a source of noise that can be used to mask security issues in transparency logs for the two people on earth who even bother to monitor them.
Personally I believe what needs to happen is that registrars need to be the ones issuing certs as a standard inseparable part of domain ownership and DV CAs should themselves become registrars or disappear.
Why CA opposition? (Score:3)
This is seems counter intuitive, more regular renewals mean more regular fees, so why do they oppose this?
No (Score:1)
Certificates should NEVER expire. End-of-Line. Once signed that signature should be good until revoked.
Only approved ads (Score:1)
Want to do something on the internet that needs encryption from ads, social media, business competitors, software updates, payments, sales, blocking cyber crime attempts, games, your own ads, other nations security services?
Thats a 397 day certificate for people who really need encryption...
All certificates are equal, but some ad brand certificates are more equal than others.
Self-signed (Score:1)
No renewal for you if you are the opposition (Score:1)
uhh... (Score:2)
Short time BS again. (Score:1)
They want it short so they can charge again for a cert. People that say - keep it short aren't the ones that have to maintain thousands of servers. Screw that, should be 10 years. Machine should be replaced by then.
As for the mis-issued and revoked certs - why is this even an issue? If it's revoked then don't let them use it. You know, why there is a revoked list in the first place. If it's mis-issued - revoke it.
Otherwise, it expires, things grind to a halt. This is unacceptable today. All because a stupid
GlobalSign (and other CAs?) are sprooking this (Score:2)