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

[MacRumors]

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.

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

 

[-Ray-]

Win!!

 

[vicviper789]

Planned obsolescence...smh...

 

[Sasparilla]

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.).

 

[SteveOfTheStow]

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

 

[keysofanxiety]

Planned obsolescence...smh...

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

 

[wtn]

"Deprecated" is not a synonym for "removed."

 

[Soba]

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

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.

 

[eatrains]

Planned obsolescence...smh...

Is this satire?

 

[darngooddesign]

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’.

 

[lunarworks]

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?

 

[Kaibelf]

Planned obsolescence...smh...

Any words about those other companies that did the same two years ago?

And we cannot assume this is sarcasm considering how people are on the internet.

 

[Dave-Z]

TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate.

This is the one that I don't quite understand. First, subject alternative name is an optional x509 extension; why is it now being required by Apple? Second, the whole point of the subject alternative name is to provide an alternative name to that which is found in the common name. I know that when creating multi-domain certificates we list the first domain (in common name) in the subject alternative name, but if we're only using one domain, why would we even add the subject alternative name to the certificate?

 

[Westside guy]

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?

I don't remember that. What I recall was US consumers being able to use 128-bit encryption in their browser while non-US consumers were limited to 40-bit encryption - due to the "munitions" argument.

It's why Korean banks developed their own ActiveX-based banking tech, a security headache which persisted long after Microsoft said to the world "Uh... please stop using that".

Fortunately someone eventually convinced the old farts who made those silly rules that there are plenty of smart people outside the US who are capable of writing their own web browsers capable of good encryption... so all setting those artificial restrictions did was hobble US-based browser makers.

 

[Superhai]

I don't remember that. What I recall was US consumers being able to use 128-bit encryption in their browser while non-US consumers were limited to 40-bit encryption - due to the "munitions" argument.

I remember this. And also that 128 bit versions of the browsers was widely available from piracy sites.

 

[mannyvel]

Goodbye, Oracle!

The only things that I remember that still use SHA-1 are older Oracle products and sites.

What's amusing is that it'll be easier to connect to unsecured sites than SHA-1 sites, which is ridiculous because SHA-1 sites are marginally more secure than unsecured sites.

 

[dontwalkhand]

Bye bye to the idea of configuring old sonicwalls with a Mac.

Sometimes when we order them they come with old OSes on them and we have to update them to get it to newer security.

Time to keep an old PC around for this purpose I guess.

 

[mdriftmeyer]

Great news. It's been broken for years.
[doublepost=1559847690][/doublepost]

This is the one that I don't quite understand. First, subject alternative name is an optional x509 extension; why is it now being required by Apple? Second, the whole point of the subject alternative name is to provide an alternative name to that which is found in the common name. I know that when creating multi-domain certificates we list the first domain (in common name) in the subject alternative name, but if we're only using one domain, why would we even add the subject alternative name to the certificate?

https://access.redhat.com/documenta...Standard_X.509_v3_Certificate_Extensions.html

An object identifier (OID) is a string of numbers identifying a unique object, such as a certificate extension or a company's certificate practice statement. The Certificate System comes with a set of extension-specific profile plug-in modules which enable X.509 certificate extensions to be added to the certificates the server issues. Some of the extensions contain fields for specifying OIDs

The PKIX standard recommends that all objects, such as extensions and statements, that are used in certificates be included in the form of an OID. This promotes interoperability between organizations on a shared network. If certificates will be issued that will be used on shared networks, register the OID prefixes with the appropriate registration authority.
OIDs are controlled by the International Standards Organization (ISO) registration authority. In some cases, this authority is delegated by ISO to regional registration authorities. In the United States, the American National Standards Institute (ANSI) manages this registration

Using an OID registered to another organization or failing to register an OID may carry legal consequences, depending the situation. Registration may be subject to fees. For more information, contact the appropriate registration authority.

 

[Dave-Z]

Great news. It's been broken for years.
[doublepost=1559847690][/doublepost]


https://access.redhat.com/documenta...Standard_X.509_v3_Certificate_Extensions.html

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:

TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).

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.

 

[dragoon2745]

So you're saying I should stop using MD5?

 

[Shirasaki]

I don’t understand the full implication here, but sounds like a deal breaker for a very small group of people (literally).

 

[mannyvel]

I don’t understand the full implication here, but sounds like a deal breaker for a very small group of people (literally).

It's not really a dealbreaker, it's just aggravating because anyone affected will need to pull up an old Windows VM to do anything with the devices. Everyone in the industry needs to do this occasionally, so it's not a big deal...it'll just take like 20-30 minutes (and the associated pain) instead of 1-2.

 

[Doctor Q]

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.

What will happen when I connect to my "insecure" local webserver that's on my private in-home network?

 

[skinned66]

They're literally doing you a favour. They've supported it more than long enough.

 

[Glockworkorange]

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?

Really? Wow.