Problems addressed
HTTPS hides URLs, payloads, and uploads from a proxy that only sees tunnel metadata. Malware delivery, phishing pages, and data exfiltration over TLS evade policy without deliberate inspection and trust deployment.Outcomes operators expect
- Policy on full HTTPS URLs and content where inspection runs.
- Malware and DLP controls on encrypted flows when licensed and configured.
- Selective bypass for pinned apps, regulated sites, and privacy policy carve-outs.
Technical scope
SafeSquid’s documented TLS support covers TLS 1.0 through TLS 1.3. This matters because modern threats overwhelmingly use encrypted web sessions, and a proxy that cannot inspect current TLS traffic leaves the main enterprise web path opaque.Advantages vs “TLS blind proxying”
Inspection restores Layer 7 visibility on the proxy path at the cost of client trust in the SafeSquid root CA and operational work for bypass rules. Comparative performance or legal suitability vs other vendors: Not SSOT-backed here—see What is SafeSquid SWG?.Acquire, deploy, use
Follow Configure HTTPS Inspection: Root CA, enable inspection, deploy trust to clients, define bypasses, verify. HTTPS inspection (SSL/TLS interception) allows SafeSquid to decrypt, inspect, and re-encrypt HTTPS traffic. Without inspection, encrypted sessions remain a blind spot for content-level malware, phishing, and data-leakage policy.When to Use SSL Inspection
:::tip
Selective inspection
Bypass policies can exclude sensitive categories while inspection remains enabled for the rest of traffic.
:::
Why HTTPS Inspection Matters
The problem- Draft: Most enterprise web traffic is HTTPS; measure with local metrics if a percentage is required for a board narrative.
- Encrypted traffic hides malicious payloads, phishing attempts, and data exfiltration from content-aware policy.
- Without inspection, the proxy sees tunnel metadata (for example SNI), not full URLs or bodies.
- URL filtering on HTTPS sites
- Malware scanning of encrypted downloads
- Data Loss Prevention (DLP) on HTTPS uploads
- Application control (detect Google Drive, Dropbox, etc. in HTTPS traffic)
- Content security (block ransomware downloads, malicious scripts)
- real-time SSL certificate validation against remote servers
- automatic certificate-chain repair through AIA fetching for broken chains
- continuous updates to the trusted root CA list
How It Works
- Client → SafeSquid: Browser connects to SafeSquid using SafeSquid’s certificate
- SafeSquid → Origin: SafeSquid creates a separate TLS connection to the destination
- Inspection: SafeSquid sees the decrypted content and applies policies
- Re-encryption: SafeSquid re-encrypts and forwards to the destination
Important considerations
Bypass is Required For:
- SSL-pinned applications (mobile apps, some desktop software)
- Banking and financial sites (compliance/privacy)
- Healthcare portals (HIPAA compliance)
- Government sites (security requirements)
Client Trust Required:
All client browsers and applications must trust the SafeSquid Root CA certificate. Without trust, users see certificate warnings on every HTTPS site. Deploy the Root CA to:- Windows certificate store (for Chrome, Edge, IE)
- Firefox certificate store (separate)
- macOS Keychain (for Safari, system-wide)
- Mobile devices (via MDM)
Production safety
- Do not enable broad inspection in production before planning certificate deployment and bypass scope.
- Test certificate-pinned applications, regulated destinations, and business-critical SaaS before rollout.
- If inspection is introduced without a pilot, certificate warnings and application failures can create a self-inflicted outage.
Configuration Guides
Configure HTTPS Inspection
Complete setup guide covering:- Generate or import Root CA certificate (Self-Service Portal)
- Enable HTTPS inspection in SafeSquid
- Configure bypass policies for sensitive domains
- Deploy Root CA to clients (Windows, macOS, Firefox, mobile)
- Verify inspection is working
Import Certificate into Chrome/IE
Step-by-step walkthrough for importing the SafeSquid Root CA into the Windows Trusted Root Certification Authorities store (used by Chrome, Edge, and Internet Explorer). Use this after enabling HTTPS inspection to eliminate browser certificate warnings on Windows clients.Quick Start Checklist
- ✅ Generate Root CA in Self-Service Portal
- ✅ Enable HTTPS Inspection in SafeSquid Configuration Portal
- ✅ Configure bypass policies for banking/healthcare sites
- ✅ Deploy Root CA to all clients:
- Windows (Chrome/IE)
- Firefox
- macOS via MDM or Keychain
- Mobile via MDM
- ✅ Verify inspection is working (check padlock icon, test bypass)
Verification and validation
After enabling SSL inspection, confirm all of the following:- the client trusts the SafeSquid Root CA
- inspected sites show the expected SafeSquid-issued certificate path
- bypassed destinations remain uninspected
- blocked or scanned HTTPS transactions now trigger the intended policy outcomes
- logs show SSL-related decisions such as validation or decryption behavior where expected
- Positive test: browse to a site that should be inspected and confirm content-aware policy can now see it
- Negative test: browse to a bypassed site and confirm the original site certificate remains intact
Troubleshooting
Symptom: Users see certificate warnings on normal HTTPS sites.Likely cause: The SafeSquid Root CA is not trusted on the client.
Isolation: Inspect the presented certificate chain and confirm whether the SafeSquid CA is installed.
Remediation: Deploy the CA correctly to the client trust store.
Retest: Reload the same inspected site and confirm the warning disappears. Symptom: A business-critical app breaks only when inspection is enabled.
Likely cause: Certificate pinning, protocol sensitivity, or an application-specific trust expectation.
Isolation: Compare behavior with a narrow bypass for the application domain.
Remediation: Keep a tightly scoped bypass if inspection is not technically viable for that app.
Retest: Confirm the application works and that unrelated traffic is still inspected. Symptom: HTTPS traffic passes, but content-aware controls still do not trigger.
Likely cause: Inspection is not actually active on that flow, or the destination is still bypassed.
Isolation: Check the active SSL policy path, the certificate behavior, and the matching bypass rules.
Remediation: Correct the inspection scope.
Retest: Repeat the same policy-triggering transaction and confirm the control fires.
Common Questions
Q: Will users see certificate warnings?A: Yes, until you deploy the SafeSquid Root CA to their devices. Once trusted, no warnings appear. Q: Can I inspect only some sites and not others?
A: Yes, use bypass policies to exclude specific domains (e.g., banking sites). Q: What about mobile apps that use certificate pinning?
A: Add those apps’ domains to the bypass list. They cannot be inspected. Q: Does this slow down HTTPS traffic?
A (Draft — pending engineering SSOT): Inspection adds CPU-bound TLS work. Deployment Planning covers AES-NI and sizing. Do not treat fixed millisecond figures as verified product facts until CTO publishes benchmarks in-docs.
Source register
Next Steps
- Configure HTTPS Inspection — Complete setup guide
- Authentication — Enable user-aware policies after SSL Inspection
- Access Restriction — Configure URL filtering (now works on HTTPS)
- Data Leakage Prevention — Scan HTTPS uploads for sensitive data