Developer Certificate Validation

Question

I want customers to be able to upload their own provisioning profile, including badges, so that I can make them a custom version of my on-the-fly application that they can publish.

However, I have a little problem checking the provisioning profile. In particular, I want to check if DeveloperCertificate is really a valid certificate. The profile looks something like this:

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>ApplicationIdentifierPrefix</key> <array> <string>ABCDEFGH</string> </array> <key>CreationDate</key> <date>2012-03-28T11:17:23Z</date> <key>DeveloperCertificates</key> <array> <data> MIIFajCCBFKgAwIBAgIIddUra9YprMQwDQYJKoZIhvcNAQEFBQAwgZYxCzAJ BgNVBAYTAlVTMRMwEQYDVQQKDApBcHBsZSBJbmMuMSwwKgYDVQQLDCNBcHBs ZSBXb3JsZHdpZGUgRGV2ZWxvcGVyIFJlbGF0aW9uczFEMEIGA1UEAww7QXBw ... </data> </array> ... </dict> 

So, I extract the certificate (s) and then want to verify them, preferably using the openssl command. What is the encryption used for these certificates, and how can I verify them using openssl? I think this uses pkcs12, but try that gives me an error:

 $ openssl pkcs12 -noout -in testcertificate 140653159306912:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1319: 140653159306912:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:381:Type=PKCS12 

Can someone point me in the right direction? It is very important that I can somehow check the validity period of the developer certificates.

thanks

Answer 1

I studied this, and it turns out that it should not be as difficult as David describes. The solution is actually quite simple:

The certificate is a base64 encoded DER certificate. What you need to do is the following:

• Extract certificate from XML

• Base64 decode certificate:

  base64 -d certificate> certificate.crt

• Verify the certificate using OpenSSL:

  openssl x509 -inform DER -in certificate.crt -noout -text

Or, if we run it:

 cat certificate | base64 -d - | openssl x509 -inform DER -noout -text 

The -text option allows openssl to provide all the details, but you can specify according to your wishes. Suppose, for example, that you are only interested in whether the certificate is an actual distribution certificate, instead you can use the -subject option and see the CN= field.

Answer 2

Ok, I have good news and bad news. I have a friend who is a Mac / iOS security expert, and he works a lot in this area. In fact, he had something very similar. The information I received from him is as follows. But the bad news is not an easy command line method - you will most likely have to unscrew the Mac application to do this using the methods below.

- Technics ---

The certificate inside this XML file ... is read into the NSData object; although there are usually 3 certificates; at least in profiles created by Apple. I don’t know if this is so.

If there are 3 certificates, it is usually enough to verify that one of them (usually the last one) is called "Apple Root CA" and has a SHA1 value in hexadecimal format "611E5B662C593A08FF58D14AE22452D198DF6C60" - I use the SHA1 function in openssl.h for this.

If there is only one certificate, it is likely a certificate sheet. To check if this is normal, it is more difficult, because a full "chain of trust" is usually required to check.

In any case, you need to associate with Security.framework, call SecCertificateCreateWithData () with NSData (in an appropriate way) to get SecCertificateRef.

A relative label could be a call to SecCertificateCopyValues ​​() to get the "Authorization key identifier (2.5.29.35)" field (the dictionary key for this seems to be kSecOIDAuthorityKeyIdentifier) ​​and check if this field value is hexadecimal "E7342A2E22DE39606BB494CE7783512F31, 31731123 313 313 313 313 313 313 313 313 313 313 313 313 313 313 313 313 313 311 316 311 316 311 316 311 361 316 311 361 316 311 361 316 311 361 316 311 361 316 311 316 311 316 311 361 391 361 391 361 391 603 seems to be valid for all certificates issued by Apple. Returning from SecCertificateCopyValues ​​() is a nested dictionary dictionary, so you need to expand it to find this.

The full and complete answer would be to pass the certificate to SecTrustSettingsCopyTrustSettings (), sequentially, kSecTrustSettingsDomainUser, kSecTrustSettingsDomainAdmin, kSecTrustSettingsDomainSystem, checking if the certificate is explicitly trusted or not. If the intermediate certificate is not installed on the machine, which is likely to fail if it has a sheet certificate.