Does URLSession check the whole certificate chain?

Hello,


URLSession does not estabilish the connection, if the certificate(s) of the endpoint is(are) invalid (for example, revoked). My question is ...

Does URLSession check the whole certificate chain or just the leaf certificate?


Illustration:

----

Certificate Leaf (Valid)

Certificate Intermediate (Valid)

Certificate Root (Valid)


Connection established

----


----

Certificate Leaf (Revoked or Expired))

Certificate Intermediate (Valid)

Certificate Root (Valid)


Connection refused

----


----

Certificate Leaf (Valid)

Certificate Intermediate (Revoked or Expired)

Certificate Root (Valid)


Will the connection be refused?

----



It might be a strange question, becuase it is obvious that the connection will be refused.

However, my team wants to prove or see this behavior. If not, they are not conviced. This is the most difficult part.

We don't know how to deploy (or where to find) a website with the intermediate certificate revoked or expired, hence we can't see it.

We don't know either where to find a documentation or code, hence we can't prove it.



Thanks in advance.


Best,

Neil

Answered by Systems Engineer in 415276022

Neil,


Any Apple API performing TLS will, at minimum, perform server trust evaluation based on RFC 2818. Specifically these APIs use a TLS trust policy as returned by SecPolicyCreateSSL, which is an extension of the SecPolicyCreateBasicX509 which will form a chain of trust that checks the root and each link. Therefore, if an intermediate is present in the chain it will be evaluated.


As mentioned in my previous response, APIs like NSURLSession can use App Transport Security to provide options to enforce stricter security in the chain of trust and deciding on whether you want to fail the connection or do extra checks on the SecTrustRef to ensure the certificate is valid. One great example of this is using the NSRequiresCertificateTransparency key in your ATS settings.


A great reference on this topic is a post the Quinn wrote called TLS for App Developers.


Matt Eaton

DTS Engineering, CoreOS

meaton3 at apple.com

Neil,



Great question. The best answer is that results can vary based on your App Transport Security configuration, the status of your intermediate certificate, and the properties of your certificates. To your specific question on how to test some of these conditions, I usually test with badssl dot com. This may not cover all of your testing needs, or a revoked intermediate certificate, but it should get you started. For end to end testing I would encourage you to setup this exact scenario in your server environment.


Next, you should consider how your ATS settings are configured in your project and how this plays a role in validation as well. For example, consider a strictly enforced case of domain dot com:


<key>NSAppTransportSecurity</key>

<dict>

<key>NSExceptionDomains</key>

<dict>

<key>domain.com</key>

<dict>

<key>NSIncludesSubdomains</key>

<true/>

<key>NSExceptionAllowsInsecureHTTPLoads</key>

<false/>

<key>NSExceptionRequiresForwardSecrecy</key>

<true/>

<key>NSExceptionMinimumTLSVersion</key>

<string>TLSv1.2</string>

<key>NSThirdPartyExceptionAllowsInsecureHTTPLoads</key>

<false/>

<key>NSThirdPartyExceptionRequiresForwardSecrecy</key>

<true/>

<key>NSRequiresCertificateTransparency</key>

<true/>

</dict>

</dict>

</dict>


For this specific situation, you could receive recoverable SSL failures when testing certificates with missing Common Names due to the enforcement of NSRequiresCertificateTransparency, but not see these errors otherwise. The best answer to to test each scenario with your ATS requirements to know which errors to account for.


Matt Eaton

DTS Engineering, CoreOS

meaton3 at apple.com

Thank you for these valuable tips. We really appreciate it. We're now working on a testing environement.


By the way, for the original question. Does URLSession check the whole certificate chain or just the leaf certificate?

I would be grateful if I could get the answer to this question. It allows me to have an expectation.


Thank in advance.


Best,

Neil

Accepted Answer

Neil,


Any Apple API performing TLS will, at minimum, perform server trust evaluation based on RFC 2818. Specifically these APIs use a TLS trust policy as returned by SecPolicyCreateSSL, which is an extension of the SecPolicyCreateBasicX509 which will form a chain of trust that checks the root and each link. Therefore, if an intermediate is present in the chain it will be evaluated.


As mentioned in my previous response, APIs like NSURLSession can use App Transport Security to provide options to enforce stricter security in the chain of trust and deciding on whether you want to fail the connection or do extra checks on the SecTrustRef to ensure the certificate is valid. One great example of this is using the NSRequiresCertificateTransparency key in your ATS settings.


A great reference on this topic is a post the Quinn wrote called TLS for App Developers.


Matt Eaton

DTS Engineering, CoreOS

meaton3 at apple.com

Thank you very much. Very helpful information.

Does URLSession check the whole certificate chain?
 
 
Q