Apple Drops Support for SHA-1 Certificates in macOS Catalina and iOS 13

In a new support document, Apple has indicated that macOS Catalina and iOS 13 drop support for TLS certificates signed with the SHA-1 hash algorithm, which is now considered to be insecure. SHA-2 is now required at a minimum.


Apple says all TLS server certificates must comply with these new security requirements in macOS Catalina and iOS 13:
  • TLS server certificates and issuing CAs using RSA keys must use key sizes greater than or equal to 2048 bits. Certificates using RSA key sizes smaller than 2048 bits are no longer trusted for TLS.
  • TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm. SHA-1 signed certificates are no longer trusted for TLS.
  • TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted.
Effective immediately, any connections to TLS servers violating these new requirements will fail and may cause network failures, apps to fail, and websites to not load in Safari in macOS Catalina and iOS 13, according to Apple.

Google, Microsoft, and Mozilla all deprecated SHA-1 certificates in 2017.

Related Roundups: iOS 13, iPadOS, macOS Catalina
Tags: Safari, SHA-1


Top Rated Comments

(View all)
Avatar
2 weeks ago
Nice to see them doing this.

Planned obsolescence...smh...


For an insecure encryption algorithm? I would hope they'd deprecate it (following Google, Firefox etc.).
Rating: 15 Votes
Avatar
2 weeks ago

For an insecure encryption algorithm? I would hope they'd deprecate it (following Google, Firefox etc.).


There was an implicit /s in vicviper789's post ;)
Rating: 5 Votes
Avatar
2 weeks ago

Planned obsolescence...smh...


I get your point and share the frustration, but it's not warranted in this case.

Encryption algorithms have shelf lives, more or less. Weaknesses are periodically discovered that make them vulnerable to cracking or workarounds, as in this case. Generally these problems cannot be fixed in the way ordinary software is patched because the problems are not specific to any vendor and are simply fundamental flaws in the encryption mechanism; the only solution is abandonment of the encryption method and moving on to safer methods.

SHA-1 is over 25 years old and has been known to have problems since at least 2005. Deprecating encryption methods that are known to be too weak or vulnerable is the right thing to do, and if anything, this move is long overdue.
[doublepost=1559832487][/doublepost]

I know, it's a disgrace. Little known fact: very few websites work well on Netscape Navigator either :mad:


I miss Netscape. ;)

I have to laugh at the 40-bit encryption we used in the late 90s (32-bit in some parts of the world). It wasn't thought overly safe even at the time, but that seems just silly, today.
Rating: 4 Votes
Avatar
2 weeks ago

There was an implicit /s in vicviper789's post ;)


It’s impossible to tell if someone is being sincere or sarcastic on the internet; which is why we have ‘/s’.
Rating: 4 Votes
Avatar
2 weeks ago

Planned obsolescence...smh...


I know, it's a disgrace. Little known fact: very few websites work well on Netscape Navigator either :mad:
Rating: 4 Votes
Avatar
2 weeks ago

I miss Netscape. ;)

I have to laugh at the 40-bit encryption we used in the late 90s (32-bit in some parts of the world). It wasn't thought overly safe even at the time, but that seems just silly, today.

Remember when encryption-enabled Netscape was considered a "munition", and was barred from export from the US, so they had a plaintext-only version for the rest of the world?
Rating: 2 Votes
Avatar
2 weeks ago
Planned obsolescence...smh...
Rating: 2 Votes
Avatar
1 week ago

Thanks, but I don't think that completely answers my question (unless I'm missing something).

For example, it's common practice in businesses to have their own root certificate authority. They then issue certificates signed by that authority to private, internal servers. Each client device is configured to accept that private root certificate as trusted and can therefore (when connected to the company's LAN either locally or by VPN) visit myprivatesite.local and the site will be secure and trusted.

If one is only issuing private server certificates in this context, there's really no need for SAN; but based on this MacRumors article Apple's devices wouldn't accept that because it needs that extension in the certificate. This makes no sense to me. Now I do get that it's standard practice to include the domain in the CN in the list of SANs, but not if there is literally one, single domain.

(The same is true for public web sites that only need a certificate for one domain, though public CAs will handle most of this stuff for the web site owner.)

Here's another thing not mentioned above:



Sure in most cases no one is issuing certificates for that long, but why restrict the validity period? If I'm setting up something internally I should be able to do what I want as I can always revoke the certificates later if need be.


Apple is simply aligning with requirements in place for public certificates.

SAN is required, even for one domain, on public certificates. The reason is Common Name only does not allow for use of name constraints and for identifying if it’s a DNS name or IP address.

825 days is current max lifetime for public certs. I say current because there is a desire to make this shorter.
Rating: 1 Votes
Avatar
2 weeks ago
So you're saying I should stop using MD5?
Rating: 1 Votes
Avatar
2 weeks ago
"Deprecated" is not a synonym for "removed."
Rating: 1 Votes
[ Read All Comments ]