Safari Will Stop Trusting Certs Older Than 13 Months (theregister.co.uk) 115
"Safari will, later this year, no longer accept new HTTPS certificates that expire more than 13 months from their creation date..." writes the Register.
Long-time Slashdot reader nimbius shares their report: The policy was unveiled by the iGiant at a Certification Authority Browser Forum (CA/Browser) meeting on Wednesday. Specifically, according to those present at the confab, from September 1, any new website cert valid for more than 398 days will not be trusted by the Safari browser and instead rejected.
Older certs, issued prior to the deadline, are unaffected by this rule.
By implementing the policy in Safari, Apple will, by extension, enforce it on all iOS and macOS devices. This will put pressure on website admins and developers to make sure their certs meet Apple's requirements — or risk breaking pages on a billion-plus devices and computers... The aim of the move is to improve website security by making sure devs use certs with the latest cryptographic standards, and to reduce the number of old, neglected certificates that could potentially be stolen and re-used for phishing and drive-by malware attacks... We note Let's Encrypt issues free HTTPS certificates that expire after 90 days, and provides tools to automate renewals.
Long-time Slashdot reader nimbius shares their report: The policy was unveiled by the iGiant at a Certification Authority Browser Forum (CA/Browser) meeting on Wednesday. Specifically, according to those present at the confab, from September 1, any new website cert valid for more than 398 days will not be trusted by the Safari browser and instead rejected.
Older certs, issued prior to the deadline, are unaffected by this rule.
By implementing the policy in Safari, Apple will, by extension, enforce it on all iOS and macOS devices. This will put pressure on website admins and developers to make sure their certs meet Apple's requirements — or risk breaking pages on a billion-plus devices and computers... The aim of the move is to improve website security by making sure devs use certs with the latest cryptographic standards, and to reduce the number of old, neglected certificates that could potentially be stolen and re-used for phishing and drive-by malware attacks... We note Let's Encrypt issues free HTTPS certificates that expire after 90 days, and provides tools to automate renewals.
self signed certificate internal use may be an mes (Score:2)
self signed certificate internal use may be an mess.
Re: (Score:2)
Re:self signed certificate internal use may be an (Score:4, Insightful)
Re: self signed certificate internal use may be an (Score:2)
Apple announced that beginning Sept. 1, newly issued publicly trusted TLS certificates are valid for no longer than 398 days.
The statement is specifically âpublicly trustedâ(TM) TLS certificates, rather than just âTLS certificatesâ(TM). This could mean that certs derived from commercial CAs trusted
Re: (Score:2)
Remember the Apple "1984" commercial? Apple (and Google too) is the new Big Brother. In a year, we can celebrate the first glorious anniversary of the Information Purification Directives.
Re: self signed certificate internal use may be an (Score:2)
Re: (Score:1)
Re: self signed certificate internal use may be an (Score:1)
this will make apples app store only suck even mor (Score:2)
this will make apples app store only suck even more
Re: (Score:3)
The summary mentions Let's Encrypt, a perfectly good domain-name-validating (DV) certificate authority. It offers an automated renewal process useful for any website open to the public or otherwise accessed through the Internet.
One limit of LE and other public CAs affects users of machines on a home LAN, which are unlikely to have a fully qualified domain name (FQDN) because the average householder is unlikely to own a domain name. CAs don't issue certificates for private IPs or names, such as those in 192.
Re: Make the whole Internet a DRM subscription... (Score:2)
No problems using a fqdn in your private net if you run your own DNS.
Re: (Score:2)
There's no reason to use Let's Encrypt for an internal network. A lot of people have got hung up on Let's Encrypt, but they are just a free CA that is actually well enough trusted by the browsers. It makes no sense for internal networks whatsoever.
I will say that the state of internal network https serving is crappy. Yes, if you are so inclined you *can* run your own CA for an internal network. You can even skip DNS and use IP for subject or SAN fields if desired.. However no one makes it utterly trivi
Re: (Score:2)
You can build your own cert infrastructure -- if you were so inclined. Generate a self-signed cert, generate some certs for other devices, have the self-signed cert sign them. You can do it with OpenSSL. Then import the original cert as a trusted cert into each of your machines at home.
You can have the CNs or Hostnames be anything you want them to be...
Re: (Score:2)
You can actually do this with Apple's own Keychain Access utility which, in this respect, is acting as a front end to OpenSSL. It's not a blindingly obvious bit of the interface, but it's there. The big thing that it has trouble with is setting up the SAN fields, which browsers require.
Re: (Score:2)
except you cant you .dev or chrome will have a hissy fit.
Re: (Score:2)
Re: (Score:2)
You don't need to create TXT records, that's just one option... Having the ability to deliver HTTP traffic on the hostname will work too.
Re: (Score:2)
Having the ability to deliver HTTP traffic on the hostname will work too.
Provided you don't live in a country that puts even businesses behind CGNAT [slashdot.org].
Re: (Score:2)
Letsencrypt works fine over ipv6.
Re: (Score:2)
Nearly two years ago, you wrote:
How much has the availability of IPv6 service from ISPs in Myanmar and other developing countries improved in the past 23 months?
Re: (Score:2)
Now one of the 4 major ISPs provides it, and national usage has reached 10% (it was negligible 23 months ago).
https://stats.labs.apnic.net/i... [apnic.net]
Re: (Score:2)
IP addressing has nothing to do with SSL certification
I presume we are talking about the typical scenario of putting your IP addresses in SAN so that browsers can access your SSL service by IP and still get validation. In that case a public CA should reject anything in 10/9, 172.16/12, 192.168/16, and fd::/8.
I think you re right that if you want any certificate that would actually work with browsers for an internal network, your only options are:
-Own a domain to do TXT validation records to Lets Encrypt
-Buy certs from another CA
-Do your own CA and only worry
Dynamic DNS with PSL+TXT (Score:2)
And no, you can't use a dynamic DNS provider as you don't own the parent domain nor the means to make TXT validation records either.
In theory, a dynamic DNS provider could offer subdomains under a domain name on the Public Suffix List, TXT record support, and programmatic updates (PSL+TXT+API), which would be sufficient for use of Let's Encrypt. In practice, I haven't read about dynamic DNS providers that offer PSL+TXT+API other than Duck DNS, and I'm interested in seeing evidence as to whether Duck DNS will remain in operation long enough to recommend the provider for long-term use by home users.
Re: (Score:2)
If you're techy enough to be playing around with rPis, NUCs etc, then you should be able to figure out how to find a free dynamic DNS provider that lets you set TXT records in order to do letsencrypt DNS authentication, or any old DNS provider if you don't mind opening up port 80 on your router.
Re: (Score:2)
If you're techy enough to be playing around with rPis, NUCs etc, then you should be able to figure out how to find a free dynamic DNS provider that lets you set TXT records
That might be true for the specific case I mentioned, namely use of a Raspberry Pi or NUC. But I have discovered that a lot of free providers either:
A. don't support TXT records,
B. are not on the Public Suffix List and thus are limited to 20 certificates per week across the whole domain (which other users of the same service will have inevitably already used up),
C. require a CAPTCHA for updates in order to block use of automated tools that do not display the provider's advertising, or
D. have since shut down
My certs ... (Score:2)
... (Two! Two mints in one!) expire after one year.
And in tomorrows news ... (Score:3)
Apple buys a Certificate Authority so it can cash in on the movement towards "short term" Certificates.
"There's Gold in them thar Certificates", Tim Cook announced, "because now people will pay the same price as they used to in order to buy a bloody big integer good for only one year, whereas in the old days, a bloody big integer was good for three years. Apple is moving to take advantage of this new trend in the bloody big integer marketplace."
Re: (Score:3)
Apple buys a Certificate Authority so it can cash in on the movement towards "short term" Certificates.
"There's Gold in them thar Certificates", Tim Cook announced, "because now people will pay the same price as they used to in order to buy a bloody big integer good for only one year, whereas in the old days, a bloody big integer was good for three years. Apple is moving to take advantage of this new trend in the bloody big integer marketplace."
Did you read the summary?
The aim of the move is to improve website security by making sure devs use certs with the latest cryptographic standards, and to reduce the number of old, neglected certificates that could potentially be stolen and re-used for phishing and drive-by malware attacks.
They have a point. But please feel free to explain to us why keeping years old certificates with outdated crackable cryptography in use is a good thing for everybody.
Re: (Score:3)
You are assuming that 13 month+ cryptography is cracked by default.
Speeding up the process isn't much better. When having to move faster like that, and you'll introduce more bugs and errors due to trying to move faster in a time crunch. (Or sites might just drop HTTPS, and default back to http as it is easier for them)
Newer isn't always better. Time-tested can be a better option.
As per the article:
It has been noted that by increasing the frequency of certificate replacements, Apple and others are also making life a little more complicated for site owners and businesses that have to manage the certificates and compliance. "Companies need to look to automation to assist with certificate deployment, renewal, and lifecycle management to reduce human overhead and the risk of error as the frequency of certificate replacement increase
So either the sites have to do it themselves (which I pointed out the issues there), or outsource it to another
Re: (Score:2)
So I don't like a browser unilaterally deciding to ignore the certificates expiry, but there seems to be a likelihood that CAs will go down this route. All that said, the same forces driving no-more-than-year certs will also drive 'screw your http without tls' experience, so there is unlikely to be a big move away from https.
A new certificate does not necessarily mean new cryptography. The signature has moved to SH256/SHA512, but other than that, the certs are largely generated much the same way they were
Re: (Score:2)
The biggest risk for old certs is that the private keys are generally lying around on disk storage somewhere unencrypted and will likely walk out the door unprotected one day.. Additionally, some vulnerability manages to give an attacker a copy of a private key without the cert owner even knowing. Capping the validity of those unknown exposures is some mitigation.
I have never once in my entire life witnessed any CA reject a CSR request because the same private key as last time was used to reissue it. There isn't even a protocol to communicate past keys across all of the global overlapping trust anchors.
Capping validity without enforcing an arbitrary constraint on private key reuse undermines this entire argument. It becomes just another lame excuse for otherwise indefensible behavior.
Re: (Score:2)
Sure, strictly speaking someone could just reuse same private keys unless the CAs all track previously signed public key and reject attempts to reuse (which I wouldn't be surprised if they do start doing just that).
That said, it is at least fairly likely that a strategy to generate a new CSR will have the organization doing a new key. It's not really any easier to reuse the same key (you have to replace the certificate file everywhere, might as well replace the existing key), and I think most people would
Re: (Score:2)
Re: (Score:3)
They have a point. But please feel free to explain to us why keeping years old certificates with outdated crackable cryptography in use is a good thing for everybody.
When intermediate certificates no longer have over a decade of validity to say nothing of roots pushing thirty years come back and make the same arguments.
Currently what's the limit you can get from a CA ...2 years validity tops?
Hard to believe such ridiculous arguments are seriously being offered.
Re: (Score:2)
They have a point. But please feel free to explain to us why keeping years old certificates with outdated crackable cryptography in use is a good thing for everybody.
Apple's policy has nothing to do with whether or not a particular algorithm or protocol has vulnerabilities. It's perfectly understandable that a browser would refuse to use known vulerable protocols or algorithms, but that is independent of rejecting the certificate outright. Apple's policy doesn't even have anything to do with the age of the certificate. They're saying they'll reject a brand new certificate, using only the latest algorithms, just because it's specified that it will be valid for 13 mont
Re: (Score:2)
For years now most certificate authorities have been offering a new cert on a regular basis at no additional cost. There is even a protocol to automate the updates called ACME.
It's been good practice to keep certificate lifetimes down for a long time now.
This is bullshit (Score:5, Insightful)
SSL certs for any amount of time should be just fine. This is just a fucking gimmick to increase revenue for the Commercial CA providers, which is already a fucking farce as it is. The amount of effort necessary to maintain a CA is very low and is sure as fuck has never justified the cost of many Certificates.
The correct solution for when a cert become compromise should be Revocation, but naturally this infrastructure was built like shit so it is not very reliable. As long as a Cert is not Revoked it should be considered as good.
A Certs validity period only serves as the same bullshit security theater logic that requires people to change their password periodically.
Like a password... a certificate is secure until it is compromised and requiring a frequent change is High Effort and Low Value process that only encourages people to become less secure not more. You can only push so hard before your efforts start to fucking backfire!
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Insightful)
The problem is KNOWING that a cert has been compromised, which isn't always detected in time. The whole point of expiration is that there are not old and potentially compromised certs laying around everywhere.
Sure, it would be *GREAT* to live in an ideal world where we got notifications every single time a cert is used in every single case, and could issue revocations from actively monitoring every single interaction with the cert and using that to detected non-sanctioned usages... But if we truly lived in
Re: (Score:2)
If you want to use an arbitrarily short time frame on your cert that is fine. In fact as the person requesting the cert I hope that you have a good reason for it and I am going to trust you to request that.
But this is different than the industry forcing you because they said so.
I also do not have a problem with using expiry for marking when certs do not want to be used past a certain time frame so you do not have to keep a large CRL, but that is not this.
If you plan on being up a long time... then there is
Re: This is bullshit (Score:2)
And what if a CA certificate is compromised?
Re: (Score:2)
Re: (Score:2)
The problem is KNOWING that a cert has been compromised, which isn't always detected in time. The whole point of expiration is that there are not old and potentially compromised certs laying around everywhere.
The problem with this argument is CAs accept CSRs signed with the same private key used earlier.
If the vector you are concerned about is operator unaware of compromise this measure not only fails to protect against an ongoing persistent attack it also fails to protect against continuation of benefits from an earlier one-time compromise even AFTER a new cert is issued.
Re: (Score:2)
Commercial CA providers. Both of them. There is Sectigo and DigiCert, all others are just brands.
Re: (Score:3)
The commercial providers are dying out, letsencrypt provides free certificates which work just as well and generally have better automation.
Re: (Score:2)
who pays for certs any more?
seriously, what is this, 2002?
Re: (Score:2)
Re: (Score:2)
You can only push so hard before your efforts start to fucking backfire!
I'd like to believe that, but remember what happened to Equifax. The whole leak thing was a PR trainwreck, but nobody seemed to care and the company's profitability has actually gone up.
This is for SECURITY. That means it's good by default and you can't dare argue against it. Everyone knows that.
Well crap. (Score:2)
I never thought I would utter the catch-phrase "Certificate-Industrial Complex."
Re: (Score:1)
Good name... Public CA has always been a scam and CA Compromises like Comodo were proof of it. And how long did it take for that to be resolved?
The Comodo compromise outed both he industry and consumers as ignorant and stupid sitting ducks. Consumers needs to stop bitching about getting fucked around... they seem to love it.
Re: (Score:2)
Re: (Score:2)
i for one always do 1 year because pricing changes and 2-3 year is too long
The entire CA industry stopped issuing 3 year certs on March 1, 2018. The maximum validity period for publicly trusted SSL certificates is currently 825 days.
What is that supposed to achieve? (Score:5, Interesting)
What is that supposed to achieve? Renewing and installing a certificate is itself a high-risk activity, and demanding it be done more often is likely to lead to more failures of the trust chain. I'm reminded of the Gateway Arch National Park that was changing the elevator cables that run up the leg of the Arch every 5 years; when one of them broke (fortunately no one was hurt) the elevator cable company's response was basically "you idiots: those are designed to last 50 years. Stop messing with them".
Re: (Score:2)
Make sure the latest CIA/NSA backdoors are included.
Re: (Score:2)
Renewing and installing a certificate is a high-risk activity when it's done irregularly.
Huge numbers of certificates are changed at 90 days or less without problems, specifically because people have put in the work to make it a low-risk, automated activity.
Safari? (Score:2)
You mean to tell me there are still people using the Safari browser?
Re:Safari? (Score:4, Informative)
Literally everyone on iPhones. Even if you use "another browser", it is just framed Safari.
Re: (Score:3)
You mean to tell me there are still people using the Safari browser?
I use it, actually. I switched away from Firefox several years ago when it seemed like Mozilla was shooting itself in the foot every other week. I’ve stuck with it because Safari’s developer tools are surprisingly good.
Re: (Score:2)
I still have a Safari installer for Windows but haven't installed it anywhere in years. The hardware dongle needed to run modern Safari just isn't worth it.
Re: (Score:2)
The hardware dongle needed to run modern Safari just isn't worth it.
It took me a couple seconds to grok this, but then I laughed.
Security of embedded devices out the window. (Score:5, Interesting)
I guess Safari will no longer be usable for talking to actually secure embedded devices.
Re: (Score:2)
They should be using ACME. https://en.m.wikipedia.org/wik... [wikipedia.org]
Re: (Score:3)
I don't let the management systems of my servers talk to anything off of the management lLAN at all, certainly not a certificate authority. They don't even have a potential route out if I can help it.
That's a good policy for less formal LANs, such as a home as wel, I fave a few devices at home that are configured via a web browser, but they do not talk to the outside world EVER.
This is a case of idiots who think they know better than the rest of the world destroying security in the name of security.
The whol
Re: (Score:1)
You can accept the self signed certificate. I don't know if Safari lets you permanently accept it, Firefox and Chrome do.
Re: (Score:3)
Re: (Score:3)
It doesn't. Furthermore, it won't use its password management tools on a site with an clicked through certificate, forcing people to use easily remembered/guessed passwords for all that internal stuff they really shoudl be keeping more secure. But it will still use its password manager for unencrypted sites, go figure.
Re: (Score:2)
It does, they just made is harder to do. You have to export the certificate and then import it to your local storage.
Re: (Score:2)
And for replacing check and click with that, they deserve to have their fingers slammed repeatedly.
Re: (Score:2)
There should be a flag to bring the check box back.
Re: Security of embedded devices out the window. (Score:2)
Unless theyâ(TM)ve gone really hardass recently they wonâ(TM)t even throw up the âdo you want to visit this terrible den of deception?â(TM) screen if the cert is trusted, whether by descent from a trusted root or individually. The ability to tell the browser to go ahead anyway is a convenience feature, since groveling around in the cert store is
Re: (Score:2)
Only in the sense that it's perfectly acceptable if you have to jack your car up and drop the gas tank in order to fill it. After all, if we make it any easier, people might do it without paying for the service^W^W^W^W^W^W^Wfill it with water. What's next, rip out the configuration menus and files and if you want to change anything, edit the source and recompile?
Re: (Score:2)
you don't need to run acme on the web server. you can retrieve the certs using sideband auth and ship the certs using whatever secure means you desire.
Re: (Score:2)
Nope. It's for a 32-bit 16.16 binary fixed point representation. It's nothing too unusual.
Re: (Score:2)
The concept of an embedded device that is actually secure sounds interesting. Is someone somewhere contemplating building such? If so, are they seriously contemplating accessing it with a web browser?
Headline is wrong. (Score:5, Informative)
EditorDavid's headline is wrong.
The story is that Safari won't accept certificates with an expiration that is more than 13 months from their issue date. So, if you get a new 2 year certificate after the cutoff date, Safari won't accept it immediately.
Nothing to do with age and all to do with length of validity.
Re: (Score:3)
Re: (Score:2)
To hell with the users. My enterprise defaults to two year certs, and ever since the SHA-1 debacle, we've been trying to space them out so they aren't all expired the same week. We've literally got hundreds of them.
If hate can be weaponized, expect the Apple campus to spontaneously explode one day.
Re: (Score:2)
You should really move to an automated system to renew your certificates. More than likely in the next few years a CA or an intermediary will be breached requiring you to immediately replace them all in a matter of hours or days. It's happened before, it will happen again.
If you're managing more than one website and still have to manually manage your certs, you're probably forgetting some.
Re: (Score:2)
You should really move to an automated system to renew your certificates.
Unnecessary connectivity is an unnecessary security risk. When I renew I also shop around to avoid being ripped off as much as possible.
More than likely in the next few years a CA or an intermediary will be breached requiring you to immediately replace them all in a matter of hours or days.
Perhaps but probably not mine so no action would likely be required of me.
Re: (Score:2)
Ten year old load balancers are likely no longer supported by the vendor that made them, and probably don't support modern versions of tls or modern ciphers. Before too long you'll have to replace them because modern browsers will end up deprecating the tls versions and ciphers your old load balancers do support.
Also why wasn't an ability to script and automate the devices a requirement during procurement? That's extremely short sighted thinking, and totally unscalable - how would you manage a large number
Re: (Score:2)
you are talking out of your ass. Some load balancer models do indeed have 10+ year support. The better load balancers are clusterable and the certs and domain info can be propagated.
Yet another Apple money grab (Score:5, Insightful)
Apple does not get to set the standard for certificates, yet they are attempting to do so by having their browser ignore standards and implement their own. A technique they are stealing from Microsoft. The goal is to generate more money selling certificates, not to improve security. If security were truly the heart of the issue, their browser would issue a warning when a cert is using a bad encryption method, which has nothing to do with the age of the cert.
Re:Yet another Apple money grab (Score:4, Informative)
The goal is to generate more money selling certificates, not to improve security.
Apple isn't a certificate authority and doesn't make a cent from certs. There is no monetary upside to this for Apple.
Re: (Score:2, Interesting)
Not only that, but shorter renewal times will encourage people to move to certificate providers with better automation - eg letsencrypt. I have a bunch of certs with them which renew every 90 days, the process is entirely automated and the certs get auto renewed a couple of weeks before they expire.
Re: (Score:2)
Not only that, but shorter renewal times will encourage people to move to certificate providers with better automation - eg letsencrypt. I have a bunch of certs with them which renew every 90 days, the process is entirely automated and the certs get auto renewed a couple of weeks before they expire.
Correct. Moreover, Let's Encrypt is *FREE* so the commercial certificate authorities lose money as their business model collapses. The story is more like what happened to newspaper's classified advertisement revenue post-Craigslist.
Re: (Score:1)
Re: (Score:2)
Yet another Apple money grab
Care to walk us through how this is an Apple money grab? Like literally show me the money trail here because I'm not seeing it.
Apple can go pound sand (Score:4, Interesting)
There was a vote and Apple lost handily. So naturally they had to go ahead and leverage their position in order to get their fucking way instead.
It's insane what anti-trust violations Apple is allowed to get away with. Locked down app stores, draconian limitations preventing competing browsers and software that displease Apple. The more power is allowed to be aggregated into the hands of the few the more corruption always follows.
The issue doesn't matter. Everyone can think it was a good idea or a bad idea. I don't give a f*** makes no difference. One company should not be allowed to have the power to unilaterally dictate terms to the world period.
Re: (Score:3)
One company should not be allowed to have the power to unilaterally dictate terms to the world period.
They don't. You just need the courage to vote with your wallet and stop using that company. It's not like the entire world is stuck with the Safari browser.
This situation is more like Tesla telling all their customers that they need to bring their keyless ignition fobs into a dealer every 13 months to get the code updated. Inconvenient as hell for their customers but they don't have the power to unilaterally dictate terms to the world. After about a year of this nonsense, their customers will just pur
Re: (Score:2)
They don't. You just need the courage to vote with your wallet and stop using that company. It's not like the entire world is stuck with the Safari browser.
Do you seriously think myself or anyone will be able to go to any CA and get a 2 year cert after this? Do you think they would dare issue it knowing the complaints that will follow?
This situation is more like Tesla telling all their customers that they need to bring their keyless ignition fobs into a dealer every 13 months to get the code updated. Inconvenient as hell for their customers but they don't have the power to unilaterally dictate terms to the world.
This analogy has no relationship to the issue at hand. Tesla bullshit has sway over only Tesla and their customers. This one decision affects the choices available to every website operator in the world whether they want anything to do with Safari or Apple or not.
Unstoppable force will meet immovable object (Score:4, Insightful)
Picture a company with a standard policy of 2 year certs. After a decade of corporate mergers the workflows, budget, and schedules have all been ironed out and aligned to handle this across all domains with no customer interruptions.
Company IT also issues only iPhones as approved mobile devices for connecting to the internal network.
Which will budge? Will they recall the iPhones and move to Android, or somehow get 30+ website managers, plus the finance team to completely redo their upgrade schedules? For a large, dysfunctional company the phone swap will be the path of least resistance...
Apple might have shot themselves in the foot here.
Re: (Score:3)
Apple issued certs coming soon! (Score:2)
Why not 13 weeks, or 13 days? Super secure site should renew every 13 hours, no?
Apple is basically saying they don't trust public CA's. Their next move, Apple issued certificates, just you wait.... And yes, they will be valid only 12 months at a time, so they can raise the price on you every single year, after the first 2 year grace period.