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 Web Security Appliance
, 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 Web Security Appliance
, 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
Web Security Appliance
proxy is unable to verify the certificate chain since the intermediate certificate is missing.
Previously, the solution was manual intervention by the Web Security Appliance
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 Web Security Appliance
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 Web Security Appliance
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 Web Security Appliance
fetches the issuer’s certificate recursively until the root CA certificate is obtained, and then tries to verify the chain