Skip to main content

URL Patterns in SSL Exceptions

URL configuration directly impacts security posture in Zscaler ZIA. Poor patterns—often implemented with good intentions under time pressure—accumulate into significant security exposure.

Pattern Categories​

This guide examines:

  • ✅ Secure Patterns - Recommended approaches
  • ⚠️ Caution Patterns - Acceptable with constraints
  • ❌ Anti-Patterns - Insecure or unmaintainable

1. SSL Exception Patterns​

✅ Pattern: Specific FQDN Exceptions​

Use specific fully-qualified domain names only.

Example:

✅ Secure
play.itunes.apple.com
bag.itunes.apple.com
init.itunes.apple.com

Why secure:

  • Minimal security surface area
  • Clear scope and intent
  • Easily auditable

⚠️ Pattern: Subdomain Wildcards​

Wildcard covering all subdomains of a trusted parent domain.

Example: *.company-internal.example.com

⚠️ Acceptable with constraints

Constraints:

  • Parent domain under organizational control
  • All subdomains serve trusted content
  • Regular review of subdomain creation

When acceptable:

  • Organization controls all subdomains
  • Regular audit of active subdomains (quarterly)
  • Documented list of all services

When to avoid:

  • Public SaaS domains (not under your control)
  • CDN domains (anyone can publish)
  • Shared infrastructure domains

❌ Anti-Pattern: CDN Wildcards in SSL Exceptions​

CRITICAL SECURITY ISSUE

CDNs allow anyone to publish content. A wildcard like *.akamaized.net bypasses inspection for:

  • ✅ Legitimate: netflix-content.akamaized.net
  • ❌ MALICIOUS: attacker-payload.akamaized.net ← Also bypassed

Real finding: *.akamaized.net in SSL exceptions handling 2TB/month = millions of potential malicious domains uninspected.

Solution: Replace with specific FQDNs:

  • ✅ netflix-content.akamaized.net
  • ✅ apple-updates.akamaized.net
  • ✅ microsoft-downloads.akamaized.net

Time to fix: 4-5 hours (log analysis → document → test → deploy)

✅ Pattern: Cloud Application-Level Exceptions​

Use Zscaler's Cloud Application exceptions instead of individual URLs.

Example:

Instead of listing individual URLs:

  • ❌ salesforce.com
  • ❌ force.com
  • ❌ salesforceliveagent.com
  • ❌ salesforce-sites.com
  • ❌ ... (20+ Salesforce domains)

Use Cloud Application exception:

  • ✅ "Salesforce" (automatically covers all domains)

Advantages:

  • Vendor-maintained (Zscaler updates domain list)
  • Comprehensive coverage
  • Cleaner policy
  • Future-proof

❌ Anti-Pattern: Undocumented Exceptions​

Large URL categories with no clear purpose or documentation.

Why problematic:

  • Can't determine what each URL is for
  • No ownership or accountability
  • Accumulates over time
  • Audit failure

Best practice: Use small, specific categories instead of giant catch-all categories.

Since ZIA doesn't allow documenting individual URLs, use category names and descriptions to document purpose:

Examples:

  • ✅ SSL-Exception-Salesforce-CertPinning (clear purpose in name)
  • ✅ SSL-Exception-Banking-Apps-Q1-2024 (functional grouping with timeframe)
  • ❌ SSL-Exceptions-Misc (unclear, will accumulate)

Add comments at policy level to document why specific categories are excluded from SSL inspection.

2. Wildcard Usage Patterns​

✅ Pattern: Appropriate Wildcard Scope​

Use wildcards with appropriate scope constraints.

Appropriate scenarios:

Internal infrastructure under your control:

Examples:

  • ✅ *.internal.company.com
  • ✅ *.vpn.company.net

Context:

  • All subdomains controlled by organization
  • Trusted infrastructure
  • Regular subdomain auditing

Decision framework:

Use wildcards when ALL of these are true:

  1. ✅ You control the parent domain OR it's a single trusted service
  2. ✅ All subdomains serve equivalent trust level
  3. ✅ Maintaining individual FQDNs creates unreasonable burden
  4. ✅ Regular audits verify scope hasn't expanded

Understanding Wildcard Syntax​

Zscaler treats these identically:

  • *.example.com
  • .example.com

Both match:

  • example.com (root domain) ✅
  • subdomain.example.com (all subdomains) ✅

Use a consistent syntax for better readability