SSL Decryption Breaking Applications — 'Outlook Stopped After Security Changes'

The Call Comes In

"After the security team enabled SSL inspection, Outlook stopped syncing"
"Teams video works but chat messages are not sending"
"Banking portal shows certificate error from inside but not outside"
"Some websites partially load — images are missing, login fails"
"Mobile MDM enrollment broke after the firewall change"
"Certificate warnings appearing for sites that had no warning yesterday"
"One application shows login loop — user logs in, redirected back to login"

Why This Is the Most Feared Enterprise Rollout

A single SSL decryption policy can break hundreds of applications simultaneously. The applications that break are often the most critical ones — email, video conferencing, ERP access, banking — because those are precisely the high-value applications that modern security teams want to inspect. Rolling back SSL decryption is politically difficult once the CISO has signed off. So TAC must fix specific applications without removing the policy entirely.

How SSL Decryption Works — The Foundation for Debugging

When SSL decryption is enabled, the firewall acts as a man-in-the-middle for TLS sessions. For outbound HTTPS:

Step	What Happens
1	Client initiates TLS handshake to server (e.g., outlook.office365.com)
2	Firewall intercepts the handshake and presents ITS OWN certificate to the client (signed by the Forward Trust CA)
3	Client validates the firewall's certificate against its trusted CA store
4	Simultaneously, the firewall establishes a separate TLS session with the real server
5	The firewall decrypts inbound traffic, inspects it, re-encrypts with the original certificate for the client

For this to work: the client must trust the Forward Trust CA installed on the firewall. If it does not, the client sees an untrusted certificate warning. If the application uses certificate pinning, it ignores the OS trust store and rejects any certificate that is not the exact expected certificate — making decryption impossible for that application.

What Most Engineers Try First (And Why It Fails)

Bypass the firewall entirely to test — confirms firewall is the cause but gives no specifics
Disable antivirus profile on the decryption policy — AV is not the cause, TLS interception is
Reinstall the application — application is fine, the certificate it receives is wrong
Trust the firewall CA on one test machine — may fix that machine but does not deploy widely, and does not fix certificate pinning
Disable decryption policy completely — fixes everything but removes all visibility, defeats the purpose

The Five Root Causes and Their Signatures

Root Cause	Symptom	Distinctive Signal
Certificate Pinning	App fails completely, no certificate warning shown	App uses hardcoded expected cert — any substitution breaks it
Client Does Not Trust Forward Trust CA	Certificate warning dialog shown to user	Browser shows 'Certificate issued by unknown authority'
Missing Intermediate Certificate	Some apps fail, others work	Certificate chain incomplete — leaf cert cannot be validated
Unsupported TLS Version or Cipher	TLS handshake fails, no data exchange	Decryption log shows 'unsupported version' or 'handshake error'
Mutual TLS (mTLS) Traffic	Application sends client certificate, firewall cannot relay it	Application requires presenting its own certificate to server

The Actual TAC Debug Sequence

Step 1 — Check Decryption Logs First

pan-os-cli

# Check decryption logs for the affected destination
show log decryption direction equal forward   | match "<destination-domain-or-ip>"

# Key fields to examine:
# error: the specific failure reason
# common fields and their meanings:
# "decryption: error" = TLS handshake failed during firewall interception
# "client-to-firewall: unsupported version" = client TLS version not supported by firewall
# "firewall-to-server: handshake failure" = server rejected firewall's TLS negotiation
# "certificate-verify-fail" = forward trust CA validation issue

# Also check traffic logs to see if traffic is being decrypted or bypassed
show log traffic   | match "<destination>"
# Look for "flags" field — "0x400000" indicates decrypted traffic

Step 2 — Identify Certificate Pinning

pan-os-cli

# Certificate pinning cannot be fixed by configuration — only by exclusion.
# These applications are known to use certificate pinning:
# - Microsoft Teams (partial — some components pin)
# - Apple Push Notification Service
# - Mobile banking applications
# - Zoom (some versions)
# - MDM enrollment services (Intune, JAMF)
# - Most financial trading platforms

# Confirm pinning: check if application works when decryption is excluded
# Add the destination to the SSL exclude list temporarily
# If application immediately starts working — pinning confirmed

# Check decryption exclusion list
show running decryption-policy

# Test whether a specific URL should be excluded
test decryption-policy-match from trust to untrust   source <client-ip>   destination <server-ip>   destination-port 443

Step 3 — Validate Certificate Trust Chain

pan-os-cli

# Check what CA certificates are in the firewall's trust store
show config running | match "certificate"

# Check the Forward Trust CA certificate configuration
show running ssl-decrypt

# Verify the Forward Trust CA certificate is:
# 1. Marked as a CA certificate (can sign other certificates)
# 2. Has not expired
# 3. Has been exported and deployed to all client machines/browsers

# Check certificate details
show certificate <forward-trust-ca-name>

# Common issue: CA cert deployed to Windows but not to Mac, mobile, or specific browsers
# Firefox uses its own trust store independent of the OS — must be deployed separately

Step 4 — TLS Version and Cipher Mismatch

pan-os-cli

# Check which TLS versions the firewall supports for decryption
show config running | match "tls|ssl-protocol"

# If an application requires TLS 1.3 but the decryption policy is set to 1.2 max:
# The firewall will downgrade the session, which modern applications reject

# Common cipher mismatch scenario:
# Server requires ECDHE + AES-256-GCM
# Firewall decryption profile is configured for a subset that excludes this cipher
# Result: TLS handshake fails at the cipher negotiation stage

# Check configured SSL/TLS profiles
show config running | match "ssl-exclude|min-version|max-version"

TLS 1.3 and Decryption

TLS 1.3 is significantly harder to decrypt than TLS 1.2. It removed support for RSA key exchange (which made passive decryption possible) and made forward secrecy mandatory. Many organizations have TLS 1.3 decryption gaps — sessions using TLS 1.3 bypass decryption silently unless the firewall is explicitly configured to handle it. If your decryption policy is not working for newer applications, check whether the destination is using TLS 1.3.

Step 5 — Mutual TLS (mTLS) Detection

Applications that use mutual TLS require the client to present a certificate to the server during the handshake. When the firewall intercepts this session, it acts as the client to the server — but it does not have the client's private key and certificate. The server requests a certificate, the firewall cannot provide one, and the handshake fails.

pan-os-cli

# mTLS traffic will show in decryption logs with:
# "server-certificate-request" in the handshake logs
# OR the application will fail immediately at connection — never gets past TLS

# Common mTLS applications:
# - IoT device communication
# - Internal microservice APIs
# - Some VPN clients
# - Enterprise MDM enrollment
# - Some financial API integrations

# These must be excluded from decryption — there is no configuration fix
# Add the destination host/IP to the SSL Exclude list

Building the SSL Exclude List — The Practical Fix

Not all traffic should be decrypted. The SSL exclude list tells the firewall to let specific traffic pass through without decryption. This is not a security failure — it is correct policy for traffic that cannot or should not be inspected.

Traffic That Must Always Be Excluded

Certificate pinned applications — they will always fail under decryption
Mutual TLS (mTLS) traffic — firewall cannot present client certificates it does not own
Financial applications and banking — regulatory requirements may prohibit interception
Healthcare applications — HIPAA considerations around data in transit
Personal/private traffic on employee devices (if policy does not permit inspection)
Software update services — antivirus updates, OS updates; inspecting these can break the update process

Building and Validating the Exclude List

pan-os-cli

# After adding to exclude list, validate:
test decryption-policy-match from trust to untrust   source <client-ip>   destination <excluded-server-ip>   destination-port 443

# Result should show: action = no-decrypt

# Confirm in traffic logs after user retests:
show log traffic destination equal <server-ip>
# Flags field should NOT show decrypted indicator

# Standard exclusions for Microsoft 365 (common production requirement):
# *.microsoft.com, *.office365.com, *.office.com
# *.live.com, *.microsoftonline.com
# These cover Teams, Outlook, SharePoint, OneDrive

# For Zoom:
# *.zoom.us, *.zoomgov.com, *.zoom.com

Pre-Rollout Validation — How to Avoid This Outage

SSL decryption rollouts should never go directly to all users. This sequence prevents the 2am emergency call:

Stage 1: Enable decryption for a pilot group of 10-20 technical users who can report issues clearly
Stage 2: Run for one week — monitor decryption logs daily for errors and new exclusion candidates
Stage 3: Test every critical business application explicitly from the pilot group machines
Stage 4: Build the exclude list from pilot findings before expanding
Stage 5: Deploy Forward Trust CA to ALL devices and browsers before expanding beyond pilot
Stage 6: Expand by department, not all at once — enables faster isolation if something breaks
Stage 7: Monitor decryption error rates for 48 hours after each expansion

The Certificate Deployment Gap

The most common rollout failure is deploying the Forward Trust CA certificate only to Windows via Group Policy, while Mac, Linux, iOS, and Android devices are not covered. Those devices immediately show certificate errors for all decrypted traffic. Firefox on any platform uses its own trust store and requires a separate deployment even on properly configured Windows machines. Map your device inventory before rollout and confirm CA deployment coverage for every platform.

Previous Module Next Module