Certificates for TLS inspection

TLS Inspection requires two separate secure connections: one from the client to the NGFW Engine and one from the NGFW Engine to the server. Substituting its own certificate for the original server certificate allows the NGFW Engine to decrypt and re-encrypt the traffic.

HTTPS uses the TLS protocol to secure HTTP connections. When a client browser connects to a server that uses HTTPS, the server sends a certificate to the browser. The certificate contains the server's public key and a digital signature from a certificate authority that verifies the server's identity. The browser and the server negotiate an encryption algorithm, which is used to create the encrypted connection.

When a client in the protected network initiates a TLS connection to an external server, the NGFW Engine checks whether the server’s certificate was signed by a certificate authority that is considered trusted. If the certificate was signed by a trusted certificate authority, the NGFW Engine makes a new certificate that matches the server's certificate. From the point of view of a user in the protected network, the process is invisible: the connection is established in the same way as a TLS connection made directly to the server.

When a server’s certificate is self-signed or has not been signed by a trusted certificate authority, the NGFW Engine cannot trust the server certificate. In this case, the NGFW Engine makes a new self-signed certificate. This certificate is presented to the user in the protected network. The user’s browser shows the same warning that it would show if it received a self-signed certificate directly from a server. In this case, the user must decide whether to accept the certificate.

When a server in the protected network is the destination of an incoming TLS connection, the NGFW Engine uses the server's credentials to decrypt and re-encrypt the traffic.