The internal client on your network attempts to initiate
a TLS session with an external server.
The firewall intercepts the client’s SSL certificate request.
For the client, the firewall acts as the external server, even though
the secure session being established is with the firewall, not with
the actual server.
The firewall then forwards the client’s SSL certificate request
to the server to initiate a separate session with the server. To
the server, the firewall looks like the client, the server doesn’t
know there’s a man-in-the-middle, and the server verifies the certificate.
The server sends the firewall a signed certificate intended
for the client.
The firewall analyzes the server certificate. If the server
certificate is signed by a CA that the firewall trusts and meets
the policies and profiles you configure, the firewall generates
an SSL Forward Trust copy of the server certificate and sends it
to the client. If the server certificate is signed by a CA that
the firewall does not trust, the firewall generates an SSL Forward
Untrust copy of the server certificate and sends it to the client.
The certificate copy the firewall generates and sends to the client
contains extensions from the original server certificate and is
called an
impersonation certificate because it is not
the server’s actual certificate. If the firewall does not trust
the server, the client sees a block page warning message that the
site they’re attempting to connect to is not trusted, and if you
Enable
Users to Opt Out of SSL Decryption, the client can choose
to proceed or terminate the session.
The client verifies the firewall’s impersonation certificate.
The client then initiates a session key exchange with the server,
which the firewall proxies in the same manner as it proxies the
certificates. The firewall forwards the client key to the server,
and makes an impersonation copy of the server key for the client,
so that firewall remains an “invisible” proxy, the client and server
believe their session is with each other, but there are still two
separate sessions, one between the client and the firewall, and
the other between the firewall and the server. Now all parties have
the certificates and keys required and the firewall can decrypt
the traffic.
All SSL session traffic between goes through the firewall transparently
between the client and the server. The firewall decrypts the SSL
traffic, applies security policies and profiles and decryption profiles
to the traffic, re-encrypts the traffic, and then forwards it.