TLS authentication with *.pfx certificate on iOS from MDM

Forgot to add that I tried using the SecItemCopyMatching function to read the certificates from the iOS Keychain, but I haven't been able to get this to see the *.pfx certificate under "Configuration Profile".

Let’s start with terminology. A .pfx file typically contains a digital identity, not just a certificate. When talking about “certificate authentication” I generally use the term mutual TLS to avoid the ongoing ambiguity regarding the word certificate. For more background on this, see TLS for App Developers.

Is "Configuration Profile" the iOS equivalent of the Mac Keychain?

No. These are different things, although they do connect when you use a profile to install certain payloads, specifically:

• CertificatePKCS12 (com.apple.security.pkcs12) for a digital identity

• CertificatePKCS1 (com.apple.security.pkcs1) for just a certificate, typically an intermediate certificate

When you install a profile containing one of these payloads the system places the credential into the keychain.

There’s one other relevant payload type, namely, CertificateRoot (com.apple.security.root) for a trusted anchor. When you install a profile containing one of these payloads the system places the certificate into the trust store [1].

When an MDM pushes a *.pfx certificate digital identity onto an iOS device, will it appear under "Configuration Profile"?

Yes. Well, no, but yes. MDM can’t push a digital identity, it can only push configuration profiles. If your MDM system has a UI to push a digital identity, it’s actually pushing a configuration profile with the com.apple.security.pkcs12 payload.

If the answer to #2 is yes, is it possible to access the "Configuration Profile" certificates digital identities from within the app?

No. The credentials in com.apple.security.pkcs12 and com.apple.security.pkcs1 are placed in an Apple keychain access group that’s not available to other apps [2]. See QA1745 Making Certificates and Keys Available To Your App.

Some articles I've read said this isn't possible due to security--you can only access your app's certificates digital identities.

Correct.

If this is true, how will the MDM make the certificates available to our app specifically and not just the device?

This is an ongoing source of grief. See this post for my best suggestion.

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

[1] On macOS this is implemented using the keychain. On iOS there’s a separate trust store subsystem.

[2] There’s a limited exception for apps that provide a custom VPN transport the Network Extension provider facility.

Wow, this is awesome info Quinn, thanks for explaining all this. One other question: When I do a manual install of a *.pfx digital identity by dragging it onto an iOS Simulator like I did in my testing, and it appears under that "Configuration Profile" section in Settings, I'm just seeing the profile, right? But behind the scenes it has also installed part of its payload into the separate trust store subsystem? When I click "More Details", it takes me to a "Certificate" section, and I can see a Certificate name, and when I click that, it takes me to a long detail section, where I can see the issuer name, the public key info, the certificate authority, the signature, etc. Is this essentially showing me part of that trust store subsystem? Or is there another place in iOS where you can see the entire contents of that trust store subsystem (ie, does iOS have an equivalent of the MacOS Keychain, which shows you everything installed?). Oddity about iOS: If these digital identities are NOT accessible from the app, why does iOS allow me to install it at all? Won't they just sit there, completely walled-off and useless?

When I do a manual install of a *.pfx digital identity by dragging it onto an iOS Simulator like I did in my testing, and it appears under that "Configuration Profile" section in Settings, I'm just seeing the profile, right?

Ah, I forgot about this edge case. If you manually ingest a credential, iOS will wrap it up into a dummy profile and ingest that. That’s what happens when you drop a .p12 on to the simulator.

Note .p12 and .pfx are pretty much equivalent, both being files containing a PKCS#12 blob that typically contains a digital identity.

But behind the scenes it has also installed part of its payload into the separate trust store subsystem?

No. The trust store is only relevant to anchors. When you drop a .p12, it synthesises a com.apple.security.pkcs12 payload and that’s imported into the keychain. The underlying PKCS#12 blob typically contains a digital identity, that is, a private key and a certificate that’s wrapped around the public key associated with that private key. It may also contain other certificates, for example, intermediate certificates [1]. These get placed in the keychain, not the trust store, because of the scope implied by the PKCS#12.

Keep in mind that the client device never does trust evaluation on the certificate in the client digital identity, so these extra certificates don’t need to be trusted. Indeed, most of the time they don’t even need to be present. I touch on this in TLS for App Developers, in the text starting with “In many cases the client only needs to send item 0, that is, its leaf certificate.”

Or is there another place in iOS where you can see the entire contents of that trust store subsystem (ie, does iOS have an equivalent of the MacOS Keychain, which shows you everything installed?).

Not really. My Networking Resources post has a link to an Apple Support article that documents what’s in the built-in trust store. Beyond that, you have to look at the installed profiles.

If these digital identities are NOT accessible from the app, why does iOS allow me to install it at all?

For the benefit of built-in apps, like Mail and Safari.

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

Thank you so much, this is extremely helpful. I feel like my knowledge bank just leveled up. :)