Reduced certificate lifespan: CA root

I have some concerns related to shortening the lifetime of certificates, as per https://support.apple.com/en-gb/102028

Does this apply to Private CA root certificates?

And if yes:

  • does it apply if I use ATS and higher level API like URLSession
  • does it apply it I carry my root CA cert in my app payload and use low level libraries without ATS support?
Answered by DTS Engineer in 823865022

There are two restrictions in play here:

The first applies to all CAs. As endecotp noted, the latter only applies to pre-installed CAs.

Note that these contraints are applied by the TLS policy (SecPolicyCreateSSL). The Basic X.509 policy does not enforce them (SecPolicyCreateBasicX509).

Written by SalvoNt in 773796021
does it apply if I use ATS and higher level API like URLSession

ATS isn’t a factor here. This is part of the TLS policy that applies to all TLS connections, not part of the enhanced security applied by ATS.

Written by SalvoNt in 773796021
does it apply it I carry my root CA cert in my app payload … ?

I’m not sure what “app payload” means in this context. If you’re talking about distributing your app via MDM, there are other factors involved. However, assuming that this is a standard App Store app then:

  • It is possible to embed a custom anchor with your app.

  • And then apply that anchor to trust evaluations done by our various networking APIs [1].

  • In that case, if your custom trust evaluation uses the TLS policy, which it should, then the first limit applies but the second does not.


However, I strongly recommend against using custom anchors because, if you make a mistake in your code, you lose all TLS protections. Bugs like this have affected many third-party developers, including some ‘household name’ developers. These problems are one of the reason for ATS.

If you’re thinking of doing this because you want additional security, my advice is that you equip your servers with a standard CA-issued digital identity and then implement certificate or public key pinning on the client side. That way your app will never be less secure than the default for the system on which it’s running.

Apps that use URLSession, or things layered on top of URLSession, can implement pinning using the NSPinnedDomains property.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Most, but not all, of our networking APIs support overriding TLS server trust evaluation.

The doc you linked to says:

"This change will only affect TLS server certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS and tvOS."

So I'd say this does not apply to your "Private CA root certificates". But I'm not a TLS expert.

There are two restrictions in play here:

The first applies to all CAs. As endecotp noted, the latter only applies to pre-installed CAs.

Note that these contraints are applied by the TLS policy (SecPolicyCreateSSL). The Basic X.509 policy does not enforce them (SecPolicyCreateBasicX509).

Written by SalvoNt in 773796021
does it apply if I use ATS and higher level API like URLSession

ATS isn’t a factor here. This is part of the TLS policy that applies to all TLS connections, not part of the enhanced security applied by ATS.

Written by SalvoNt in 773796021
does it apply it I carry my root CA cert in my app payload … ?

I’m not sure what “app payload” means in this context. If you’re talking about distributing your app via MDM, there are other factors involved. However, assuming that this is a standard App Store app then:

  • It is possible to embed a custom anchor with your app.

  • And then apply that anchor to trust evaluations done by our various networking APIs [1].

  • In that case, if your custom trust evaluation uses the TLS policy, which it should, then the first limit applies but the second does not.


However, I strongly recommend against using custom anchors because, if you make a mistake in your code, you lose all TLS protections. Bugs like this have affected many third-party developers, including some ‘household name’ developers. These problems are one of the reason for ATS.

If you’re thinking of doing this because you want additional security, my advice is that you equip your servers with a standard CA-issued digital identity and then implement certificate or public key pinning on the client side. That way your app will never be less secure than the default for the system on which it’s running.

Apps that use URLSession, or things layered on top of URLSession, can implement pinning using the NSPinnedDomains property.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Most, but not all, of our networking APIs support overriding TLS server trust evaluation.

equip your servers with a standard CA-issued digital identity and then implement certificate or public key pinning on the client side.

Quinn, do you have any comments about the use of that approach on e.g. corporate networks that have “MITM” proxies? The Wikipedia page for pinning says “Most browsers disable pinning for certificate chains with private root certificates to enable various corporate content inspection scanners”. Does that happen with these APIs?

Did you see this thread, where the developer might be encountering this issue when App Review run his app:

https://developer.apple.com/forums/thread/773444

Certificate pinning is fundamentally incompatible with TLS inspection. If you want to run in environments where TLS inspection is common, you can’t enable certificate pinning. Or at least you can’t enable it universally.

One option is to eschew NSPinnedDomains and implement the pinning yourself. You can then implement a managed app configuration key to disable your pinning. That way a site manager can disable your pinning via MDM.

However, that may not be what you want. For example, if you’re working on a personal banking app, you don’t want to expose the user’s traffic just because they’ve enrolled in MDM for work or uni.

Written by endecotp in 823890022
Did you see this thread, where the developer might be encountering this issue when App Review run his app

AFAIK TLS inspection wasn’t a factor in this case, but I didn’t handle that case so I’ve asked Kevin if there’s anything we can say publicly.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

AFAIK TLS inspection wasn’t a factor in this case, but I didn’t handle that case so I’ve asked Kevin if there’s anything we can say publicly.

I added a more extended write up on that thread about what you can do about his kind of situation, but on the specific question:

... corporate networks that have “MITM” proxies? ... Did you see this thread, where the developer might be encountering this issue when App Review run his app

The issue in that thread was in fact a straightforward DNS issue which was quickly resolved once I got the necessary details to the right people.

I'll also highlight the same point I made in that thread, namely that network issues caused by Apple's network are EXTREMELY rare. I only see a case like this every few years and every one of them has been completely unique. Case in point, this is the only one that's involved DNS.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Reduced certificate lifespan: CA root
 
 
Q