TLS Inspection: The Step Everyone Gets Wrong
TLS inspection is the most common cause of SASE deployment rollbacks. Here is how to get it right the first time.
TLS inspection — also called SSL decryption or break-and-inspect — is the step where your SASE platform terminates the encrypted TLS session from the user, inspects the decrypted content against your SWG, CASB, and DLP policies, and then re-encrypts it toward the destination. It is essential for any meaningful web security because over 95% of web traffic is encrypted. Without TLS inspection, your SASE platform is blind to the content of most traffic.
It is also the single most common cause of day-one rollbacks. Here is why, and how to avoid it.
Why TLS inspection breaks things
When the SASE platform intercepts a TLS connection, it presents its own certificate to the user's browser or application. If the endpoint does not trust the SASE platform's root CA certificate, the connection fails with a certificate error. That is the simple case and it is easy to fix — deploy the root CA via Intune or JAMF.
The harder case is certificate pinning. Some applications embed the expected server certificate directly in their code and refuse to accept any substitute — even a legitimately signed one from your SASE platform's CA. When TLS inspection intercepts these connections, the application breaks silently or throws a cryptic error that looks nothing like a certificate problem.
The bypass list you need on day one
The following categories of traffic should bypass TLS inspection from the start. Do not wait to discover these through user complaints — bypass them proactively.
Certificate-pinned applications
- Microsoft Teams and Skype for Business (media streams use certificate pinning)
- Microsoft 365 authentication endpoints (login.microsoftonline.com)
- Apple services (iCloud, App Store, Apple Push Notification Service)
- Google services that use certificate pinning (Google Play, Chrome updates)
- Banking and financial applications (most pin their certificates)
- EDR/XDR agents (CrowdStrike, SentinelOne, Microsoft Defender) — these must reach their cloud without interception
- Certificate revocation endpoints (OCSP responders, CRL distribution points)
Traffic that causes performance problems
- Video conferencing (Zoom, Teams, WebEx) — decryption adds latency to real-time media
- Windows Update and WSUS endpoints — high bandwidth, low risk, no benefit from inspection
- CDN traffic for trusted domains (Akamai, CloudFront) serving known-good software updates
- Streaming media (if your policy allows it) — inspecting Netflix traffic wastes PoP capacity
Traffic with legal or compliance restrictions
- Healthcare portals (HIPAA may restrict interception of patient data in transit depending on your legal counsel's interpretation)
- Banking and personal finance (employee personal banking should not be inspected for privacy reasons)
- Government portals (some .gov domains expect specific certificate chains)
How to build and maintain the bypass list
- Start with the vendor's recommended bypass list — every SASE vendor publishes one and they cover the most common certificate-pinned domains
- Add your industry-specific applications (healthcare, banking, government have unique requirements)
- Deploy TLS inspection in monitor mode to a pilot group of 50–100 users for two weeks
- Review the TLS error logs daily — every certificate error is a candidate for the bypass list
- Ask your helpdesk to tag any ticket mentioning "connection error" or "certificate error" during the pilot
- After two weeks with zero TLS errors in the pilot, expand to the next group
- Continue monitoring TLS errors in production and add to the bypass list as new applications are deployed
The root CA deployment problem
For TLS inspection to work on non-bypassed traffic, every endpoint must trust your SASE platform's root CA certificate. This sounds simple but creates problems in three scenarios.
Unmanaged devices (BYOD)
You cannot push a root CA to devices you do not manage. For BYOD users, you have two options: agentless access via browser isolation (no certificate needed because the browser runs in the cloud) or a captive portal that prompts users to install the certificate manually. Neither is great. Browser isolation adds latency. Manual certificate installation has low compliance rates. This is why most organizations use a lighter inspection policy for BYOD — DNS-layer filtering without full TLS inspection.
Non-Windows/macOS endpoints
Linux, ChromeOS, and IoT devices each have their own certificate trust store and deployment mechanism. Linux is particularly painful because there is no unified certificate deployment tool — the process varies by distribution and sometimes by application (Firefox uses its own trust store on Linux, separate from the OS). Budget extra time for non-standard endpoints.
Certificate expiration
The SASE platform's root CA certificate has an expiration date. If it expires before you renew and redeploy it, every user's TLS inspection breaks simultaneously. Set a calendar reminder for 90 days before expiration. Automate the renewal through your endpoint management platform if possible.
Performance considerations
TLS inspection is computationally expensive. The SASE platform must decrypt, inspect, and re-encrypt every connection. Two things affect user-perceived performance:
- PoP proximity: The closer the SASE PoP is to the user, the less latency TLS inspection adds. A user in Tokyo connecting through a PoP in Singapore will notice the overhead. A user in New York connecting through a PoP in New Jersey will not.
- Single-pass architecture: Vendors that inspect traffic once (applying SWG + CASB + DLP policies in a single decryption) add less latency than vendors that decrypt multiple times for different inspection engines. Ask your vendor about their inspection architecture.
Bottom line
TLS inspection is not optional — without it, your SASE platform cannot see the content of 95% of web traffic. But it is the deployment step that requires the most preparation. Build your bypass list before you enable decryption. Deploy the root CA to all managed endpoints before you enable decryption. Run in monitor mode before you enforce. If you do these three things, TLS inspection will work smoothly. If you skip any of them, you will be writing a rollback email within 48 hours.
Sources
- IETF, "The Transport Layer Security (TLS) Protocol Version 1.3" RFC 8446 — rfc-editor.org
- Cloudflare, "What is TLS (Transport Layer Security)?" — cloudflare.com/learning
- NIST, "Guidelines for TLS Implementations" SP 800-52 Rev. 2 (2019) — nist.gov
- Zscaler, "TLS/SSL Inspection" — zscaler.com
- Palo Alto Networks, "SSL Decryption" — paloaltonetworks.com
Related on sase.cloud
One email per publish. Unsubscribe anytime.