Re: [SOLVED] SecTrustEvaluate() failing with kSecTrustResultRecoverableTrustFailure
Re: [SOLVED] SecTrustEvaluate() failing with kSecTrustResultRecoverableTrustFailure
- Subject: Re: [SOLVED] SecTrustEvaluate() failing with kSecTrustResultRecoverableTrustFailure
- From: Rick Mann <email@hidden>
- Date: Fri, 17 May 2013 17:48:12 -0700
One correction: the code I posted has a minor error, in that it releases the trust before creating the credential. Just move the line that creates the credential (if the trust evaluation returns true) to before the CFRelease(trust).
On May 17, 2013, at 15:41 , Rick Mann <email@hidden> wrote:
> I figured it out, finally. Because our server has a dynamically-assigned IP address, and no hostname, we couldn't create a cert that matched. By default, iOS and OS X want to verify the hostname. The solution is to create a new SecTrustRef with a policy that does not check the hostname, and evaluate that. The final code is:
>
> - (void)
> connection: (NSURLConnection*) inConnection
> willSendRequestForAuthenticationChallenge: (NSURLAuthenticationChallenge*) inChallenge
> {
> NSLogDebug(@"Connection challenged");
>
> // Build a new trust based on the supplied trust, so that we can set the policy…
>
> NSURLProtectionSpace* protectionSpace = inChallenge.protectionSpace;
> SecTrustRef trust = protectionSpace.serverTrust;
>
> CFIndex numCerts = SecTrustGetCertificateCount(trust);
> NSMutableArray* certs = [NSMutableArray arrayWithCapacity: numCerts];
> for (CFIndex idx = 0; idx < numCerts; ++idx)
> {
> SecCertificateRef cert = SecTrustGetCertificateAtIndex(trust, idx);
> [certs addObject: CFBridgingRelease(cert)];
> }
>
> // Create a policy that ignores the host name…
>
> SecPolicyRef policy = SecPolicyCreateSSL(true, NULL);
> OSStatus err = SecTrustCreateWithCertificates(CFBridgingRetain(certs), policy, &trust);
> CFRelease(policy);
> if (err != noErr)
> {
> NSLogDebug(@"Error creating trust: %d", err);
> [inChallenge.sender cancelAuthenticationChallenge: inChallenge];
> return;
> }
>
> // Set the root cert and evaluate the trust…
>
> NSArray* rootCerts = @[ CFBridgingRelease(mRootCert) ];
> err = SecTrustSetAnchorCertificates(trust, CFBridgingRetain(rootCerts));
> if (err == noErr)
> {
> SecTrustResultType trustResult;
> err = SecTrustEvaluate(trust, &trustResult);
> CFRelease(trust);
>
> bool trusted = err == noErr;
> trusted = trusted && (trustResult == kSecTrustResultProceed || trustResult == kSecTrustResultUnspecified);
> if (trusted)
> {
> NSURLCredential* credential = [NSURLCredential credentialForTrust: trust];
> [inChallenge.sender useCredential: credential forAuthenticationChallenge: inChallenge];
> return;
> }
> }
>
> // An error occurred, or we don't trust the cert, so disallow it…
>
> [inChallenge.sender cancelAuthenticationChallenge: inChallenge];
> }
>
> On May 16, 2013, at 12:46 , Jens Alfke <email@hidden> wrote:
>
>>
>> On May 15, 2013, at 9:13 PM, Rick Mann <email@hidden> wrote:
>>
>>> I'm trying to validate our self-signed certificate in NSURLConnectionDelegate's -connection:willSendRequestForAuthenticationChallenge: using itself as the root cert. I'm not 100% sure I'm doing it right, but looking at the ridiculously, excessively complicated example code, I've come up with this:
>>
>> Ugh, yeah, I’ve had trouble with this too, but it was long enough ago that I don’t remember the details.
>> One thing that might help is calling SecTrustGetResult to get detailed info on the results of trust evaluation. The returned structure might have some clues in it.
>>
>> You can also ask for help on the apple-cdsa list (which is for security/crypto related topics).
>>
>> —Jens
>> _______________________________________________
>>
>> Cocoa-dev mailing list (email@hidden)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
>
> --
> Rick
>
>
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
--
Rick
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden