0

I've been writing client certificate code for iOS using many of the resources here: iOS Client Certificates and Mobile Device Management and I've broken out the process to these steps:

  1. Get the Cert via email or AppConfig

  2. Store the Cert (securely)

  3. Extract Identity and Trust from the Cert.

  4. Intercept failed web requests, create NSURLConnection to manually handle auth responses as per Eskimo's advice.

  5. Turn Identity and Trust into the auth response challenge.

My problem is step 2. SecPKCS12Import function appears to automatically add Identity to the keychain as well as return all Identities and Trusts from the certificates, thus eliminating the need for the convenience function often given ExtractIdentityAndTrust().

But on my 2nd run, I will need the Identity and Trust, not just Identity. My current plan is to store the entire cert raw using SecItemAdd, test for duplicates and use it, but I feel like I should be able to just use SecPKCS12Import then later grab it without also using SecItemAdd.

The documentation that is most confusing is SecPKCS12Import, and I would like a clearer understanding of what it does vs secItemAdd, and if secItemCopyMatching() is the same in the end just to grab the certificate. Is Trust not needed or am I just being literal and it's stored with the identity?

The general save, use, store, grab is working, but I'm using NSData and would prefer to store it correctly

Stephen J
  • 2,367
  • 2
  • 25
  • 31

1 Answers1

0

I eventually became more familiar with the KeyChain and Identity vs Trust and learned this:

The Trust is a Cert stored in a place that determines who your custom Certificate Authorities are. It only needs to be tested once, which is why it isn't stored.

Storing the Identity is also a certificate, but needed for later. The keychain considers Certificates/Identities to be a Special/Unique thing so it is stored as its own thing, which is why all the keychain code looks different than just securing a password.

Basically, storing the Trust is unnecessary for future reference, but should be checked for good practice. I personally think an expiration might be handy

Stephen J
  • 2,367
  • 2
  • 25
  • 31