This certificate emulation process is commonly known as SSL interception or SSL bridging. Here’s how it works and the types of certificates involved:
1. Root Certificate Authority (CA) Certificate
- Description: This is a trusted certificate installed on the ProxySG device. The proxy uses this root CA certificate to sign emulated certificates.
- Role in Emulation: The root CA certificate acts as a trust anchor. It allows the ProxySG to issue new certificates (emulated certificates) for each HTTPS connection it intercepts.
2. Emulated Server Certificates
- Description: These are certificates generated by the ProxySG for each SSL session it intercepts.
- How it Works: When a client initiates a secure connection to a website, the ProxySG intercepts this connection. Instead of forwarding the connection directly to the server, the ProxySG establishes two SSL connections: one between the client and the proxy, and another between the proxy and the destination server.
- Between Client and Proxy: The ProxySG presents an emulated certificate to the client. This certificate is dynamically generated and signed by the ProxySG’s root CA. The emulated certificate mimics the original server's certificate, including details like the server's domain name.
- Between Proxy and Server: The ProxySG connects to the actual server using the server’s real certificate.
3. Intermediate Certificates (if applicable)
- Description: Sometimes, the ProxySG may also generate intermediate certificates.
- Role in Emulation: These intermediates can be used to create a chain of trust from the emulated server certificate back to the root CA installed on the ProxySG. This can be useful for more complex certificate hierarchies.
Practical Example
- Client Request: The client requests an HTTPS page from
https://<your_domain>.com
.
- Interception by ProxySG:
- The ProxySG intercepts this request.
- The ProxySG creates an SSL connection to
<your_domain>.com
and verifies the server’s certificate.
- Simultaneously, the ProxySG generates an emulated certificate for
<your_domain>.com
and signs it with its own root CA.
- Response to Client: The ProxySG sends the emulated certificate to the client.
- Client Trust: The client trusts the emulated certificate if the ProxySG’s root CA certificate is installed in the client’s trusted store.
- Data Flow: Encrypted traffic flows from the client to the ProxySG, gets decrypted for inspection, and then re-encrypted and sent to the actual server.
Key Points
- Trust: For this process to work seamlessly, the ProxySG’s root CA certificate must be trusted by the client devices. This often involves installing the ProxySG’s root CA certificate on all client devices.
- Transparency: To the client, it appears as if they are communicating directly with the server, although the ProxySG is decrypting and inspecting the traffic in between.
- Security and Privacy Considerations: While SSL interception allows for monitoring and filtering of HTTPS traffic for security purposes, it also involves handling sensitive data, requiring careful management to avoid privacy issues and ensure compliance with relevant regulations.
Note:
So, only if the emulated certificates intermittently seen on the browser triggers/presents a security pop-up to the the end user, because the browser does not trust the issuer used by the appliance, then you may have to download the CA certificate from the Proxy, and have the same installed in the trusted certificate store on the clients or client browsers.