🎯 TL;DR - Key Takeaways
- Hardware: PA-7080 recommended for 50Gbps with full threat prevention (305 Gbps throughput)
- Certificate trust is critical: Deploy CA cert via GPO 2+ weeks before enabling decryption
- Exclude healthcare & financial: HIPAA/PCI compliance + certificate pinning issues
- TLS 1.3 impacts performance: 15-20% higher CPU vs TLS 1.2 due to PFS requirements
- Session reuse is key: Enable SSL session cache to reduce handshake overhead by 60%
- Plan for certificate pinning failures: Expect 5-10% of apps to break, need exclusion process
🧮 Interactive Hardware Sizing Calculator
Input your throughput requirements to get hardware recommendations. This calculator uses Palo Alto's published performance specs for PAN-OS 11.1.
Your Requirements
📊 Hardware Recommendations
PA-5450
PA-7080
🎯 Why 50Gbps is the Enterprise Threshold
50Gbps of SSL-inspected traffic represents the tipping point where hardware selection and architecture design become critical. Below 50Gbps, mid-tier firewalls can handle the load. Above it, you need datacenter-class hardware or risk performance degradation.
What Does 50Gbps Actually Look Like?
- 5,000-10,000 concurrent users in a large enterprise
- 500K-1M concurrent SSL sessions at peak
- 25K-50K new SSL handshakes per second
- 80-90% of web traffic is now HTTPS
- Multiple datacenters with geo-distributed firewalls
💻 Hardware Selection Deep Dive
Choosing the right hardware is the foundation of a successful SSL decryption deployment. Undersizing leads to packet loss and user complaints. Oversizing wastes hundreds of thousands of dollars.
PA-5450 vs PA-7080: The Critical Decision
| Specification | PA-5450 | PA-7080 | Notes |
|---|---|---|---|
| Firewall Throughput | 200 Gbps | 590 Gbps | L4 stateful inspection without security |
| Threat Prevention | 189 Gbps | 305 Gbps | IPS enabled (most common use case) |
| IPsec VPN | 85 Gbps | 310 Gbps | Proxy for SSL decryption capacity |
| Max Sessions | 30M | 160M | Concurrent connections |
| New Sessions/Sec | 1.5M | 4M | Critical for bursty traffic |
| Form Factor | 2U rackmount | Chassis (21 slots) | PA-7080 requires more rack space |
| Redundancy | Fixed config | Redundant power/DPCs | PA-7080 more resilient to HW failures |
| Price (List) | ~$185K | ~$425K | With cards populated, before discounts |
🔧 Our Decision: PA-7080
Why We Chose PA-7080 for 50Gbps
While the PA-5450 technically supports 85 Gbps of IPsec VPN (a rough proxy for SSL decryption capacity), we needed headroom for:
- Growth: Traffic increases 20-30% year-over-year
- Traffic spikes: Black Friday, product launches, DDoS events
- TLS 1.3 adoption: Higher CPU usage than TLS 1.2
- Full security stack: IPS + AV + URL filtering + WildFire
The Math
PA-5450 Analysis:
- 189 Gbps threat prevention throughput (baseline)
- 50 Gbps target × 80% SSL = 40 Gbps SSL traffic
- SSL decryption overhead: ~3x CPU usage
- Effective capacity: 189 ÷ 3 ≈ 63 Gbps SSL-decrypted throughput
- Verdict: Marginal headroom (26% spare capacity)
PA-7080 Analysis:
- 305 Gbps threat prevention throughput (baseline)
- 50 Gbps target × 80% SSL = 40 Gbps SSL traffic
- SSL decryption overhead: ~3x CPU usage
- Effective capacity: 305 ÷ 3 ≈ 102 Gbps SSL-decrypted throughput
- Verdict: Excellent headroom (100%+ spare capacity)
🏗️ Alternative Architectures
Option 1: Multiple PA-5450s in Parallel
Design: Load balance traffic across 2-3 PA-5450s using upstream router ECMP or external load balancer
Pros: Lower per-unit cost, horizontal scalability, failure domain isolation
Cons: Complex session state sync, asymmetric routing challenges, operational overhead
Cost: 3x PA-5450 HA pairs = $1.1M (vs $850K for PA-7080 pair)
Option 2: SSL Offload Appliance + PA-5450
Design: Use F5 SSL Orchestrator or Citrix ADC to decrypt traffic, forward plaintext to PA-5450
Pros: Specialized SSL acceleration hardware, firewall can focus on security
Cons: Additional hop adds latency (3-5ms), another device to manage, licensing costs
Cost: F5 SSL Orchestrator (~$200K) + PA-5450 ($185K) = $385K per site
Option 3: Prisma Access Cloud
Design: Offload SSL decryption to Palo Alto's cloud service
Pros: No hardware CAPEX, cloud-scale capacity, automatic updates
Cons: Egress bandwidth costs, latency for on-prem apps, data sovereignty concerns
Cost: ~$120-180/user/year for 5K users = $600-900K/year OPEX
🔐 Certificate Management Strategy
SSL decryption requires the firewall to act as a man-in-the-middle, re-signing certificates for all HTTPS traffic. If clients don't trust your CA certificate, they see scary browser warnings for EVERY website.
Certificate Deployment Timeline
Week 1-2: Generate CA Certificate
Create dedicated CA certificate for SSL decryption (don't reuse existing CA)
Week 3-4: Distribute CA Cert via GPO
Deploy to Trusted Root CA store on all Windows/Mac/Linux endpoints
- Export certificate from Palo Alto (Device > Certificate Management > Export)
- Windows: GPO → Computer Config → Policies → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities
- macOS: Jamf/Intune profile with CA cert
- Linux: Copy cert to /usr/local/share/ca-certificates/ and run update-ca-certificates
Week 5-6: Pilot SSL Decryption
Enable decryption for 5-10% of users (IT department first)
- Monitor for certificate errors (check browser developer tools)
- Validate that apps aren't breaking (especially mobile apps with pinning)
- Gather feedback on any performance issues
Week 7-8: Production Rollout
Gradually expand decryption to all users (25% → 50% → 100%)
- Enable decryption policy for production user groups
- Monitor firewall CPU, session count, latency
- Respond quickly to certificate pinning failures with exclusions
📱 Mobile Device Considerations
iOS Devices
Challenge: iOS doesn't trust user-installed CA certificates for apps (only for Safari)
Solution: Deploy via MDM profile (Jamf, Intune, etc.) with full device trust
Android Devices
Challenge: Android 7+ requires apps to explicitly trust user CAs
Solution: Deploy as system CA via MDM (requires device admin) OR exclude corporate Android devices from SSL decryption
BYOD Devices
Recommendation: Do NOT decrypt BYOD traffic. Privacy concerns, inability to deploy CA cert reliably, high support overhead.
📋 Decryption Policy Design
Your decryption policy determines what traffic gets decrypted and what bypasses inspection. Getting this right is critical for security, compliance, and user experience.
The Three-Tier Policy Framework
🚫 Tier 1: Never Decrypt (Compliance & Privacy)
Categories to Always Exclude
| Category | Reason | Example Sites |
|---|---|---|
| financial-services | PCI-DSS compliance, certificate pinning | *.chase.com, *.bankofamerica.com, *.wellsfargo.com |
| health-and-medicine | HIPAA compliance, PHI privacy | *.clevelandclinic.org, *.mayoclinic.org, *.healthcare.gov |
| government | Security requirements, cert pinning | *.gov, *.mil, *.irs.gov |
| personal-sites-and-blogs | User privacy, limited security value | Personal email, social media DMs |
Configuration Example
⚠️ Tier 2: Technical Exclusions (Certificate Pinning)
Common Certificate Pinning Apps/Services
These applications validate the certificate against a hardcoded public key hash and will break if you decrypt:
| Application | Domains to Exclude | Symptom if Decrypted |
|---|---|---|
| Apple Services | *.apple.com, *.icloud.com, *.mzstatic.com | iMessage fails, App Store won't load, iCloud sync stops |
| Google Chrome Updates | *.google.com/chrome, *.gvt1.com | Chrome refuses to update, security alerts |
| Microsoft Office 365 | *.office.com, *.microsoftonline.com, *.sharepoint.com | Can't login to Office apps, OneDrive sync fails |
| Zoom | *.zoom.us | Can't join meetings, connection errors |
| Dropbox | *.dropbox.com, *.dropboxapi.com | Sync client reports "SSL error" |
Palo Alto's Predefined Exclusion List
Palo Alto maintains a list of known certificate pinning sites that's automatically updated:
Building Your Own Exclusion List
You'll still encounter pinning failures not in Palo Alto's list. Create a process:
- User reports: "App X stopped working after SSL decryption enabled"
- Verify it's pinning: Check firewall logs for "SSL decryption failed" errors
- Identify domains: Look at decryption logs, packet captures
- Add to exclusion: Create custom no-decrypt rule for specific app domains
- Document: Maintain wiki page of excluded apps and business justification
✅ Tier 3: Decrypt Everything Else
Default Decrypt Rule
After exclusions, decrypt all remaining outbound SSL traffic:
Inbound Decryption (Optional)
For inbound traffic to your web servers, use SSL Inbound Inspection:
Complete Policy Order
Rules are evaluated top-to-bottom. More specific rules must come first:
- No-Decrypt-Compliance (financial, healthcare, government)
- No-Decrypt-Pinning (Apple, Microsoft, custom app exclusions)
- No-Decrypt-BYOD (guest WiFi, personal devices)
- Decrypt-Outbound (everything else)
⚡ Performance Optimization
SSL decryption is CPU-intensive. These optimizations reduced our CPU utilization by 35% without compromising security.
🔄 Enable SSL Session Reuse
The Problem
Each new SSL handshake requires expensive cryptographic operations (RSA/ECDHE key exchange, certificate validation). For a user visiting CNN.com, their browser makes 50+ HTTPS connections (ads, analytics, images) - that's 50 full handshakes.
The Solution: SSL Session Caching
Enable SSL session resumption so clients can reuse session keys:
Impact
- ✅ Handshake CPU usage reduced by 60%
- ✅ SSL handshake latency: 100ms → 5ms for cached sessions
- ✅ Supported 40% more sessions on same hardware
🔐 Optimize Cipher Suite Selection
TLS 1.2 vs TLS 1.3 Performance
| Protocol Version | CPU Usage | Handshake RTTs | PFS Default |
|---|---|---|---|
| TLS 1.2 (RSA) | Baseline (1x) | 2-RTT | No (optional) |
| TLS 1.2 (ECDHE) | +15-20% | 2-RTT | Yes |
| TLS 1.3 | +20-25% | 1-RTT | Yes (mandatory) |
Recommended Cipher Suite
📊 Monitoring & Alerting
Key Metrics to Monitor
| Metric | Warning Threshold | Critical Threshold | Action |
|---|---|---|---|
| Data Plane CPU | >70% | >85% | Add exclusions or upgrade hardware |
| SSL Proxy Utilization | >60% | >80% | Check session cache settings |
| Packet Buffer Utilization | >70% | >90% | Packet drops imminent - urgent action |
| Session Utilization | >75% | >90% | Check for session leaks or attacks |
CLI Commands for Monitoring
⚠️ Common Gotchas & How We Solved Them
These are the painful lessons we learned during our deployment. Save yourself the trouble.
🔴 Gotcha #1: Mobile App Apocalypse
What Happened
Day 1 of SSL decryption rollout, we got flooded with tickets: "Outlook mobile won't sync email," "Teams mobile won't connect," "Banking apps showing security errors."
Root Cause
Mobile apps use certificate pinning 10x more than desktop apps. iOS/Android apps bundle the expected certificate and reject our firewall-signed cert.
Solution
Created expedited process for mobile app exclusions:
- User reports app name + error screenshot
- Security team tests app, confirms pinning (not malware)
- Network team identifies domains via packet capture
- Add no-decrypt rule within 1 hour
- Update KB article with excluded apps
🔴 Gotcha #2: Crypto Currency Wallets Blocked
What Happened
Executive VP couldn't access his crypto exchange account. Escalated to CTO within 30 minutes.
Root Cause
Cryptocurrency exchanges (Coinbase, Kraken, Binance) use aggressive certificate pinning to prevent MITM attacks. Makes sense given the financial stakes, but broke our decryption.
Solution
Pre-emptively excluded all major crypto exchanges before general rollout:
🔴 Gotcha #3: Cloud SaaS Performance Degradation
What Happened
Salesforce, Workday, and other cloud apps became noticeably slower (5-10 second delays on page loads).
Root Cause
Cloud SaaS apps make 100+ parallel HTTPS connections per page. Each connection hit the firewall for full SSL handshake (before we enabled session caching). Added 50-100ms latency per request.
Solution
- Enabled SSL session caching (see performance section)
- Increased cache size from default 10K to 25K sessions
- Validated HTTP/2 was working (reduces connection count)
Results
- Salesforce page load: 8s → 2s (75% faster)
- Workday: 6s → 1.5s (75% faster)
- User satisfaction scores recovered to pre-decryption levels
🔴 Gotcha #4: TLS 1.3 0-RTT Breaks Decryption
What Happened
Some sites (Google, Cloudflare CDN) showed intermittent SSL errors for repeat visitors.
Root Cause
TLS 1.3 "0-RTT" (Zero Round Trip Time) resumption sends encrypted data in the FIRST packet. Firewall can't decrypt traffic it hasn't seen the handshake for, causing connection failures.
Solution
📅 Our 8-Week Implementation Timeline
Here's the actual timeline from our deployment. Adjust based on your org size, but don't skip phases.
Phase 1: Planning & Hardware (Weeks 1-2)
- ☐ Calculate throughput requirements (current + 30% growth)
- ☐ Select hardware (PA-5450 vs PA-7080 analysis)
- ☐ Order firewalls (8-12 week lead time - start early!)
- ☐ Get budget approval ($850K for PA-7080 HA pair)
- ☐ Engage legal/compliance team (HIPAA, PCI, GDPR review)
- ☐ Document business case and risk assessment
Phase 2: Hardware Setup & CA Deployment (Weeks 3-4)
- ☐ Rack and cable firewalls
- ☐ Configure HA pair (A/P mode)
- ☐ Generate SSL decryption CA certificate (4096-bit)
- ☐ Export CA cert and create GPO
- ☐ Deploy CA to all Windows/Mac/Linux endpoints via GPO/MDM
- ☐ Verify CA deployment (spot-check 50+ machines)
- ☐ Configure base security policies (no decryption yet)
Phase 3: Policy Development (Weeks 5-6)
- ☐ Create no-decrypt rules (financial, healthcare, government)
- ☐ Enable predefined SSL decryption exclusion list
- ☐ Build custom exclusion list (Apple, Microsoft, mobile apps)
- ☐ Create decrypt-outbound rule (disabled for now)
- ☐ Configure SSL forward proxy profile
- ☐ Enable SSL session caching (25K sessions, 1hr timeout)
- ☐ Set up monitoring & alerting (CPU, sessions, packet buffer)
Phase 4: Pilot Deployment (Week 7)
- ☐ Enable decryption for IT department only (50 users)
- ☐ Monitor firewall CPU, memory, sessions for 48 hours
- ☐ Collect user feedback (anonymous survey)
- ☐ Test common apps: Office 365, Salesforce, Zoom, Slack
- ☐ Identify and document any cert pinning failures
- ☐ Add exclusions as needed
- ☐ Verify threat prevention still working (test malware samples)
Phase 5: Production Rollout (Week 8)
- ☐ Week 8 Day 1: Enable for 25% of users (random selection)
- ☐ Week 8 Day 3: Expand to 50% if no major issues
- ☐ Week 8 Day 5: Expand to 100% of users
- ☐ Monitor help desk ticket volume closely
- ☐ Have rollback plan ready (disable decryption rule)
- ☐ Document all exclusions added during rollout
- ☐ Schedule monthly review of decryption policy
✅ Pre-Flight Checklist
Do NOT enable SSL decryption until you can check all these boxes:
🚨 Critical Requirements (Must-Have)
- ☐ CA certificate deployed to ALL managed endpoints (95%+ coverage)
- ☐ Waited 2+ weeks after CA deployment for offline devices to update
- ☐ Legal/compliance approval for decryption policy
- ☐ Healthcare & financial traffic excluded (HIPAA/PCI compliance)
- ☐ Predefined SSL decryption exclusion list enabled
- ☐ Pilot tested with 50+ users for 1+ week without major issues
- ☐ Rollback plan documented and tested
- ☐ Help desk trained on common SSL decryption issues
⚠️ Recommended (Should-Have)
- ☐ SSL session caching enabled (25K+ sessions)
- ☐ Monitoring & alerting configured (CPU, sessions, packet buffer)
- ☐ Custom exclusions for known cert pinning apps (Apple, Microsoft, Zoom)
- ☐ TLS 1.3 0-RTT disabled to prevent intermittent failures
- ☐ Mobile app exclusion process documented
- ☐ Performance baseline captured (pre-decryption latency, throughput)
- ☐ Executive/VIP users identified for targeted support
- ☐ KB article published with FAQs for users
💬 Questions or Share Your Experience?
This guide is community-maintained. If you've deployed SSL decryption at scale, have additional gotchas to share, or want to discuss your Palo Alto deployment: