Certificates for TLS inspection

TLS Inspection requires two separate secure connections: one from the client to the Secure SD-WAN Engine and one from the Secure SD-WAN Engine to the server. Substituting its own certificate for the original server certificate allows the Secure SD-WAN 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 Secure SD-WAN 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 Secure SD-WAN 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 Secure SD-WAN Engine cannot trust the server certificate. In this case, the Secure SD-WAN 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 Secure SD-WAN Engine uses the server's credentials to decrypt and re-encrypt the traffic.