TLS Inspection in Microsoft Entra GSA Internet Access – Complete Configuration Guide

Introduction

Today, over 95% of internet traffic is encrypted with TLS (Transport Layer Security). While encryption is essential for privacy and security, it also introduces challenges, malware, phishing payloads, or data exfiltration attempts can hide inside encrypted tunnels, evading traditional security controls.

This is where Microsoft Entra Global Secure Access (GSA) Internet Access comes in. With its TLS inspection capability, GSA allows organizations to securely decrypt, inspect, and re-encrypt traffic at Microsoft’s secure service edge ,providing visibility without compromising protection.

In this blog, we’ll explore how TLS inspection works in Entra GSA, its benefits, limitations, and best practices for a smooth deployment.

Why TLS Inspection Matters

Good and bad sides of encryption

• TLS ensures confidentiality, integrity, and authenticity of communications.

• But attackers leverage the same encryption to conceal malicious activities.

The visibility gap

• Security teams can no longer rely on inspecting clear-text traffic.

• Without TLS inspection, threats like data leaks or malware hidden in HTTPS traffic go unnoticed.

Microsoft’s approach

• Entra GSA integrates TLS inspection directly into its Internet Access service.

• It brings inspection closer to users, reducing reliance on legacy appliances or complex on-premises solutions.

How TLS Inspection Works in Entra GSA

1. Certificate Setup

• Admin generates a Certificate Signing Request (CSR) in the GSA portal.

• The CSR is signed by the organization’s trusted CA.

• The signed certificate is uploaded to GSA and used as an intermediate CA for TLS inspection.

2. Dual TLS Handshake

• Client connects to the GSA edge. GSA presents a dynamically generated leaf certificate for the requested domain.

• Simultaneously, GSA initiates its own TLS session with the actual destination server.

3. Traffic Decryption & Inspection

• GSA decrypts the client’s traffic at the edge.

• Security controls (web filtering, DLP, malware scanning) are applied.

4. Re-Encryption & Forwarding

• If compliant, the traffic is re-encrypted and forwarded to the destination.

• Responses follow the same process in reverse.

5. Logging & Metadata

• Rich telemetry is captured:- TlsAction (Intercepted/Bypassed), TlsStatus, TlsPolicyId, etc. for monitoring and auditing.

Note: To ensure successful handshakes, install your root certificate authority, and intermediate certificate authority if used for signing the CSR, in the trusted certificate store on all client devices.

Key Benefits

• Deep visibility into encrypted traffic – Detect hidden malware, exfiltration, or shadow IT.

• Enhanced enforcement of security policies – Apply DLP, threat protection, and compliance rules to HTTPS flows.

• Unified experience – Natively integrated into Microsoft’s Global Secure Access stack, simplifying architecture.

• Improved risk posture – Reduce blind spots created by encrypted traffic.

Deploy Transport Layer Security inspection

Prerequisites

Before you begin configuring TLS inspection in Entra Global Secure Access, ensure the following requirements are in place:

• Public Key Infrastructure (PKI) Service – A PKI service is required to sign the Certificate Signing Request (CSR) and issue an intermediate certificate for TLS inspection. For lab or testing scenarios, you can alternatively use a self-signed root certificate generated with OpenSSL.

• Test Devices or Virtual Machines – At least one Windows device or VM joined to Microsoft Entra ID (cloud-joined or hybrid-joined) is needed to validate the setup and perform inspection testing.

• Microsoft Entra Internet Access License – A trial or active license for Microsoft Entra Internet Access must be assigned to the users .

• Global Secure Access Prerequisites – Ensure the base requirements for Global Secure Access are already met (such as Global Secure Access client installation and necessary policy configurations).Refer my previous blog How to Configure Microsoft Entra Global Secure Access Internet Access with Web Filtering Policies  

1. Generate and Upload a Signed Certificate

As a Global Secure Access Administrator, do the following: Sign in to the Microsoft Entra admin center. Navigate to Global Secure Access > Secure > TLS inspection policies.

Open the TLS inspection settings tab. Select + Create certificate to begin generating a Certificate Signing Request (CSR).

In the Create certificate pane, provide the required details:

Certificate name – A unique identifier with no spaces, maximum 12 characters. Example: DemoTLSCA.

Common Name (CN) – The intermediate certificate identifier (e.g., Demo TLS ICA).

Organizational Unit (OU) – Your organizational unit, such as Contoso IT.

Select Create CSR. The system generates a .csr file, which is automatically saved to your download folder.

2. Sign the CSR

Use your organization’s PKI service to sign the Certificate Signing Request (CSR). When issuing the certificate, ensure the following properties are correctly configured:

• Extended Key Usage: Server Authentication must be included.

• Certificate Authority (CA): set to true.

• Key Usage: must include keyCertSign and cRLSign.

• Basic Constraints: critical, CA:TRUE.

Save the resulting signed certificate in .pem format for later upload.

Testing with a Self-Signed Root CA (OpenSSL)

For lab or proof-of-concept scenarios, you can bypass a full PKI and instead use a self-signed root certificate authority created with OpenSSL to sign your CSR.

To test with OpenSSL: Download and install Open SSL from the following website 

After installing OpenSSL on your Windows device, navigate to the installation directory:

C:\Program Files\OpenSSL-Win64  

Inside this directory, create a new configuration file named openssl.cnf. This file will hold the certificate authority (CA) settings required for generating and signing certificates.

Paste the following configuration into the file:

[ rootCA_ext ]

subjectKeyIdentifier = hash

authorityKeyIdentifier = keyid:always,issuer

basicConstraints = critical, CA:true

keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ interCA_ext ]

subjectKeyIdentifier = hash

authorityKeyIdentifier = keyid:always,issuer

basicConstraints = critical, CA:true, pathlen:1

keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ signedCA_ext ]

basicConstraints = critical, CA:true

keyUsage = critical, digitalSignature, cRLSign, keyCertSign

extendedKeyUsage = serverAuth

[ server_ext ]

subjectKeyIdentifier = hash

authorityKeyIdentifier = keyid:always,issuer

basicConstraints = critical, CA:false

keyUsage = critical, digitalSignature

extendedKeyUsage = serverAuth

Using the openssl.cnf configuration file you prepared earlier, you can generate a new root certificate authority (CA) and use it to sign the CSR.

Create a New Root CA and Private Key

Run the following command to generate a self-signed root CA certificate and private key:

openssl req -x509 -new -nodes -newkey rsa:4096 -keyout rootCAchain.key -sha256 -days 370 -out rootCAchain.pem -subj "/C=US/ST=US/O=Self Signed/CN=Self Signed Root CA" -config openssl.cnf -extensions rootCA_ext

In my Example i am going to save the keys in C:\GSATLS folder and .cnf file i kept in C:\Program Files\OpenSSL-Win64\

openssl req -x509 -new -nodes -newkey rsa:4096  -keyout "C:\GSATLS\rootCAchain.key" -sha256 -days 370 -out "C:\GSATLS\rootCAchain.pem" -subj "/C=US/ST=US/O=Self Signed/CN=Self Signed Root CA" -config "C:\Program Files\OpenSSL-Win64\openssl.cnf" -extensions rootCA_ext

This creates:

rootCAchain.key – The private key for your root CA.

rootCAchain.pem – The self-signed root certificate.

CSR Signing

Next, use your newly created root CA to sign the CSR generated in the Entra admin center:

openssl x509 -req -in <CSR file> -CA rootCAchain.pem -CAkey rootCAchain.key -CAcreateserial -out signedcertificate.pem -days 370 -sha256 -extfile openssl.cnf -extensions signedCA_ext

In my example CSR file i kept in C:\GSATLS and the same directory will be used to generate the PEM file

openssl x509 -req -in "C:\GSATLS\65d56830-e313-460c-a5cb-0215a0aec33b_GSATLSCA.csr" -CA "C:\GSATLS\rootCAchain.pem" -CAkey "C:\GSATLS\rootCAchain.key" -CAcreateserial -out "C:\GSATLS\signedcertificate.pem" -days 370 -sha256 -extfile "C:\Program Files\OpenSSL-Win64\openssl.cnf" -extensions signedCA_ext

This produces signedcertificate.pem, which can be uploaded into Microsoft Entra Global Secure Access for TLS inspection testing.

⚠️ Important: Self-signed certificates are only suitable for testing. For production deployments, always use a trusted enterprise PKI or certificate authority.

After signing the CSR, you’ll have two key files:

signedcertificate.pem – The certificate signed by your CA (or self-signed for testing).

rootCAchain.pem – The root or intermediate CA certificate.

Upload both files back into the Microsoft Entra admin center, which we created earlier. These certificates will enable TLS termination and inspection within Global Secure Access.

Once the certificate is uploaded, its status will appear as Enrolling. This indicates that Global Secure Access is provisioning and configuring the necessary backend services. Once ready it will show the status as Active.

The root CA certificate generated earlier needs to be converted into a format that client devices can trust. This certificate can then be deployed to endpoints via Intune, Group Policy (GPO), or installed manually.

To create a client-friendly .cer file, run the following OpenSSL command:

openssl x509 -in rootCAchain.pem -outform DER -out rootCAchain.cer

In our example, the full command looks like this:

openssl x509 -in "C:\GSATLS\rootCAchain.pem" -outform DER -out C:\GSATLS\rootCAchain.cer

The output file rootCAchain.cer is now ready for distribution and installation on client machines.

3. Create a TLS Inspection Policy

As a Global Secure Access Administrator, follow these steps to create a TLS inspection policy: In the Microsoft Entra admin center, navigate to Secure > TLS inspection policies.

Select + New policy and set the Action to Inspect. Click Next

Destination will be selected all, 

Once saved, TLS termination will be enabled for all traffic categories except the following, which are excluded by default for privacy and compliance reasons:

• Education

• Finance

• Government

• Health & Medicine

Click Next then Review ,Press Submit to save the configuration

4. Link the TLS Inspection Policy to a Security Profile

Before enabling TLS inspection on user traffic, ensure your organization has clearly defined and communicated a Terms of Use (ToU) for end users. This step is essential for transparency and compliance with privacy or consent requirements.

You can associate a TLS inspection policy with a security profile in two ways. The simplest approach is to link it to the baseline profile, which applies to all user traffic including Remote Network Traffic.

Option 1: Link to the Baseline Profile (applies to all users)

In the Microsoft Entra admin center, go to Secure > Security profiles.

Open the Baseline profile tab. Select Edit profile.

Under Link policies, choose + Link a policy > Existing TLS inspection policy.

In the Link a TLS inspection policy view, select the TLS policy you created earlier and assign a priority. Click Add to save the configuration.

This ensures TLS inspection is applied to all user traffic unless bypass rules or exceptions are defined.

Option 2: Link to a Security Profile for Specific Users or Groups

If you prefer more granular control, you can associate the TLS inspection policy with a custom security profile and then apply it only to selected users or groups through a Conditional Access policy.

This approach allows you to pilot TLS inspection with targeted groups or roll it out gradually across the organization, rather than applying it to all users at once.

Custom Security Profile Configuration and CA policy creation you can refer my previous Blog How to Configure Microsoft Entra Global Secure Access Internet Access with Web Filtering Policies

5. Testing TLS Inspection Policy

Before TLS inspection can work seamlessly, all client devices must trust the root certificate used for decrypting and re-encrypting traffic. The recommended approach is to deploy the trusted root certificate through Intune for managed Windows devices. Alternatively, you can distribute it via Group Policy (GPO) or install it manually on individual machines.

Testing the Configuration

1. Verify certificate installation

• Confirm that the root certificate is present in the Trusted Root Certification Authorities store on the test device.

2. Set up the Global Secure Access client

• Ensure the GSA client is already installed and configured.

3. Browse test websites

• Open a browser on a client device and visit various websites.

• Check the certificate details in the browser.

• Confirm that the traffic is being intercepted and that the certificate chain includes the Global Secure Access certificate.

A successful test shows the Global Secure Access certificate in use, confirming that TLS inspection is functioning properly.

6. Monitor TLS Inspection in Logs

You can track TLS inspection activity through the Global Secure Access Traffic Logs. The logs provide detailed insights, including:

TLS Action – Whether the traffic was Intercepted or Bypassed.

TLS Status – The outcome of the TLS handshake (e.g., Success or Failure).

TLS Policy ID – The identifier of the policy applied.

TLS Policy Name – The friendly name of the inspection policy in effect.

Reviewing these logs helps validate policy enforcement, troubleshoot issues, and confirm whether TLS inspection is operating as expected.

Microsoft Traffic is Bypassed

Govt Site GSA TLS Bypass Default

Limitations & Considerations

While powerful, TLS inspection also comes with constraints

Bypass Lists

• Built-in categories (e.g., Finance, Healthcare, Government, Education) are excluded from inspection by default.

• Custom bypass rules can be added for sensitive or incompatible services.

Certificate Handling

• Only one active certificate can be used at a time.

• Certificates must be valid for at least one year.

Protocol Challenges

• Limited HTTP/2 and ALPN v2 support may cause handshake failures.

• Certificate revocation checking (OCSP, AIA) is not performed.

Mobile App Incompatibility

• Many apps use certificate pinning and will fail if inspected.

• TLS inspection is currently recommended primarily for Windows devices.

Privacy & Compliance

• Decrypting user traffic raises regulatory and user trust concerns.

• Sensitive data flows should be exempted through bypass rules.

Deployment Best Practices

1. Pilot First – Start small with test groups before full rollout.
2. Maintain Bypass Lists – Regularly update and review exclusions.
3. Manage Certificates Proactively – Plan renewals and distribute trusted roots across devices.
4. Monitor Logs – Track bypass rates, handshake errors, and policy hits.
5. Communicate Clearly – Keep IT, compliance, and end-users informed about inspection policies.
6. Platform Segmentation – Focus on managed Windows devices to reduce breakage.
7. Stay Updated – TLS inspection is still in preview, and Microsoft may expand capabilities (e.g., HTTP/2 support).

Looking Ahead

As encrypted protocols evolve (TLS 1.3, Encrypted SNI, Encrypted DNS), inspection will remain complex. Microsoft is actively improving TLS inspection in GSA ,future updates may address HTTP/2, mobile app compatibility, and finer-grained controls.

Organizations should treat TLS inspection as a strategic security layer, used carefully, with transparency, and aligned to compliance requirements.

Conclusion

TLS inspection in Entra Global Secure Access Internet Access provides organizations with much-needed visibility into encrypted traffic. It enables advanced security controls while leveraging Microsoft’s secure edge infrastructure.

However, successful deployment requires planning, balancing security, privacy, and user experience. With a phased rollout, strong governance, and active monitoring, TLS inspection can become a cornerstone of modern Zero Trust security.