iOS Client Certificates and Mobile Device Management
Asked Answered
C

3

16

Our customers want to use an MDM (mobile device management) solution (MobileIron) to install client certificates onto corporate iOS devices, in order to limit access to certain corporate web services to corporate devices only.

MobileIron installs the client certificate into Settings > General > Profiles, which is the default location for certificates in iOS, and Safari can respond with this certificate when a corporate web service challenges it for one.

But I need the same thing to happen from within a custom app. When our app gets challenged for a certificate, I need to be able to respond with the certificate from Settings > General > Profiles. I have examples of responding with a certificate which is bundled with our app, and with a certificate which our app stores within its own keychain, but I do not have an example of responding with a certificate installed on the device in Settings > General > Profiles.

Can anyone explain to me more about what the NSURLAuthenticationChallengeSender protocol method -performDefaultHandlingForAuthenticationChallenge: does? Does default handling mean that iOS effectively responds to the challenge on behalf of the app? Can this response include a client certificate stored in Settings > General > Profiles?

Update

If the MDM could install a client certificate into the app keychain, that would be perfect.

Chloras answered 19/9, 2014 at 1:16 Comment(0)
C
8

Apple tech support pointed me to the following tech note in response:

https://developer.apple.com/library/ios/qa/qa1745/_index.html

To summarise, what we want to do is not supported.

Chloras answered 23/9, 2014 at 8:11 Comment(0)
M
3

MobileIron's AppConnect 2.1 update solves this problem, no special code required. X.509 certificates can be pushed with the AppConnect Configuration, and the AppConnect framework intercepts any authentication challenges when it can respond with an eligible cert. Certs can be created on-the-fly at first launch, revoked later, customized per-user or per-device, and different URL's can use different certs.

If anyone is using the code snippet on this page, stop, it's not needed. After wrapping your unmodified app, or linking-in the AppConnect framework, add an MI_AC_CLIENT_CERT_1 key to your AppConnect Configuration, pointing to a Certificate Enrollment configuration (i.e. SCEP, Entrust, Symantec PKI, PIV-D, etc.). Add a MI_AC_CLIENT_1_RULE key with a URL (with optional wildcard). There is no step 3. Your app will now automatically use certs for authentication.

Full details are in MobileIron's AppConnect and AppTunnel Guide docs, under "Certificate authentication from AppConnect apps to enterprise services".

Marmoset answered 2/3, 2017 at 22:47 Comment(4)
Okay, so having moved on from the project which prompted me to ask this question, I can't try this out. It sounds like it would have addressed the needs of the customers, and it would have simplified our app. The "interception of authentication challenges" part bothers me slightly, though. Does that mean that AppConnect becomes the HTTPS endpoint, instead of the app? So AppConnect proxies the traffic?Chloras
Brett, I'm not going to divulge our "secret sauce" here, but check out developer.apple.com/library/content/documentation/Cocoa/… and NSURLAuthenticationMethodClientCertificate.Marmoset
I'll take that as a "yes".Chloras
I'm going to guess this works with the newer Sessions since they're shared, so your framework can intercept them.Loadstar
B
1

I just came back from an onsite at a customer who was using MobileIron and was looking to do just this. MobileIron development support provided us with this snippet of code, which imports a certificate provided by the AppConnect Wrapper through MobileIron's Core Config technology.

It's not pretty, but as it was provided by them I was not allowed to modify it. It works though! You insert this into your AppDelegate.h:

- (NSString *)appConnectConfigChangedTo:(NSDictionary *)newConfig;

And this into your AppDelegate.m, right after the aforemention pragma mark:

#pragma mark UIApplicationDelegate implementation                                
- (NSString *)appConnectConfigChangedTo:(NSDictionary *)newConfig{
        //NSLog(@"New config: %@", newConfig);                                          //unsecure
        NSLog(@"New config retrieved");                                                 //confirm we got a new config
        NSString *certStr       = [newConfig valueForKey:@"kUserCert"];                 //Store certificate as String
        NSString *certPassword  = [newConfig valueForKey:@"kUserCert_MI_CERT_PW"];      //Store certificate password as string
        NSData *cert = [[NSData alloc] initWithBase64EncodedString:certStr options:0];  //only for iOS7+, decodes base64 encoded certificate
        CFDataRef pkcs12Data = (__bridge CFDataRef)cert;                                //Extract identity & certificate objects from
        CFStringRef password = (__bridge CFStringRef)certPassword;                      //the cert data Identity
        SecIdentityRef myIdentity = nil;                                                //Initialize variable for identity
        SecCertificateRef myCertificate = nil;                                          //Initialize variable for certificate
        OSStatus status = extractIdentityAndTrust(pkcs12Data, password, &myIdentity, nil); //Use Apple-provided method for extracting Identity and Trust
        if (status != errSecSuccess || myIdentity == nil) { NSLog(@"Failed to extract identity and trust: %ld", status);} //Likely due to corruption
        else { SecIdentityCopyCertificate(myIdentity, &myCertificate); }                //This method is supposed to store the Certificate, but Fiori doesn't see it here
        const void *certs[] = { myCertificate };                                        //Initialize an array for one certificate
        CFArrayRef certsArray = CFArrayCreate(NULL, certs, 1, NULL);                    //Make the array the way Apple wants it to be
        NSURLCredential *credential = [NSURLCredential credentialWithIdentity:myIdentity certificates:(__bridge NSArray*)certsArray persistence:NSURLCredentialPersistencePermanent];                                       //MobileIron's method of Credential storage
        NSMutableDictionary *secIdentityParams = [[NSMutableDictionary alloc] init];    //Initialize Dictionary to store identity
        [secIdentityParams setObject:(__bridge id)myIdentity forKey:(__bridge id)kSecValueRef]; //Build the secIdentityParams dictionary in the way the next method expects it to be
        OSStatus certInstallStatus = SecItemAdd((__bridge CFDictionaryRef) secIdentityParams, NULL); //Add the identity to the keychain for Fiori consumption
        if (myIdentity) CFRelease(myIdentity);                                          //Free
        if (certsArray) CFRelease(certsArray);                                          //Up
        if (myCertificate) CFRelease(myCertificate);                                    //Memory
        return nil;                                                                     //Success
} 
// Copied from Apple document on Certificates:
// http://developer.apple.com/library/mac/documentation/security/conceptual/CertKeyTrustProgGuide/CertKeyTrustProgGuide.pdf
OSStatus extractIdentityAndTrust(CFDataRef inP12data, CFStringRef password, SecIdentityRef *identity, SecTrustRef *trust){
        OSStatus securityError = errSecSuccess;
        const void *keys[] = { kSecImportExportPassphrase };
        const void *values[] = { password };
        CFDictionaryRef options = CFDictionaryCreate(NULL, keys, values, 1, NULL, NULL);
        CFArrayRef items = nil;
        securityError = SecPKCS12Import(inP12data, options, &items);
        if (securityError == errSecSuccess) {
                CFDictionaryRef myIdentityAndTrust = CFArrayGetValueAtIndex(items, 0);
                if (identity && CFDictionaryGetValueIfPresent(myIdentityAndTrust, kSecImportItemIdentity, (const void **)identity)) {
                        CFRetain(*identity);
                    }
                if (trust && CFDictionaryGetValueIfPresent(myIdentityAndTrust, kSecImportItemTrust, (const void **)trust)) {
                        CFRetain(*trust);
                    }
            }  
        if (options) {CFRelease(options);}
        if (items) {CFRelease(items);}
        return securityError;
}

Once you've built your app, ask the MobileIron administrator to 'wrap' the app so that it can use AppConnect. Once that is done and the wrapped app is deployed to test users via MobileIron, set up a Core Config that take a User Certificate specific for the provisioned user and pushes it to the provisioned devices under the Core Config key "kUserCert".

Bridge answered 27/10, 2015 at 14:55 Comment(4)
Very interesting. Will have to try to get our hands on a copy of MobileIron to try this out.Chloras
do you need to integrate with MobileIron SDK?Realist
For this functionality there was no traditional library or SDK: MobileIron provided us with the sample code, and we had to use their Wrapper application to wrap the app for AppConnect to work.Bridge
@LewWeiHao it would have to come from MobileIronBridge

© 2022 - 2024 — McMap. All rights reserved.