Click here for the Japanese version of this article.

Introduction

If you're using Microsoft Entra Global Secure Access (GSA) – Internet Access, this guide shows how to enable and operate TLS Inspection in your environment.

TLS Inspection explained with a mail analogy

Without TLS Inspection

The “envelope” (traffic) is sealed and encrypted.
The “post office” (the network admin/GSA) cannot open it.
Even if the letter is a scam, nobody notices.
→ Only destination checks (URL/domain-level control) are possible. The content is opaque, so auditing is not feasible.

With TLS Inspection

The post office (GSA) securely opens the envelope once.
It inspects the contents (URLs, files, prompts, etc.).
If safe, it repackages and re-encrypts the envelope, then forwards it.
If the content is phishing, malware, or otherwise harmful, it gets blocked.
→ Because the content is visible, advanced actions like threat evaluation, AI prompt inspection, and file analysis become possible.

In short, TLS Inspection in GSA performs secure TLS interception: GSA decrypts HTTPS traffic, inspects it, and re‑encrypts it before forwarding. This enables granular governance and advanced protection while maintaining end‑to‑end control.

Diagram excerpted from the following resources:

What is Transport Layer Security inspection?
https://learn.microsoft.com/en-us/entra/global-secure-access/concept-transport-layer-security?wt.mc_id=MVP_407731

Microsoft Entra Blog: TLS Inspection now in Microsoft Entra Internet Access
https://techcommunity.microsoft.com/blog/microsoft-entra-blog/tls-inspection-now-in-microsoft-entra-internet-access/4395972

Note
Enabling TLS Inspection by itself gives you visibility into encrypted traffic (auditing).
To take actions (e.g., block), combine TLS Inspection with the policy types below.

Policy Type	TLS Inspection Required?	Why
Web Content Filtering	Recommended	HTTPS URL categorization requires decryption
Threat Intelligence Policies	Required	Improves detection for malicious URLs and C2 communication
File Policies	Required	Needed to inspect file contents
Prompt Policies	Recommended	URL-level blocking works without TLS; Prompt Shield requires decrypted content
Threat Protection Policies	Recommended	Without TLS you can only control URL/domains; with TLS you gain layered inspection
Netskope DLP Policies	Not required	Decryption happens on the Netskope side
Cloud Firewall Policies	Not required	Layer 3/4 controls only

In other words, TLS Inspection is effectively a prerequisite to get full value from the first five policy types above.

Prerequisites

To configure TLS Inspection for GSA, ensure the official prerequisites are met:

Official reference: Prerequisites
https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-transport-layer-security-settings?wt.mc_id=MVP_407731#prerequisites

Summarized:

Certificate Authority (CA)
Microsoft Entra Internet Access license
Global Secure Access prerequisites

1) Certificate Authority

This is often the most confusing part of a production rollout.
Microsoft’s documentation shows OpenSSL as a test option but doesn’t prescribe a production PKI.

A Public Key Infrastructure (PKI) service to sign the Certificate Signing Request (CSR) and generate an intermediate certificate for TLS inspection. For testing scenarios, you can also use a self-signed root certificate created with OpenSSL.

This guide uses Active Directory Certificate Services (AD CS) with production in mind.
Prepare a server and create a standalone CA (or, in an AD domain, an Enterprise CA is recommended) using the following article. If you already operate AD CS, you can reuse it.

Deploying Active Directory Certificate Services (AD CS)
https://qiita.com/carol0226/items/cb38ed3188c520bd9d64

2) Microsoft Entra Internet Access license

Configure GSA Internet Access following:

[GSA:Internet] Configure Microsoft Entra Internet Access
https://qiita.com/carol0226/items/ae2bfdb209170fb41bae

3) Global Secure Access prerequisites

Make sure all prerequisites are satisfied (it’s fairly extensive):

[GSA: Internet] How to Meet All Prerequisites for Internet Access
https://qiita.com/carol0226/items/29197f33c6537cd2b0e5

Certificate Creation and Deployment

We’ll proceed in this order:

Create a CSR
Sign the certificate using AD CS
Upload the signed certificate
Distribute the AD CS root certificate to clients
Create a TLS Inspection policy
Assign the TLS Inspection policy to a Security Profile
Test the configuration

Reference
In my walkthrough, steps 1–3 are explained with manual procedures and screenshots.
Microsoft has since published a PowerShell-based end‑to‑end method (not tested here):

Generate and sign TLS certificates using AD CS with PowerShell
https://learn.microsoft.com/en-us/entra/global-secure-access/scripts/powershell-active-directory-certificate-service?wt.mc_id=MVP_407731

1. Creating the CSR

For TLS Inspection to function, GSA must operate as an intermediate certificate authority, issuing on‑the‑fly server certificates for inspected HTTPS sessions.
To enable this, you must generate a Certificate Signing Request (CSR) in GSA and have it signed by your upstream CA (AD CS).

Key point
Client devices trust your organization’s root CA.
Once GSA is recognized as a subordinate CA, any certificate it issues during TLS interception is automatically trusted by clients.

Official reference:
Create a CSR and upload the signed certificate
https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-transport-layer-security-settings?wt.mc_id=MVP_407731#global-secure-access-admin-create-a-csr-and-upload-the-signed-certificate-for-tls-termination

Steps

Sign in to the Microsoft Entra admin center as a Global Secure Access Administrator:
https://entra.microsoft.com
Follow these steps:
① From the left navigation, select TLS inspection policy
② Open the TLS inspection settings tab
③ Select + Create certificate
④ Fill in the following required fields:
- Certificate name:
  Shown in certificate hierarchy views. Must be unique, without spaces, and ≤12 characters.
  Note: You cannot reuse a deleted certificate name.
- Common Name (CN):
  A meaningful name for your intermediate CA (e.g., Contoso TLS ICA).
- Organization Unit (OU):
  Example: Contoso IT.
⑤ Select Create CSR.
After creation, a notification appears:

A .csr file is downloaded:

You should now see the generated certificate entry listed:

2. Signing the Certificate Using AD CS

1 . Open your browser and navigate to:
http://<ADCS-server-ip>/certsrv

2 . When the page loads, select Request a certificate:

3 . Select advanced certificate request:

4 . Open the downloaded .csr file in Notepad and copy only the base64 body (exclude the BEGIN and END headers).

5 . Paste the CSR into the form, select the Subordinate Certification Authority template (must choice), then click Submit.

6 . Choose Base 64 encoded, then download both:

The issued certificate
The certificate chain

3. Uploading the Signed Certificate

The certificates downloaded from AD CS cannot be uploaded directly to GSA.

Important
AD CS outputs:

Root certificate → certnew.cer
Certificate chain → certnew.p7b

GSA requires certificates in PEM (.pem) format.

Converting to PEM format

① Convert the root certificate

Copy certnew.cer and rename the file extension to .pem.
GSA accepts this file directly.
(Keep the .cer version as it will be needed later.)

② Convert and extract the certificate chain

Open certnew.p7b. Export both certificates in Base 64 encoded .cer format.

First certificate (root):

Second certificate (intermediate):

When exporting, ensure Base 64 is selected:

Save the certificates as .cer files:

Root certificate:

Intermediate certificate:

③ Create a combined certificate chain

Open a new Notepad file and paste both certificates back‑to‑back.
Save the file as Chain.pem.

④ Upload the certificate to GSA

In the TLS Inspection Settings page, upload the .pem files and select Upload signed certificate.

A notification confirms a successful upload:

Initially, the certificate state shows Disabled.
From the action menu, select Enable.
It briefly enters the “Registering” state.

After enabling, the certificate becomes Enabled:

At this point, you can confirm that AD CS has issued the subordinate certification authority (SubCA) certificate as shown below.

When you open the certificate by double‑clicking it, you can verify the following details.
General tab

Details tab

Certification Path tab

At this point, the intermediate CA configuration is complete.

4. Deploying the AD CS Root Certificate to Client Devices

Once the intermediate certificate is configured in GSA, client devices must trust the root certificate issued by your AD CS environment.
Below are the supported deployment options.

① Manual installation on a single client

For testing on an individual machine, follow the steps in the article below:

How to download and install the AD CS root certificate on a client PC
https://qiita.com/carol0226/items/33042c5c639c79832aeb

② Domain‑joined devices using an AD CS Enterprise CA

If you're operating an Enterprise CA, domain‑joined devices automatically receive the root certificate through Active Directory Group Policy.
No additional configuration is required.

③ Deploying the root certificate using Intune

For production environments with many devices, Intune distribution is recommended.

The following guide uses screenshots generated from this exact GSA setup, ensuring full consistency:

Deploying trusted root certificates with Intune
https://qiita.com/carol0226/items/6b016907fd41001ab305

Key point
Although GSA uses an intermediate certificate, client devices only need the root certificate.
If the root CA is trusted, the entire chain—including the GSA intermediate CA—is validated automatically.
Therefore, if your organization already distributes the root certificate, all you need to do is sign the CSR as a subordinate CA.

5. Creating a TLS Inspection Policy

Now that certificate trust is in place, the next step is to configure a TLS Inspection Policy in GSA.
Any category or URL marked as Inspect will have its HTTPS traffic decrypted and inspected.

Official reference:
Step 1: Create a TLS Inspection Policy
https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-transport-layer-security?wt.mc_id=MVP_407731#step-1-global-secure-access-admin-create-a-tls-inspection-policy

Steps

1 . In the Microsoft Entra admin center, open Global Secure Access → Secure → TLS inspection policy, then select + Create policy.

2 . In the Basics tab, enter a descriptive name and set the action to Inspect, then select Next.

3 . In the Rules tab, retain the default rule set unless you need custom exceptions.
Select Next.

4 . Review the configuration, then select Submit.

After creation, the policy appears in the list.
You can confirm settings via … → Edit.

In the policy details, you will see:

Built‑in system bypass rules
Rule 65000 (Education, Finance, Government, Health & Medicine)
All other categories will be inspected by default

This completes the default TLS Inspection Policy configuration.

Tip
To inspect categories that are bypassed by default, create a rule with Inspect.
To bypass categories that are normally inspected, create a rule with Bypass.

Optional: Adding exception rules

If needed, you can customize inspection behavior by adding additional rules.

Select + Add rule:

Example: Inspect Rakuten Securities (normally bypassed under “Finance”)

Example: Bypass a category normally inspected (Hosted Payment Gateways)

After adding custom rules, the policy may look like this:

Reference: Web Content Filtering Categories
https://learn.microsoft.com/en-us/entra/global-secure-access/reference-web-content-filtering-categories?wt.mc_id=MVP_407731

6. Assigning the Policy to a Profile

Creating a TLS Inspection Policy alone does not activate TLS decryption.
The policy must be assigned to a Security Profile before GSA begins inspecting traffic.

For details, see the article below:

[GSA : Internet] Summary of Profile Settings for Applying Policies
https://qiita.com/carol0226/items/1d9fa23904947c8598fd

Important
TLS Inspection becomes effective only after a Security Profile has been configured to use the policy.
Without the assignment step, no traffic will be inspected.

7. Testing the Configuration

After completing all configuration steps, validate that TLS Inspection functions correctly.
The simplest approach is to compare behavior with Internet Access enabled vs. disabled.

Whenever toggling the feature on or off, remember to clear your browser’s cache.

Official reference:
Step 4: Test the configuration
https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-transport-layer-security#step-4-test-the-configuration

Clearing cache in Microsoft Edge

Viewing certificate details in Microsoft Edge

Select the lock icon → click the highlighted area:

Then click the certificate icon to display certificate details:

TLS Inspection disabled

When accessing qiita.com, the certificate appears as issued by Amazon:

The certificate chain shows a standard 3‑level hierarchy rooted at Amazon:

TLS Inspection enabled

With the feature enabled, the certificate for qiita.com is issued by:

Microsoft Global Secure Access Intermediate CA2

The certification path now forms a 4‑level chain, anchored by your AD CS root certificate:

Scrolling reveals the full chain:

If the root certificate is missing or incorrect
If the device does not trust the AD CS root certificate, browsers will display an error like the example below:

Testing with Web Content Filtering

When combined with Web Content Filtering, behavior changes in a noticeable way.

Without TLS Inspection

Example: https://www.amazon.co.jp
A timeout‑like error appears, with no explanation:

With TLS Inspection enabled

Now, the block page is shown with a clear explanation:

References

The following resources were used during the preparation of this guide:

TLS Inspection in Microsoft Entra GSA Internet Access – Complete Configuration Guide
https://www.thetechtrails.com/2025/09/entra-gsa-tls-inspection-guide.html

YouTube: TLS Inspection in Microsoft Entra Internet Access – Deep Dive
https://www.youtube.com/watch?v=WxxHH_4vKh4

Summary

This article has walked through a complete, end‑to‑end configuration of TLS Inspection in Microsoft Entra Global Secure Access (GSA)—from prerequisites, certificate creation, signing, and deployment, to policy configuration, profile assignment, and verification.

TLS Inspection is foundational for enabling advanced security capabilities, including:

Accurate web content categorization
Enhanced threat intelligence
File‑based inspection
AI prompt protection (Prompt Shield)

Although certificate handling—especially the creation of an intermediate CA and conversion to PEM—can be complex, following these steps enables a reproducible and reliable deployment.

Remember:

A TLS Inspection Policy must be assigned to a Security Profile before it becomes active.
Certificate chain validation is the most reliable way to confirm correct operation.

We hope this guide supports your deployment and testing efforts in GSA environments.
Feel free to extend it with exception rules, AD CS best practices, or Intune‑based certificate distribution models as needed.