ETP Proxy as a TLS intermediary
The HTTPS/TLS protocol is designed to provide authentication, confidentiality, and integrity by protecting traffic from a man-in-the-middle (MITM) or a malicious user who may try to sniff, divert, or modify traffic. However, the protocol may be abused by attackers who hide malicious behavior within TLS protected traffic. ETP Proxy is a “trusted intermediary” that is able to decrypt, inspect and re-encrypt all TLS traffic from enterprise managed computers. This gives ETP visibility into TLS encrypted traffic and allows it to protect an enterprise from threats, while preserving confidentiality and integrity of traffic to origin web sites.
ETP Proxy uses a MITM certificate authority (CA) TLS certificate to generate and sign MITM origin certificates for HTTPS web sites that go through it. For enterprise client computers to accept and trust these certificates, the trusted MITM CA root certificate must be deployed on all enterprise computers.
- If you use an Akamai certificate, Akamai generates and signs the certificate that you download and distribute to your client computers. See Create an Akamai certificate.
- If your company already has a public key infrastructure (PKI) in place, generate an intermediate CA certificate that is signed by the company root CA, which is already trusted by the computers in your network. To do this, generate and download a certificate signing request (CSR) from ETP. Then, submit this signing request to your existing root CA and obtain the signed intermediate MITM CA certificate. Upload this signed intermediate MITM CA certificate to ETP in order to sign MITM certificates for the inspected origin web sites. See Create a non-Akamai certificate.
From these certificates, a short-lived CA is generated to sign the certificate that is supplied for the new TLS man-in-the-middle certificate. The dynamically generated certificate contains some of the attributes and extensions of the origin certificate.
Make sure that you or another ETP administrator receives communication emails for system issues. When the certificate expires in 30 days or less, administrators who receive system issue emails are notified about the certificate expiration. The email advises administrators to regenerate or upload a new certificate. To configure who receives these emails, see Add email addresses for notifications and Assign email notifications.
When managing these certificates in ETP, make sure that you keep track of the certificate expiration date. In ETP, you can see this information after a certificate is distributed and activated in your network. Before the certificate expires, repeat the process to generate and distribute the certificate in your network.
If there are domains that use an unsupported protocol or cannot use the MITM certificate that is generated or uploaded into ETP, you can select to allow or block these domains in your network. For instructions, see Allow or block domains incompatible with TLS MITM certificate. To review which domains are incompatible with the MITM certificate by default, see Akamai bypass list.