TLS inspection in Microsoft Global Secure Access (GSA) looks deceptively simple in Microsoft’s documentation.
In reality, this is one of those features where certificate minutiae actually matter. A single inherited EKU or an over-permissive template setting is enough to cause silent breakage that’s painful to debug.
This guide documents the exact process that works when enabling TLS inspection using an internal PKI.
Step 1 — Generate the Subordinate CA CSR in Entra #
Because Global Secure Access must hold the private key used for TLS inspection, the SubCA must be generated in Entra. You do not generate this keypair on your internal CA.
Generate the CSR #
- Open the Entra admin center
- Navigate to
Global Secure Access → Secure Web Gateway → TLS inspection - Start the TLS inspection certificate setup
- When prompted, select Generate CSR
CSR Configuration #
Configure the CSR with the following values:
- Certificate type: Subordinate CA
- Key type: RSA
- Key size: 2048 or 4096
- Subject name: match your intended SubCA
Example subject:
CN=GSA-TLS-Inspection-SubCA
The private key is generated and retained by Entra. You will never see it — and that’s expected.
Export the CSR #
- Download the generated CSR file (
.csr)
This file is what your internal PKI will sign in the next steps.
Step 2 — Create the Correct Certificate Template #
This is the step most deployments get wrong.
A TLS inspection issuing CA must not contain any EKU. If it does, inspection will fail in subtle and inconsistent ways.
Open Certificate Templates #
On your Enterprise CA:
certtmpl.msc
Duplicate an existing Subordinate CA template and modify it.
Extensions → Basic Constraints #
- CA: TRUE
- Mark as critical: Enabled
- Path length: Optional (0 recommended)
Extensions → Key Usage #
Enable only:
- Certificate signing
- CRL signing
- Digital signature
Disable:
- Nonrepudiation
- Key encipherment
- Data encipherment
- Key agreement
Extensions → Application Policies (Extended Key Usage) #
- Remove all entries
- Leave the list completely empty
This is non-negotiable.
A TLS inspection CA must not advertise an EKU.
Publish the template on the Certification Authority once saved.
Step 3 — Issue a New Subordinate CA Certificate #
If you previously issued a SubCA using the wrong template, you cannot fix it.
You must issue a brand-new certificate using the corrected template.
Enroll the Certificate #
- Open Certificates (Local Computer)
- Navigate to Personal → Certificates
- Right-click → All Tasks → Request New Certificate
- Select Active Directory Enrollment Policy
- Choose the updated Subordinate CA template
- Complete the enrollment
This issues a new SubCA certificate without EKU, signed by your internal PKI.
Step 4 — Export the SubCA Certificate #
From the same system:
- Locate the new SubCA certificate under Personal → Certificates
- Right-click → All Tasks → Export
- Select No, do not export the private key
- Choose Base-64 encoded X.509 (.CER)
Save this file — it will be uploaded to Entra.
Step 5 — Validate the Certificate Before Upload #
Do not skip validation.
This is where you catch mistakes before they turn into outages.
Run the following commands:
openssl x509 -in SubCA_NEW.cer -noout -text | grep -i "Basic Constraints" -A2
openssl x509 -in SubCA_NEW.cer -noout -text | grep -i "Key Usage" -A2
openssl x509 -in SubCA_NEW.cer -noout -text | grep -i "Extended Key Usage" -A2
Confirm the following:
- Basic Constraints:
CA:TRUE - Key Usage: certificate signing, CRL signing, digital signature
- Extended Key Usage: ABSENT
If EKU appears at all, stop — the template is wrong.
Step 6 — Upload the Certificate to Entra #
- Return to
Global Secure Access → Secure Web Gateway → TLS inspection - Select Upload certificate
- Upload the new SubCA .CER file
- Upload the issuing CA or chain if prompted
- Complete the upload and wait for processing
The certificate will appear in the TLS inspection certificate list.
Step 7 — Enable TLS Inspection (Briefly) #
- Newly uploaded certificates are disabled by default
- Enable the new certificate once it shows as healthy
- Only one TLS inspection certificate can be active at a time
TLS inspection policies are applied by the Secure Web Gateway based on your domain targeting rules. Keep these surgical, not ideological.
Step 8 — Trust Distribution (Critical) #
TLS inspection will break everything if endpoints do not trust the chain.
Ensure the following are deployed to all client devices:
- Internal Root CA
- Any intermediate CA that issued the SubCA
These must be installed in Trusted Root Certification Authorities.
Common Troubleshooting & Gotchas #
Certificate uploads but traffic fails #
Almost always caused by EKU leakage in the template.
Browsers show HTTPS warnings #
Client devices do not trust the issuing CA chain.
Some apps break, others work #
Likely certificate pinning or unsupported TLS interception — exclude those domains.
“Why not decrypt everything?” #
Because TLS inspection fails socially before it fails technically.
Final Thoughts #
TLS inspection in Global Secure Access is powerful — but only when treated as a precision control, not a blanket one.
Get the PKI right and scope inspection narrowly, and it works quietly and predictably.
Rush it, and you’ll spend weeks chasing outages caused by a single checkbox you didn’t notice.