That kinda sucks...
I guess that's the end of me renewing my certs 3 months before expiry...
From September 1, Apple software, from Safari to macOS to iOS, will reject new HTTPS and other SSL/TLS certificates that are valid for more than 398 days, plus or minus some caveats. If that sounds familiar, it's because we told you so in February before the iGiant even formally announced the policy. A month later, it revealed …
Not really. 398 days is over a year. 13months or there abouts. So your once a year on a certain date just becomes once a year on a rolling 12 months.
You could invest in some automation that renews them, replaces the old cert and emails you to say 'Job done and here are the results'.
It isn't all doom and gloom. If shorter cert lives stops a load of bots then isn't that a good thing?
Why would it stop bots? When a cert if found to be miss used it can be revoked and would not be usable again, oh, wait, Apple and also chrome doesn't check for certificate revocation by default so it loads websites faster. Maybe they should turn that on first to increase security.
Point one: I've seen people who've done setups like that, by accident of incompetence. (I.e. they threw everything they had into the certificate bundle, including now-expired intermediate and root certs.) Not all browsers handle this. I don't recall if it was Firefox who'd pick an arbitrary certificate chain and fail if that one wasn't valid. Could've been Chrome, too.
Point two: I've not checked in detail, but I wouldn't be surprised if certificate transparency logs reject requests to log a certificate for the far-future. (And I don't think trusted CAs issue un-logged certs anymore.)
... the two that I've worked with (Digicert and GoDaddy) don't do that. And to my knowledge, no 3rd party CA does that. They'll grandfather in the current 2 year certs, but switch them down to single year after they expire.
They'll auto-renew the certificate and charge you for the auto-renewal, but the onus is still on the purchaser to either install the new certificate, or step through the process to produce a new CSR, re-issue the cert, install it, etc.
Internally run CAs, on the other paw, are pretty much anything goes; if you want your internal CA to issue a certificate that has the same lifespan as the root CA's certificate, it'll do it, more or less. It's contrary to best practices, but who follows those? :)
No. Browsers check for the issue date and often will complain that a certificate has been issued for a date in the future. Now if the CAs were to issue you with a bundle and automatically renew (and not charge you for) the certificates over a period of time, then fine.
Besides, this only applies for certificates issued *from* 01/09/2020, *not* the ones before. So if you can still get a four-year cert on 31/08/2020, that'll be grandfathered in and you'll be safe from the certificate madness until 2024. :-)
Great though Let’s Encrypt is, it does not offer Organization Validated or Extended Validation certificated. Commercial organisations that want to have those (particularly the latter which shows up differently in many browsers) will need to keep buying commercial certificates. For the rest of us, Let’s Encrypt seems to work really well and makes configuring HTTPS on supported web servers pretty painless.
As chroot mentions in the other comment, browser vendors eliminated the visual differences between EV and non-EV certificates a while back.
Empirical experiments were run & demonstrated pretty conclusively that nobody was checking for (or cared about) the extra UI widgets browsers used to put in the address bar for EV certs. In general, people do notice negative security indicators ("not secure", red bars, etc) but they don't notice the absence of positive security indicators (like https markers).
(When I say "nobody", I mean really, nobody. Not just lay audiences: people in IT, programming and information security too.)
Anyone who can hijack the DNS can get a lets encrypt cert.
It then prompts the question of why not just admit that SSL has nothing to do with trust and it is there solely to confirm that the data hasn't been tampered with in transit.
I can see why it might be a good idea for certificates used over the web (with some caveats), but this is now a pain for internal-use certificates e.g my reporting website, because even if there's no problem having longer expiry date, people now start frothing at the mouth, because their browser tells them it's a problem. Worse, the vulnerability scanner is reporting it as a vulnerability and the security people are frothing at the mouth that we need to fix this problem. Although to be honest it's only https in the first place because they started frothing at the mouth that it wasn't encrypted.
I feel your pain on the last point. It's like people never heard of "mitigating factors" or "it's entirely unnecessary", they just see a "red mark" on some automated scanner and start frothing.
More often than not they have also over paid someone to run the report, and who is conveniently offering to offer paid advice on it.
"We can manage with the changes but we think that it is an unnecessary burden to our community and we should give more time to them to build their SSL automation, perhaps two more years."
Let's encrypt has been around for quite some time now. Just how long do these jokers need to get their --it together?
If we have have an embedded device which has a tiny web server (e.g. router, temp monitor, etc.) and it supports TLS, then do they expect the embedded server to renew its certificates every year or so?
For that to happen automatically, they need to be connected to the internet. However, many of these devices should never be connected to the internet.
Well you either had a mechanism already in place for updating the certificate every 27 months, so you just need to do this twice as frequently as you previously did, or you've spun up your own CA/certificate in which case as the article states, the new lifetime doesn't apply.
Many embedded devices have their own server and certificate baked in at the manufacturing stage and can not be updated by the end user. They will be broken by this change to the browsers.
Browsers at a minimum need to have a setting that allows long lifetime certificates to be used.
"Browsers at a minimum need to have a setting that allows long lifetime certificates to be used."
Perfectly valid comment - in fact browsers should have a setting that allows the user to decide which certificates (and indeed which TLS versions) to accept. I'm getting utterly frustrated with browser vendors making these decisions for me - I should be allowed to be in charge of my own security.
By all means have such measures enabled by default, but we should be able to turn them off if we want. In our lab, we're stuck with using some "unsupported" browsers due to compatibility issues, and are finding that increasing numbers of perfectly safe sites are no longer accessible due to certification "advances".
it doesn't even make sense. It should be the weakness / strength of the key length, cipher and hash that determines how long a key is acceptable for, not some arbitrary period of time.
A five year old cert generated with the same settings as a cert generated yesterday is no less secure in 99.9999% of use cases. Perhaps if I were a bank, NGO or government I might want to renew keys more frequently. But if I'm some guy maintaining a gardening website or small business then now I have 5x the work to keep my site secure for no benefit at all.
This is a fair view, but you have to remember they're looking in aggregate at all certificates, not the security of any one certificate. When you're asking questions like "How do we limit the impact of breaches against every cert we see?" you get different answers to the question "How do I limit the impact of breaches against the one cert I manage?". They're doing risk management at scale, not point-solution infosec. A 12 month lifetime is already common practice in financial services, for example, for exactly this reason.
>Now I have 5x the work to keep my site secure for no benefit at all.
I don't buy this. Mr Gardening Chap's website is almost certainly run by an external provider, who can trivially automate this and probably already has. Now instead of running renew-certs.sh every 24 months they're going to do it every 6 or 12 months. That isn't any more work - it's a change to your crontab and calendar reminder. If Mr Gardening Chap hasn't outsourced the running of his website, then he is probably more than competent enough to just use Let's Encrypt and get the same outcome.
If a 12 month cert is common practice in those that need it then why does it need to be enforced, even in aggregate? If the argument is that certain keylengths or hashes are weak, then deprecate those certs, don't impose blanket rule that even a strong cert needs to be replaced.
As for random gardening website (or the gazillion small websites) , they aren't going to be attacked by state actors using hash collisions. And perhaps some hosting providers do make it easy to renew keys. Many don't. And many that do charge money for it. Even free services like Let's Encrypt don't integrate with some providers and have a cost associated with setting them up. There is always a cost to this and it yields nothing to these sites.
Browser makers have it in their power to simplify this. They want sites to use encryption but they make the process more onerous.
If your provider charges for Let's Encrypt, move provider.
I'm with TSO host, formally something else and before that something again and no part of Go Daddy, and they do it for free. It' about 5 clicks to set up.
Oh and then you can always sign up, for free, to Cloudflare, and use their free service.
You missed the "for no benefit at all" part of the complaint. There's little difference between a hacker compromising a cert for 12 months vs 24 momths; that's still a huge window to operate in. The solution is for each browser to do its own revocation checking, but no browser wants to incur the .0001 ms delay it would take per-page to run the check. So they pull unilateral stunts like this to push the solution in a direction that impacts browsers the least, even when it doesn't actually address the problem.
And let's not pretend like let's encrypt will be the solution in every case. Plenty of up-to-date software still doesn't support certificate automation, and some software has horribly complex certificate renewal procedures. You may not run any of these services in your shop, but that doesn't mean your fellow industry professionals should suffer for zero added security benefit to the industry.
So a Cert Issued five years ago with a secure algorithm is theoretically less secure than a cert issued yesterday, not because the certificate itself is more vulnerable, but because the private key has had more time to leak, or be compromised. If you never rotate the private key, then absolutely, renewing the certificate isn't actually more secure, and your statement holds. And I know that it is easy to renew a certificate with the same private key using some of the comercial certificate providers (I've done it more than once in the past).
Of course generating new keys is also fraught with caveats and gotchas, so in theory generating a new private key every time you get a new certificate is more secure, in practise there are circumstances where that may not be true.
Or in other words, it's complicated.
In general automating certificate renewal in a process that generates a new key each time is more secure, and less error prone, than having manually generated csr's and certificate rotations.
Again, everybody follows the small marketshare player Apple.
They sell less than 15% of all smart-phones, yet considered a monopoly. I guess they redefined what monopoly means :-)
Now, when will we get warnings in Windows about clipboard snooping ? Something Apple will warn about in next gen OS-X and iOS.
Chrome, Safari, and Fire Fox account for over 80% of browser market share according to StatCounter Global Stats. If you operate a public facing website, the shorter cert expiry is a done deal. The only thing left for Microsoft is to decide if they want to be consistent with the other browser makers.
So what happens if my 2 year feet is still valid for 390 more days by sept 1st? Is it still valid as it was valid from before sept 1st?
What happens if on sept 2nd I create a very valid for 400 days, will the browsers accept the feet as valid on sept 10th as it’ll be well within the 398 days it will it be rejected as it’s validity is greater than 398 days.
So when did Apple start to dictate to the end user about website certifications and how long they are supposed to be? The length of time should be a matter of administration, not being shoved down people's throats. This, and other reasons, are why I do not purchase Apple products. Apple caused this, they should bear the burden of their actions. But they won't, so the rest of us has to deal with the fallout of their decisions.
Browser makers could easily add in a certificate revocation check that would solve this problem far better than just shortening the cert lifespan. There's a standard for this already. But no browser wants to incur the .00001 ms delay it would take to check a revocation server, when they can push the burden to your local IT department instead (even when that doesn't solve the problem nearly as well). Browser makers held a ballot, the ballot failed, and so they made this unilateral move to address the problem in the laziest way possible that impacts them the least.
There are plenty of self-hosted services that don't play well with Lets Encrypt and can't yet be automated. Hell, Atlassian products don't even officially support SSL certs; you have to go through some murderous third-party hack in order to get the cert installed on each server every few years (now every year I guess).
The worth thing about this "solution" is that 12 months is still plenty of time for a malicious actor to retain your cert and do some serious long-term damage, so this move doesn't even address the problem. A robust certificate revocation system is the best way to solve this problem, and the browser makers are worried that the technical public will figure that out.
Biting the hand that feeds IT © 1998–2020