Frequently asked questions for Transport Layer Security inspection (preview)

TLS inspection decrypts and analyzes encrypted network traffic to help organizations detect threats, enforce security policies, and prevent data exfiltration. With the majority of internet traffic now encrypted, TLS inspection provides visibility into data flows that would otherwise be opaque to security tools. TLS inspection enables enterprises to apply advanced protections such as content filtering without compromising the confidentiality of legitimate communications.

TLS inspection enables organizations to analyze encrypted network traffic by decrypting it for security inspection and re-encrypting it before forwarding it to its destination. To implement TLS inspection effectively, consider the following operational best practices:

• Communicate clearly with users: Before enabling TLS inspection in a production environment, ensure users are informed about how encrypted traffic is handled. Many organizations choose to provide a Terms of Use (ToU) or similar notice.
• Select a certificate authority: Choose a root or intermediate certificate authority to sign the Certificate Signing Request (CSR) created by Global Secure Access for TLS inspection.
• Define a TLS policy: Configure a TLS inspection policy that aligns with your organization's security and operational requirements.
• Configure Conditional Access: Create a Conditional Access policy and associate it with the Global Secure Access security profile linked to the TLS policy.
• Distribute the trusted certificate: Ensure the selected certificate authority is installed on all client devices to establish trust and enable seamless TLS inspection.

TLS inspection requires an intermediate certificate authority, ensure you are using the Subordinate CA template. To sign CSR generated from TLS settings, you may use AD CS web enrollment UI or use the certreq command-line tool.

certreq -submit -attrib "CertificateTemplate:SubCA" "C:\pathtoyourCSR\tlsca.csr" "tlsca.cer"

This error occurs because certain developer tools (such as Git) don't use the operating system's certificate store by default; instead, they maintain their own certificate store. You may direct git to use windows' certificate store:

git config --global http.sslbackend schannel

or to append the certificate to Git's Certificate Authority bundle. The following PowerShell script demonstrates how to add the certificate to Git's CA bundle on a Windows system.

# Define the path to your custom root Certificate Authorities
  $certPath = "./myTLSInspectionRootCA.crt"
# Verify the certificate file exists
  if (-Not (Test-Path $certPath)) {
  Write-Host "Certificate file not found at $certPath"
  exit 1
  }
# --- Git Configuration ---
 $gitCAPath = git config --get http.sslcainfo
 if ($gitCAPath) {
 try {
 Get-Content $certPath | Add-Content -Path $gitCAPath
 Write-Host "Certificate appended to Git CA bundle at $gitCAPath"
 } catch {
 Write-Host "Failed to append certificate to Git CA bundle $_"
}
} else {
Write-Host "Git CA bundle path not found. Is Git installed and configured?"
}

Certificate pinning is a security mechanism that restricts an application's TLS connections to a specific set of trusted certificates or public keys. Certificate pining ensures that the application only communicates with servers presenting those exact credentials, even if other certificates are valid and trusted by the system. This technique helps defend against man-in-the-middle (MITM) attacks by preventing unauthorized interception of encrypted traffic. However, it also interferes with network security tools that rely on TLS inspection, which works by decrypting and re-encrypting traffic using an intermediary certificate.

The connection fails if TLS inspection terminates traffic from applications that use certificate pinning. To ensure your applications work as expected, create a custom bypass rule in the traffic forwarding profile to exclude traffic from these applications from Global Secure Access. You can perform this operation as part of custom bypass in the Internet access forwarding profile. We're working on custom TLS rules to let you acquire traffic and bypass TLS inspection only.

Microsoft Entra TLS inspection enables TLS 1.2 and TLS 1.3 by default. The highest mutually supported version is selected for the session, from the client to Global Secure Access and from Global Secure Access to the destinations. Microsoft Entra doesn't support TLS 1.3 with Encrypted Client Hello (ECH) because the Server Name Indication (SNI) is encrypted, which prevents Global Secure Access from creating the corresponding leaf certificates for TLS termination.

We recommend bypassing TLS inspection for these destinations. TLS 1.2 is the minimum recommended version because older versions, like TLS 1.1 and TLS 1.0, aren't secure and are vulnerable to attacks. When possible, move these applications to support TLS 1.2 or higher.

We use software-protected keys. Global Secure Access intermediate certificate keys are stored in memory to dynamically generate leaf certificates for websites. While these keys aren't protected by an HSM, access to our servers is highly restricted, and we use strict security controls to safeguard key access and system integrity.

Content-based security controls have dependencies on TLS inspection, including URL-enhanced web category filtering, anti-malware, DLP, ATP, and others. Additionally, Global Secure Access block notifications require you to enable TLS inspection.

Related content

• What is Transport Layer Security inspection?
• Configure Transport Layer Security