Apple deprecates SHA-1 certificates in iOS 13 and macOS Catalina

Apple joins Google, Firefox, and Microsoft in banning SHA-1-signed TLS certs.
Written by Catalin Cimpanu, Contributor

More than two years after Google, Firefox, and Microsoft have taken steps to deprecate TLS/SSL certificates signed with the SHA-1 algorithm, Apple has finally announced a similar measure this week.

In a support page published last night, the Cupertino OS maker said that starting with iOS 13 and macOS 10.15 (Catalina), the two operating systems won't support HTTPS traffic that uses TLS certificates signed with the SHA-1 algorithm.

"TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm," the company said. "SHA-1 signed certificates are no longer trusted for TLS."

All HTTPS traffic -- from apps and the Safari browser -- must now use a TLS certificate that has been signed with at least the SHA-2 algorithm, Apple said.

Took a while...

Apple was the last major browser maker that was still supporting TLS/SHA-1 certificates. Google removed SHA-1 support from Chrome with the release of Chrome 56, at the end of January 2017; Firefox removed SHA-1 support in Firefox 51, also released at the end of January 2017; and Microsoft dropped support for SHA-1 in Edge and Internet Explorer in mid-2017.

Browser makers abandoned SHA-1 after a team of academics broke the SHA-1 hashing function in February 2016. Their research showed that it was possible, albeit at high costs, to create two files with identical SHA-1 hashes, allowing for file forgeries.

Creating SHA-1 collisions is currently extremely expensive, but the cost of launching an SHA-1 attack is expected to go down in the coming years.

Besides dropping SHA-1-signed TLS certificates, Apple also announced other minimum requirements for TLS communications:

  • 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 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.
  • TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID. [for TLS server certificates issued after July 1, 2019]
  • TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate). [for TLS server certificates issued after July 1, 2019]

Apple WWDC 2019 keynote: Scenes and surprises

Related cybersecurity coverage:

Editorial standards