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
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