What is Transport Layer Security inspection?

The Transport Layer Security (TLS) protocol uses certificates at the transport layer to ensure the privacy, integrity, and authenticity of data exchanged between two communicating parties. While TLS secures legitimate traffic, malicious traffic like malware and data leakage attacks can still hide behind encryption. The Microsoft Entra Internet Access TLS inspection capability provides visibility into encrypted traffic by making content available for enhanced protection, such as malware detection, data loss prevention, prompt inspection, and other advanced security controls. This article gives an overview of the TLS inspection process.

The TLS inspection process

When you enable TLS inspection, Global Secure Access decrypts HTTPS requests at the service edge. Advanced security controls, such as full URL filtering and file scan policies, are evaluated. If no security control blocks the request, Global Secure Access re-encrypts and forwards the request to the destination.

To enable TLS inspection, follow these steps:

1. Generate a certificate signing request (CSR) in the Global Secure Access portal and sign the CSR using your organization's root or intermediate certificate authority.
2. Upload the signed certificate to the portal.

Global Secure Access uses a two-tier certificate architecture. The customer-signed intermediate certificate is the first tier and is used to create a second short-lived intermediate certificate, which dynamically generates leaf certificates for TLS termination. TLS inspection establishes two separate TLS connections:

• One from the client browser to a Global Secure Access service edge
• One from Global Secure Access to the destination server

Global Secure Access uses leaf certificates during TLS handshakes between client devices and the service. To ensure successful handshakes, install your root certificate authority and the intermediate certificate authority (if used to sign the CSR) in the trusted certificate store on all client devices.

Traffic logs include four TLS-related metadata fields that help you understand how TLS policies are applied:

• TlsAction: Bypassed or Intercepted
• TlsPolicyId: The unique identifier of the applied TLS policy
• TlsPolicyName: The readable name of the TLS policy for easier reference
• TlsStatus: Success or Failure

To get started with TLS inspection, see Configure Transport Layer Security Policies.

Supported ciphers

Known limitations

TLS inspection has the following known limitations:

• TLS inspection supports up to 100 policies, 1,000 rules, and 8,000 destinations.
• Make sure each certificate signing request (CSR) you generate has a unique certificate name and isn't reused. The signed certificate must stay valid for at least six months.
• You can use only one active certificate at a time.
• TLS inspection doesn't support HTTP/2 negotiation. Most sites automatically fall back to HTTP/1.1 and continue to work, but sites that require HTTP/2 won't load if TLS inspection is enabled. Add a custom TLS bypass rule to allow access to HTTP/2-only sites.
• TLS inspection doesn't follow Authority Information Access (AIA) and Online Certificate Status Protocol (OCSP) links when validating destination certificates.

Mobile platform

• Many mobile applications implement certificate pinning, which prevents successful TLS inspection, resulting in handshake failures or loss of functionality. To reduce risk, enable TLS inspection in a test environment first and validate that critical applications are compatible. For apps that rely on certificate pinning, configure TLS inspection custom rules to bypass these destinations using domain-based or category-based rules.

Related content

• Configure Transport Layer Security Policies
• Configure Transport Layer Security Settings
• Frequently asked questions for Transport Layer Security inspection