Will Apple allows HTTPS Connection validating with Self Signed certificate?

For treating the Self Signed certificate as valid in iOS App, I added some code to provide trust exceptions, So that mobile client will always trust the server.


BOOL isValid = NO;

SecTrustResultType result;

__Require_noErr_Quiet(SecTrustEvaluate(serverTrust, &result), _out);

if (result == kSecTrustResultRecoverableTrustFailure) {

CFDataRef errDataRef = SecTrustCopyExceptions(serverTrust);

SecTrustSetExceptions(serverTrust, errDataRef);

__Require_noErr_Quiet(SecTrustEvaluate(serverTrust, &result), _out);

}

_out:

return isValid;



1. Will apple encourage this kind of methodology?

2. Will iTunes publish my app, if I uses this code to force the client for trusting the sever?

If this is not the right way, can you please provide any alternate solution(iOS front) to support self signed certificate.

Replies

Let’s start with the basics: why are you connecting to a server that has a self-signed certificate? Is that part of your app’s infrastructure? Or does your app allow the user to enter arbitrary server addresses (like a mail client or web browser)?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks Eskimo for your kind reply.


The app is part of a server based application. It is a product with many customer installations. The product is intranet application and mobile will connect to the server using organization’s Wi-Fi. Application uses Transport security mainly to enforce message encryption at transport level (for every service call), but not to authenticate client or server. Hence, all the client applications (including mobile app) are developed by trusting the certificate by default.


Since the product is an intranet application, we are supporting self-signed certificate for all other components of the product. The product and app are already launched and used in hundreds of installations in last one year and expectation from our product management team is to continue to support this ecosystem without adding any additional constraints.


// Code starts here

BOOL isValid = NO;

SecTrustResultType result;

__Require_noErr_Quiet(SecTrustEvaluate(serverTrust, &result), _out);

if (result == kSecTrustResultRecoverableTrustFailure) {

CFDataRef errDataRef = SecTrustCopyExceptions(serverTrust);

SecTrustSetExceptions(serverTrust, errDataRef);

__Require_noErr_Quiet(SecTrustEvaluate(serverTrust, &result), _out);

}

isValid = (result == kSecTrustResultUnspecified || result == kSecTrustResultProceed);

_out:

return isValid;

// Code ended


With the above code, we intend to support both trusted certificate as well as self-signed certificate.

Can you please confirm the above code is within the Apple’s guidelines for our application’s design stated above.

Can you please confirm the above code is within the Apple’s guidelines for our application’s design stated above.

No, sorry. What you’re asking about here is App Review policy, and I don’t work for App Review and thus can’t give definitive answers about their policy.

On a technical level, I think you could do better security-wise. Self-signed certificates are pretty much the last resort when it comes to security, and even if you have to live with self-signed certificates your current code is still less secure than it could be. There are many better approaches you could take. For example:

  • You could set up your own CA, having it issue certificates for the servers in question. Your customers could then use their MDM system to install that CA’s root certificate on their devices. Such a solution would be secure, not require any code in your app, and not need any ATS exceptions.

  • You could have your customers use their MDM system to push their server’s certificate to your app via managed app preferences. Your app could then trust only servers with that certificate (see the Trusting One Specific Certificate section of TN2232 for how to do that). This would require an ATS exception, but it would actually be secure.

  • Even without any infrastructure changes, you could still do better by using trust exceptions properly (see the Trust Exceptions section of TN2232). Such a solution would be more secure (it’s basically secure except for the first connection), although it would still require an ATS exception.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks Quinn for you kind reply.


// Code starts here

BOOL isValid = NO;

SecTrustResultType result;

__Require_noErr_Quiet(SecTrustEvaluate(serverTrust, &result), _out);

if (result == kSecTrustResultRecoverableTrustFailure) {

CFDataRef errDataRef = SecTrustCopyExceptions(serverTrust);

SecTrustSetExceptions(serverTrust, errDataRef);

__Require_noErr_Quiet(SecTrustEvaluate(serverTrust, &result), _out);

}

isValid = (result == kSecTrustResultUnspecified || result == kSecTrustResultProceed);

_out:

return isValid;

// Code ended


Even without any infrastructure changes, you could still do better by using trust exceptions properly (see the Trust Exceptions section of TN2232). Such a solution would be more secure (it’s basically secure except for the first connection), although it would still require an ATS exception.


The code what we used is comes under this category. Do we need to do anything else(in terms of code) for complaining the above methodology?

Do we need to do anything else (in terms of code) for complaining the above methodology?

Your current code disables server trust evaluation completely. That is very poor form security-wise. If you’re going to go down the trust exception path (which is not what I recommend), you should following the approach described in the Trust Exceptions section of Technote 2232 HTTPS Server Trust Evaluation (sorry the link was broken in the last post).

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"