Safari to reject HTTPS certificates with over thirteen months validity
Apple places a hard cap of 398 days on certificate validity lengths, hoping to bolster safer, more secure browsing.
Apple has announced that starting on September 1, Safari will reject any website that hosts an HTTPS certificate with more than 398 days of validity. Certificates issued before September 1 will not be subject to the change until the date of their next certificate renewal.
HTTPS certificates are designed to make sure that your connection to a website is safe and secure. If you visit a site with a rejected certificate, you'll see a privacy warning.
For the average user, this shift ensures that you're only interacting with sites that have the latest encryption and security standards. Keeping up with security standards is highly critical for websites that manage the health and financial information of their users.
The announcement took place at the 49th CA/Browser Forum, a voluntary consortium of certification authorities, according to The Next Web.
Certificate authorities routinely would issue certificates that were valid for up to five years but had reduced it to just over two years in 2017.
Apple has announced that starting on September 1, Safari will reject any website that hosts an HTTPS certificate with more than 398 days of validity. Certificates issued before September 1 will not be subject to the change until the date of their next certificate renewal.
HTTPS certificates are designed to make sure that your connection to a website is safe and secure. If you visit a site with a rejected certificate, you'll see a privacy warning.
For the average user, this shift ensures that you're only interacting with sites that have the latest encryption and security standards. Keeping up with security standards is highly critical for websites that manage the health and financial information of their users.
The announcement took place at the 49th CA/Browser Forum, a voluntary consortium of certification authorities, according to The Next Web.
Certificate authorities routinely would issue certificates that were valid for up to five years but had reduced it to just over two years in 2017.
Comments
Why make it 13 months instead of 24?
https://twitter.com/near_nyan/status/1231696509634105344?s=20
They have completely lost the plot at this company. Obviously some bizarre takeover occurred in the last few years where lawyers are now running software development.
And again, why draw the line at 13 months instead of 24? Is there any study that supports this being a more appropriate period for encryption and security standards? Why not apply a policy proactively and appropriately at such times when there is a notable improvement in encryption and security standards?
I still need to reboot my web servers once every 3 months so the new certificate is picked up on. Not sure why I haven't managed to properly automate the renewal, but I'll figure it out one day.
Another issue is that companies selling certs usually offer better pricing for 2 year or more validity certs.
I can't believe that Apple wouldn't provide a "Proceed Anyway" ability after warning you that the certificate is too old. Of course, you'd get it on every website that had an old cert.
It can only work if the industry as a whole agrees on such a switch, and executes it at the same time.
Let Darwin rule the 'net. If you're not smart enough to avoid sites with dodgy security, that's your problem.
Why should Apple worry about the security of uninformed Safari users at the expense of hampering war hardened 'net veterans? Let 'em look out for themselves. Let the clueless be cast out and room made for real 'net users.
And yes, that's all /s.
Oh, puh-leeze. How often does that happen. TIme's up. Almost never, if ever, unless you define 'same time' as 'years'.
I believe Apple played a large part in moving sites away from Flash. Some still use it, and I don't need them.
Somebody's got to do something to improve security. I know– maybe we and Apple shouldn't worry about it one byte. I'm sure if left alone, sites will get it all sorted in a timely manner, and we'll be no worse off for the wait. (Yes, more /s.)
To get a certificate, the user (an end user or an administrator of a service such as a web server):
1. Generates a pair of keys (one public, one private) using a particular algorithm
2. Submits a request to a certifying authority including the public key
3. Waits while the CA performs any identity checks they choose to undertake
4. Receives a certificate from the CA that has been signed to show validity
The certificate is, in essence, approval that the pair of keys is unique and sufficiently complex to be used with current encryption protocols.
The weak link in the chain, however, is the encryption protocol used in conjunction with the keys. Recent exploits have mostly involved controlling the negotiation between the browser and the server to use an older encryption protocol that was more easily broken into, or using a buffer overflow to retrieve sensitive information that would compromise the session. You can read a good summary here: https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/
Renewing the certificate is insufficient to prevent such attacks, and thus does not ensure that the site is complying with the latest standards. It is a bit more likely that forcing administrators to renew certificates more frequently will encourage them to patch their servers on an appropriate schedule, but that cannot be relied upon.
Like everyone else here, I am concerned that this move will cause pain that exceeds the intended benefit. But Apple have a significant amount of clout, and if this change to Safari results in more attention being paid to servers by qualified administrators then ultimately it's worthwhile.
This might be helpful (item 8 on the list) although it's dealing with a Windows server, not a Mac: https://bluefeathergroup.com/blog/how-to-use-lets-encrypt-ssl-certificates-with-filemaker-server-for-windows-v2-0/
The Mac version is here: https://bluefeathergroup.com/blog/lets-encrypt-ssl-certificates-for-filemaker-server-for-mac/
Feel free to ignore all the parts about FileMaker Server, since they don't apply to your use case.
They will create another "you're holding it wrong" event for themselves.