TLS inspection

Security risks of encrypted traffic

Risk 1: Advanced attacks and data breaches go undetected by IPS
Attackers use HTTPS tunnels to deliver malicious payloads, exfiltrate data, or communicate with C2 servers. Encrypted traffic prevents the IPS engine from identifying attack signatures or data leaks. TLS inspection exposes plaintext traffic, enabling IPS to detect and block these threats.

Risk 2: Web filtering cannot enforce path-level controls over HTTPS traffic
Web filtering matches hostnames and paths in HTTP requests (such as example.com/upload/*). Without decryption, the firewall can only read the domain from SNI and cannot extract URL paths, causing fine-grained policies like “allow browsing but deny uploads” to fail. TLS inspection enables full path matching in HTTPS traffic.

Risk 3: Application identification accuracy drops under encryption, limiting control granularity
Application control uses deep packet inspection (DPI) to identify applications from payload data. Without decryption, DPI relies only on handshake information like SNI and certificates, making it impossible to distinguish behaviors under the same domain (for example, “browsing GitHub” versus “uploading to GitHub”). TLS inspection provides full traffic visibility for precise behavior identification.

Step 1: Configure a TLS inspection policy

On the TLS Inspection page, click Create TLS Inspection Policy above the policy list. The Create TLS Inspection Policy drawer appears on the right.

1. Associate Certificate.

   Parameter	Description
   Policy Name	Enter a descriptive name for the policy.
   Associate TLS Certificate	Select an existing certificate. Note When you create your first policy, the certificate dropdown includes an Apply for a Trial Certificate option. Click this to generate a test certificate for evaluating TLS inspection. A trial certificate can be used only once. In production, purchase and use your own certificate. Currently, only PCA certificates are supported. The certificate must meet the following requirements:  The certificate purpose must be set to "Internal enterprise use". Chinese cryptographic algorithm certificates are not supported. If you use the RSA private key algorithm, the key length must be at least 2048 bits. If you use the ECC private key algorithm, select P-256. If no certificates are available, click Buy Certificate to go to the Certificate Management Service console. When you purchase the certificate, ensure the PCA certificate purpose is set to "Internal enterprise use". What is a PCA certificate?.
   Certificate Validity	Displays the certificate validity period after selection. A warning appears when remaining validity drops below one year. Ensure certificates maintain at least one year of validity.
   Description	Enter a description for the policy.

   After configuring the parameters, click Next to proceed to the Configure Inspection Range step. The policy is created and saved when you proceed to the next step.

2. Configure Inspection Range.

   Important

   • The total quota for all inspection ranges is 20,000.

   • The quota consumed by a single TLS inspection policy is the sum of the quotas from all its inspection ranges.

   • A single inspection range consumes quota calculated as: number of source IP addresses × number of source port ranges × number of destination IP addresses × number of destination port ranges.

   Parameter	Description
   Protocol Type	Currently, only the TCP protocol is supported.
   Source IP Address	Select host IP addresses for outbound traffic inspection. Maximum: 1,000 addresses. Note Supported asset types: ECS EIP, ECS public IP, NAT EIP, EIP, and ENI EIP.
   Source Port	Specify ports in start port/end port format. Valid range: 0-65535. Separate multiple ranges with commas. Maximum: 100 ranges. Note All ports use range format, even for a single port. For example, 8080/8080 checks only port 8080. To check all ports, use 0/65535.
   Destination IP Address	Destination IP addresses that the source hosts access. Note You must use IPv4 addresses or address ranges in CIDR notation. For example: 192.0.2.0/24,8.8.8.8/32. You can enter up to 100 IP address objects. Separate multiple objects with commas (,). To represent all addresses, use 0.0.0.0/0.
   Destination Port	Destination service ports. Format: start port/end port. Valid range: 0-65535. Separate multiple ranges with commas. Maximum: 100 ranges.
   Description	Enter a description for the inspection range.
   Other operations	Save: Click Save below the Inspection Scope section to save the inspection range without clicking Next. After the scope is saved, Saved appears in the upper-right corner of the section. Add: Click Add an inspection range to add another inspection range. A single policy supports up to 10 inspection ranges. Delete: Click the icon in the upper-right corner of the Inspection Scope section to delete the current inspection range. After confirming the deletion, the range is immediately deleted without requiring you to click Next. Use this option with caution.

   After configuring the parameters, click Next to complete the policy configuration.

3. Review the policy information.

   After the policy is configured, the details of the policy and its inspection range are displayed. The Policy ID is included in the logs.

Step 2: Install the TLS certificate

Install the associated certificate on all hosts in the inspection scope.

1. Download the certificate.

   

   In the Configure TLS Inspection Policy list, find the policy that you created and click Download Certificate in the Actions column on the right. The certificate is downloaded to your local machine. Unzip the package to obtain the certificate file (.crt).

2. Log in to the source IP host.

   Log in to the host that you specified as the Source IP Address when you created the Inspection Scope. Upload the certificate to any directory on the host. Methods for transferring files.

3. Install the certificate.

   Copy the certificate to the OS trust store and run the update command. Steps vary by operating system.

   Note

   • If your TLS policy uses a subordinate CA certificate, you must install both the root CA and the subordinate CA.

   • The following examples apply to scenarios in which the trust store is the system trust store. If your application uses a different trust store, install the certificate in the correct trust store.

   CentOS/Alibaba Cloud Linux/Anolis/Red Hat

   1. Copy the certificate file: cp <certificate_file_name> /etc/pki/ca-trust/source/anchors/

   2. Update certificates: sudo update-ca-trust

   3. View the updated certificate: cat /etc/ssl/certs/ca-bundle.crt

      If the output displays the certificate content, the installation is successful.

      

   Ubuntu

   1. Copy the certificate file: cp <certificate_file_name> /usr/local/share/ca-certificates/

   2. Update certificates: sudo update-ca-certificates

   3. View the updated certificate:cat /etc/ssl/certs/ca-certificates.crt

      If the output displays the certificate content, the installation is successful.

      

   Windows

   Important

   • If you use a certificate that references a subordinate CA (intermediate CA), the native Certificate Manager in Windows does not install all CAs in a certificate chain file at once. It installs only the first CA in the file. In this scenario, you must manually split each CA content block into a separate file and then install each file.

   • Split the certificate by opening the downloaded and unzipped certificate file in a text editor, cutting the content block from -----BEGIN CERTIFICATE----- to -----END CERTIFICATE-----, and saving it as a new file with a .crt extension.

     

     After splitting:

   1. Install the certificate: Right-click the certificate file and click Install Certificate. Then, follow these steps:

      1	2	3

      Click Next to complete the certificate import.

   2. View imported certificates: Enter certmgr.msc in the Command Prompt to open the Certificate Manager.

      

   SUSE

   1. Copy the certificate file: cp <certificate_file_name> /etc/pki/trust/anchors

   2. Update certificates: sudo c_rehash .

   3. View the updated certificate: sudo trust list --filter=ca-anchors |grep -C 2 <Certificate CN>

      If the certificate information is displayed, the certificate is installed successfully.

      

   Fedora and Fedora CoreOS

   1. Copy the certificate file: sudo cp <certificate-file-name> /etc/pki/ca-trust/source/anchors/

   2. Update the certificates: sudo update-ca-trust extract

   3. View the updated certificate: sudo trust list --filter=ca-anchors |grep -C 2 <certificate_CN>

      If the certificate information is displayed, the certificate is installed successfully.

      

   Container Service (ACK)

   When outbound traffic originates from pods in an ACK cluster, install the PCA certificate inside each pod because the container environment is isolated from the host. If the nodes also initiate HTTPS requests (such as pulling images from a public repository), install the certificate on the nodes as well.

   Note

   • The following steps apply to Alibaba Cloud Linux 3.2104 LTS 64-bit (container-optimized) and are for reference only. Adjust the commands based on your operating system and business requirements.

   • Some of the following commands restart resources. To avoid business interruptions, we recommend that you perform these operations during off-peak hours.

   Install the certificate on nodes

   Log in to each node and run the following commands.

   1. Copy the certificate file: cp <certificate_file_name> /etc/pki/ca-trust/source/anchors/

   2. Update the certificates: sudo update-ca-trust

   3. View the updated certificate:cat /etc/ssl/certs/ca-bundle.crt

      If the certificate content is displayed, the certificate is installed.

   4. Restart the container service for the changes to take effect: sudo systemctl restart containerd.

   Install the certificate in pods

   1. Create a Secret in the console of the target cluster. The following is an example configuration. The key value is the content of the certificate file. For details about how to create a Secret, see Manage Secrets.Alternatively, you can run the following kubectl command to create the Secret, which has the same effect. You must replace ca_chain.crt in the command with the actual certificate filename.

      kubectl create secret generic cfw-pca-cert \
        --from-file=ca_chain.crt=./ca_chain.crt \
        -n default

   2. For a Deployment example, add the following content to its YAML file:

      1. Navigate to the spec.template.spec.containers field and add the following content to mount the certificate and update the truststore. In the content, secretName is the name of the Secret that you created in the previous step, for example, cfw-pca-cert.

         volumes:
                 - name: custom-ca-volume
                   secret:
                     secretName: cfw-pca-cert   
         volumeMounts:
                 - name: custom-ca-volume
                   mountPath: /etc/ssl/custom
                   readOnly: true  

      2. Continue to add the startup command under the spec.template.spec.containers field.

         Note

         The following example is based on the CentOS container system and is for reference only. Adjust the commands based on your operating system and business requirements.

         command:
                   - "/bin/sh"
                   - "-c"
                   - |
                     # 1. Install curl.
                     echo "Installing curl......"
                     yum install -y curl
         
                     # 2. Verify that the certificate is mounted. Replace ca_chain.crt with the actual certificate filename.
                     if [ ! -f /etc/ssl/custom/ca_chain.crt ]; then
                       echo "ERROR: Certificate file not found!"
                       exit 1
                     fi
         
                     # 3. Inject the certificate based on the steps for CentOS.
                     echo "Copying certificate to anchors directory..."
                     cp /etc/ssl/custom/ca_chain.crt /etc/pki/ca-trust/source/anchors/
         
                     echo "Updating CA trust store..."
                     update-ca-trust        
         
                     # 4. Keep the pod running.
                     echo "Pod ready for manual testing. Use 'kubectl exec' to test further."
                     sleep infinity

Step 3: Enable inspection and query traffic logs

1. After installing certificates on all hosts, enable the policy.

   Important

   When you enable TLS inspection, protection for new connections takes effect in about one minute. Existing persistent connections are not affected and will not be protected.

   For EIPs that are already protected and have TLS inspection enabled, disabling TLS inspection disrupts persistent connections. The duration of the disruption depends on your application's reconnection time.

   

   The TLS Inspection page lists all policies. Toggle the status switch to enable a policy. Once enabled, Cloud Firewall inspects encrypted outbound traffic per your configuration.

   Note

   You can delete a policy only when it is disabled.

2. Query traffic logs.

   After the inspected hosts generate traffic, in the left-side navigation pane of the Cloud Firewall console, choose Detection & Response > Log Audit.

   On the Traffic Logs > Internet Firewall tab, query the traffic generated by the hosts, including the matched TLS inspection policy and inspection range.

   The logs display the IDs of the policy and the inspection range.