Support for X.509 Authority Information Access extensions

Hi, I was wondering whether APIs such URLSession or SecTrustEvaluateWithError support the "Authority Information Access" X.509 extension (https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.2.1) when they are resolving certificate chains?

ie. If a TLS server is not providing an intermediate certificate but its URI is specified by an AIA extension will URLSession (and SecTrustEvaluateWithError) be able to successfully validate the certificate chain?

Local experiments seem to indicate URLSession might, but I can't find any definitive API documentation to confirm this.

Thanks in advance, Rob

Up vote post of softwaredeveloper Down vote post of softwaredeveloper
525 views
Posted by
softwaredeveloper
Reply
Add a Comment

Replies

Hi, I was wondering whether APIs such URLSession or SecTrustEvaluateWithError support the "Authority Information Access" X.509 extension (https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.2.1) when they are resolving certificate chains? ie. If a TLS server is not providing an intermediate certificate but its URI is specified by an AIA extension will URLSession (and SecTrustEvaluateWithError) be able to successfully validate the certificate chain?

Typically the data provided in the Authority Information Access extension is used to check the revocation status of the certificate being used for TLS from a trusted CA. For example in the RFC: "Information and services may include on-line validation services and CA policy data."

When your certificate chain is validated, if OCSP is performed and it succeeds then this justs tells the system that the certificate has not been revoked and the handshake can proceed.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Posted by
meaton
Up vote reply of meaton Down vote reply of meaton
Add a Comment

Adding on to my previous answer, "Authority Information Access" can be used to obtain missing intermediate information but is not something a client should rely on. Instead, a client should make sure they are connecting to a peer that provides a full certificate chain when the server hello packet is sent during the TLS handshake. This will always ensure that the chain is able to be validated and does not rely on an extension to do so.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Posted by
meaton
Up vote reply of meaton Down vote reply of meaton

  • Thanks for the replies Matt. We have fixed the certificate chain being provided during the TLS handshake, so all good, but the absence of the intermediate certificate was reportedly impacting Android clients but not iOS ones, hence my curiosity about whether the iOS APIs were obtaining the missing intermediate information behind the scenes. It's not something we're relying on though.

    —
    softwaredeveloper
Add a Comment

No problem. It is possible if the leaf certificate was issued directly from the root certificate and the client can validate the cryptographic chain of trust to that root, that the TLS handshake be valid on iOS without an intermediate. This is very uncommon, but is not unheard of.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Posted by
meaton
Up vote reply of meaton Down vote reply of meaton
Post marked as solved
Add a Comment