In addition to root
certificate authority (CA) certificate verification, AsyncOS supports the use
of intermediate certificate verification. Intermediate certificates are
certificates issued by a trusted root CA which are then used to create
additional certificates. This creates a chained line of trust. For example, a
certificate may be issued by example.com who, in turn, is granted the rights to
issue certificates by a trusted root CA. The certificate issued by example.com
must be validated against example.com’s private key as well as the trusted root
CA’s private key.
Servers send a “certificate chain” in an
SSL handshake in order for clients (for example, browsers and in this case the
WSA, which is a HTTPS proxy) to authenticate the server. Normally, the server
certificate is signed by an intermediate certificate which in turn is signed by
a trusted root certificate, and during the handshake, the server certificate
and the entire certificate chain are presented to the client. As the root
certificate is typically present in the Trusted Certificate store of the WSA,
verification of the certificate chain is successful.
However, sometimes when the end-point
entity certificate is changed on the server, necessary updates for the new
chain are not performed. As a result, going forward the server presents only
the server certificate during the SSL handshake and the WSA proxy is unable to
verify the certificate chain since the intermediate certificate is missing.
Previously, the solution was manual
intervention by the WSA administrator, who would upload the necessary
intermediate certificate to the Trusted Certificate store. Now you can use the
CLI command
advancedproxyconfig > HTTPS > Do you want to enable
automatic discovery and download of missing Intermediate Certificates?
to enable “intermediate certificate discovery,” a process the WSA uses in an
attempt to eliminate the manual step in these situations.
Intermediate certificate discovery uses a
method called “AIA chasing”: when presented with an untrusted certificate, the
WSA examines it for an extension named “Authority Information Access.” This
extension includes an optional CA Issuers URI field, which can be queried for
the Issuer Certificate used to sign the server certificate in question. If it
is available, the WSA fetches the issuer’s certificate recursively until the
root CA certificate is obtained, and then tries to verify the chain again.