SDWSCS Part 4: Content Filtering — URL Filtering & TLS/SSL Decryption

Part 3 turned on the engines that inspect traffic; this part is about the two features that decide what your users are allowed to browse — URL filtering — and whether any inspection engine can see inside HTTPS at all — the TLS/SSL decryption proxy. One of these is a policy conversation with HR; the other is a PKI project wearing a security feature’s clothing.

URL filtering

URL filtering runs in the same UTD container as IPS and AMP, referenced from an advanced inspection profile. Three mechanisms stack:

1. Category matching — 80+ web categories (gambling, social media, malware sites…), each allowed or blocked. The database is Talos-fed and cached locally; uncategorised or cache-miss URLs can be resolved via cloud lookup, which you should leave enabled unless the site genuinely has no path to the lookup service.
2. Web reputation — every URL carries a reputation score; you set a threshold (e.g. block below moderate risk) that applies regardless of category. This is the control that catches the freshly-registered phishing domain before any category applies to it.
3. Allow/block lists — explicit URL patterns that override both. Regex-capable, evaluated first, and the place where every “the CEO needs this site unblocked today” ticket ends up.

For blocked HTTP the user gets a block page (inline, or a redirect to a page you host); for blocked HTTPS without decryption, the session is simply reset — the browser shows a connection error, not an explanation, and your service desk should know that’s expected behaviour.

Edge# show utd engine standard statistics url-filtering
URLF-cloud lookups: 1834, cache hits: 15211
Blocked (category): 122   Blocked (reputation): 9

Without decryption, URL filtering of HTTPS works on the SNI/certificate hostname only — domain-level verdicts, not path-level. youtube.com/education vs the rest of YouTube needs decryption. Which brings us to the real subject of this module.

TLS/SSL decryption: the architecture decision

The decryption proxy makes the edge a man-in-the-middle: it terminates the client’s TLS session with a certificate it mints on the fly, and opens its own session to the server. For the forged certificates to be trusted, every client must trust the signing CA — and choosing where that CA lives is the design decision:

Option	How it works	When it’s right
Enterprise CA as root	Your CA issues a subordinate CA cert to the SD-WAN estate	You already run PKI and clients already trust the root — the clean answer
Enterprise CA + vManage intermediate	vManage becomes an intermediate under your root, issues per-edge certs	Large estates wanting per-edge certs without touching the root repeatedly
vManage as CA	vManage self-signs a root; you push that root to every client	Labs, or estates with no PKI — now you’re distributing a new root cert to every device, including the BYOD ones you can’t reach

If you followed the PKI-for-IPsec series on the Fortinet side, this is the same shape of decision with the same moral: the certificate work is 80% of the project.

The decrypt policy

Decryption is driven by its own policy, evaluated before the inspection engines: decrypt, don’t-decrypt (pass through encrypted), or drop — matched on destination categories, reputation, source/destination, and application. Two rules exist in every sane deployment:

• Never decrypt health, finance and government categories (regulatory expectation in most jurisdictions, and some banking apps certificate-pin anyway).
• Always decrypt uncategorised and low-reputation destinations — precisely the traffic where inspection earns its keep.

Then the operational settings that separate a working deployment from a ticket storm: undecryptable traffic handling. Certificate-pinned apps, client-cert authentication, TLS 1.3 with ESNI oddities, expired or self-signed server certs — for each class you choose drop or pass. Default posture worth defending: pass pinned applications you’ve explicitly listed, drop expired/untrusted server certificates, and log everything for the first month before tightening.

Resource reality: decryption is the most expensive thing the container does. Cisco’s sizing guidance assumes only a fraction of flows are decrypted; a branch edge asked to decrypt everything will disappoint everyone. Decrypt where inspection changes the outcome, pass where it doesn’t.

Edge# show sdwan utd dataplane config proxy
Edge# show crypto pki certificates CA-SUBORDINATE

Rollout order that survives contact with users

1. Deploy the CA chain and confirm a test client trusts a forged cert before any policy references decryption.
2. Decrypt policy in log-heavy, narrow scope (one category, one pilot VLAN).
3. Fix the pinned-app exceptions the pilot surfaces.
4. Widen scope; only then let URL filtering and IPS act on decrypted payloads.

Next up, Part 5: the dedicated security options — secure DIA with everything from Parts 2–4 assembled into one breakout design, and service chaining for the traffic that must pass a real firewall.