Afnetworking: SSL requests are failing in 2.0

Created on 17 Sep 2013  路  18Comments  路  Source: AFNetworking/AFNetworking

I'm getting the following error for every single HTTPS request I send:

Error Domain=NSURLErrorDomain Code=-1012 "The operation couldn鈥檛 be completed.

I've traced down the issue to AFURLConnectionOperation's - (void)connection:(NSURLConnection *)connection willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge method.

The securityPolicy (which is not the same as the AFHTTPRequestOperationManager's - separate issue [will file separately]) is failing the evaluateServerTrust.

We're using a valid SSL cert and this worked perfectly in 1.x releases.

Any ideas?

Most helpful comment

Creating security policy as following and updating AFNetworking to v2.6.0 fixed all my issues with error code=-1012

 AFSecurityPolicy *securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeNone];
    [securityPolicy setValidatesDomainName:NO];
    [securityPolicy setAllowInvalidCertificates:YES];

Related to this issue http://stackoverflow.com/questions/27808249/problems-with-ssl-pinning-and-afnetworking-2-5-0-nsurlerrordomain-error-1012

All 18 comments

This appears to have been caused by the defaultSecurityPolicy SSLPinningMode being set to AFSSLPinningModePublicKey.

The best way I've found to remedy this was to set my own SecurityPolicy on my AFHTTPRequestOperationManager and set the SSLPinningMode to AFSSLPinningModeNone.

This is also related to #1324 since all operations that are executed via the AFHTTPRequestOperationManager should use the same security policy defined in that class.

Is there a reason that the default SSLPinningMode changed in 2.0? It appears to be defaulted to AFSSLPinningModeNone in 1.x releases...

Ya I mentioned this as being a problem here, but never heard back from @mattt. I think the default policy is a bit to strict for this exact reason in this issue.

Ah, didn't see that thread before I started this one. Yeah, I agree - it's probably a bit too strict for the defaultPolicy.

@kcharwood Agreed. 8208096 fixes this.

Thanks, guys!

I have hard coded the Pinning mode in your library to AFSSLPinningModeNone just to ensure that's not the issue, and I still get the error:
Error: Error Domain=NSURLErrorDomain Code=-1012 "The operation couldn鈥檛 be completed. (NSURLErrorDomain error -1012.)" UserInfo=0xc278330 {NSErrorFailingURLKey=https://[redacted], NSErrorFailingURLStringKey=[redacted]}

Any ideas?

I still have this -1012 error, which happens only on specific devices, at irregular moments, with a perfectly regular server certificate.

The pinning mode is AFSSLPinningModeNone.

The AFServerTrustIsValid function gets kSecTrustResultRecoverableTrustFailure out of SecTrustEvaluate, and this is why the -[AFSecurityPolicy evaluateServerTrust:forDomain:] method returns NO, the -[NSURLAuthenticationChallengeSender cancelAuthenticationChallenge:] method is eventually called, and we have this -1012 error.

I wish AFNetworking would perform custom certificate verification if and only if the library user has explicitly asked for custom certificate validation, which I did not: I wish the default, system-provided, path would be used, as one can assume it is generally more reliable than custom code (despite the recent Apple ssl drama).

I'm investigating this path right now.

After more investigation, it looks that the certificate database of one particular device is broken. A raw NSURLConnection spawned from an application which does not embed AFNetworking fails for this particular hostname. Safari, the built-in web browser, fails for this particular hostname.

My interpretation now is that the way AFNetworking 1 was handling https certificate may have spoiled the certificate database on this particular device, beyond any repair.

Restoring the network settings, as well as other resetting options from the Settings Application did not solve the issue. Let's hope the database gets fixed eventually, and let's disable certificate checking on this particular hostname for now.

I've also run into this particular issue today...

Error Domain=NSURLErrorDomain Code=-1012 "The operation couldn鈥檛 be completed. (NSURLErrorDomain error -1012.)" UserInfo=0x14db7dc0 {NSErrorFailingURLKey=https://api.DOMAIN, NSErrorFailingURLStringKey=https://api.DOMAIN}

Visiting the site in Safari brought up a "this certificate cannot be verified", however visiting the site in Chrome (both on the iPhone and Mac) showed a certificate with no issues. This isn't a self signed SSL cert either, it's from RapidSSL.

I'm hitting this issue now too. The only workaround is indeed:

AFSecurityPolicy *securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeNone];
securityPolicy.allowInvalidCertificates = YES;
manager.securityPolicy = securityPolicy;

I'm using _AFSSLPinningModePublicKey_. I'm setting my cetificates from app bundle.
The problem is, _%95_ of the time it works, but _%5_ it fail with error:
Error Domain=NSURLErrorDomain Code=-1012 "The operation couldn鈥檛 be completed.

+(AFHTTPRequestOperationManager *)sharedManager {
    static dispatch_once_t once;
    static AFHTTPRequestOperationManager *sharedManager;
    dispatch_once(&once, ^ {
        sharedManager = [AFHTTPRequestOperationManager manager];

        // SSL pinning
        AFSecurityPolicy *securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModePublicKey];
        NSString *certPath_bank = [[NSBundle mainBundle] pathForResource:@"ibank" ofType:@"cer"];
        NSString *certPath_root = [[NSBundle mainBundle] pathForResource:@"thawte Extended Validation SSL CA" ofType:@"cer"];
        NSString *certPath_validation = [[NSBundle mainBundle] pathForResource:@"thawte Primary Root CA" ofType:@"cer"];
        securityPolicy.pinnedCertificates = @[[NSData dataWithContentsOfFile:certPath_bank],[NSData dataWithContentsOfFile:certPath_root],[NSData dataWithContentsOfFile:certPath_validation]];
        sharedManager.securityPolicy = securityPolicy;
    });
    return sharedManager;
}

The same issue for anyone?

    AFHTTPRequestOperation *operation = [[AFHTTPRequestOperation alloc] initWithRequest:mutableRequest];
    operation.securityPolicy.allowInvalidCertificates = YES;

Did anybody found a solution? I can go ahead with this 'allow invalid certificates' workaround, but it's a bit insecure.

In my case is happening only on iPhone 4S, while 5 and 5S is working correctly.

the invalid certificates enabled mine to run okay too. seems to have happened since using xcode6 (versus 5) and since using 2.0 of AFNetworking (had to upgrade coz of xcode6 other issues). The problem here is that you have to do it before every call.

I wrote the following example to illustrate custom root CA validation with AFNetworking - https://gist.github.com/r00m/e450b8b391a4bf312966

Hope it helps someone, because it sure was a struggle for me.

I had the same issue even with latest version of AFNetworking and AFSSLPinningModeNone.

I have wildcard self-signed certificate (*.mydomain.com) for test deployments and for some self-hosted web apps. To avoid warnings in web browser I added this certificate into System Keychain. I tried sending requests to api.mydomain.com which has a real certificate. Requests to api.mydomain.com were failing with Error Domain=NSURLErrorDomain Code=-1012 "The operation couldn鈥檛 be completed....

The problem was gone when I deleted this certificate from keychain. So, hopefully it will help others to resolve similar problem.

Ran into same issue even using
let manager = AFHTTPRequestOperationManager()
manager.securityPolicy.allowInvalidCertificates = true;
Any mistake ?

Creating security policy as following and updating AFNetworking to v2.6.0 fixed all my issues with error code=-1012

 AFSecurityPolicy *securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeNone];
    [securityPolicy setValidatesDomainName:NO];
    [securityPolicy setAllowInvalidCertificates:YES];

Related to this issue http://stackoverflow.com/questions/27808249/problems-with-ssl-pinning-and-afnetworking-2-5-0-nsurlerrordomain-error-1012

Was this page helpful?
0 / 5 - 0 ratings