SIA Proxy MITM certificate

The HTTPS/TLS protocol is designed to provide authentication, confidentiality, and integrity by protecting traffic from a 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. SIA Proxy is a "trusted intermediary" that is able to decrypt, inspect and re-encrypt all TLS traffic from enterprise managed computers. This gives SIA 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.

SIA Proxy uses a MITM 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 needs to be deployed on all enterprise computers.

📘
SIA Proxy supports TLS 1.3, 1.2, 1.1, and 1.0. For a list of supported cipher suites, see Supported cipher suites.

You can use either an Akamai certificate or a non-Akamai MITM CA TLS certificate:

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 SIA. 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 SIA 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 MITM certificate. The dynamically generated certificate contains some of the attributes and extensions of the origin certificate.

Make sure that you or another SIA administrator receives system issue notifications. 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 Scheduled reports and notifications.

When managing these certificates in SIA, make sure that you keep track of the certificate expiration date. In SIA, 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 SIA, 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 Bypass list.

📘
By default, SIA Proxy avoids intercepting traffic with the MITM TLS certificate when websites request client certificates. This prevents traffic to these websites from breaking, as TLS certificates require end-to-end authentication and are inherently incompatible with TLS inspection. However, with the Invalid Certificate Response setting in a policy, you can select the Block - Error Page action to block these websites and show an error page. For more information, see Unverifiable origin certificates.