7.3 Domain Name Rules, Content Actions & Inspection Exceptions
Key Takeaways
- Server Name Indication (SNI) inspection reads the unencrypted hostname in the TLS ClientHello, letting the Firebox filter and categorize HTTPS domains without full decryption; WatchGuard documents SNI as the most accurate source and falls back to the certificate Common Name when SNI is unavailable.
- Domain Name rules in an HTTPS proxy action support five actions — Allow (pass the connection through without decrypting), Inspect (decrypt and hand the stream to an HTTP proxy action or content action), Deny (refuse the request and answer the client), Drop (refuse and drop the connection), and Block (refuse, drop, and add the site to Blocked Sites).
- A separate "Action to take if no rule above is matched" setting defines the default disposition for domains that match no rule, and rules are evaluated in the order listed; wildcard patterns accept an asterisk, a period, or a question mark.
- An HTTP content action routes inbound HTTP requests to different internal web servers based on the HTTP host header and request path (host header redirect); routes set in the content action override the NAT settings in the proxy policy, and using one with the HTTPS proxy requires content inspection in an HTTPS server proxy action.
- Applications that pin certificates (mobile banking apps, cloud sync clients, OS update services) break under HTTPS Content Inspection because the re-signed certificate does not match the pinned key, so those domains need Domain Name rules set to Allow rather than Inspect.
7.3 Domain Name Rules, Content Actions & Inspection Exceptions
Quick Answer: The Firebox can enforce policy on HTTPS traffic without full decryption by reading the Server Name Indication (SNI) extension sent in cleartext in the TLS
ClientHello. Within an HTTPS proxy action, Domain Name rules support five actions — Allow (permit the request without decrypting it), Inspect (decrypt and pass the stream to an HTTP proxy action or content action), Deny (refuse the request and send a response to the client), Drop (refuse the request and drop the connection), and Block (refuse, drop, and add the site to the Blocked Sites list) — plus a separate setting for the action to take when no rule matches. A related object, the HTTP content action, routes inbound HTTP requests to different internal web servers based on the HTTP host header and path. Administrators also enforce server certificate validation and create selective inspection exceptions (Allow rules) for sensitive categories under GLBA/HIPAA and for applications that enforce certificate pinning.
Server Name Indication (SNI) Inspection vs. Full TLS Decryption
In high-throughput enterprise networks, performing full HTTPS Content Inspection on every outbound session can be resource-intensive, legally problematic, or technically incompatible with certain proprietary software. To address this, Fireware OS provides a hybrid inspection model that leverages Server Name Indication (SNI).
Mechanics of Server Name Indication (RFC 6066)
When a client web browser initiates a TLS connection, multiple virtual web servers may reside behind a single destination public IP address. To inform the remote web server which digital certificate to present, the client inserts the target hostname into the server_name extension of the initial ClientHello packet.
- Plaintext Visibility: In standard TLS 1.2 and TLS 1.3 handshakes, the
ClientHellomessage is transmitted in cleartext before cryptographic cipher suites or symmetric session keys are negotiated. - SNI Snooping: The Firebox HTTPS proxy engine parses this initial packet and extracts the Fully Qualified Domain Name (e.g.,
banking.chase.comormalware-c2-node.ru). - WebBlocker Categorization Without Decryption: The Firebox can submit this extracted domain name directly to the WebBlocker cloud database to categorize the site (e.g., Gambling, Social Media, Malicious Websites) and enforce policy actions (Allow, Deny, Warn) without decrypting the payload or requiring a Proxy Authority CA certificate on the client.
- Certificate Fallback: WatchGuard documents the SNI as the most accurate source for the server domain. When the client does not send an SNI extension, the Firebox falls back to the Common Name (CN) in the server certificate.
+---------------------------------------------------------------------------------------------------+
| SNI INSPECTION vs FULL TLS DECRYPTION |
+------------------------------------+--------------------------------------------------------------+
| SNI-ONLY INSPECTION (Allow rules) | FULL HTTPS CONTENT INSPECTION (Inspect rules) |
+------------------------------------+--------------------------------------------------------------+
| • Inspects: ClientHello SNI header | • Inspects: Decrypted HTTP commands, paths, headers, payload |
| • Client CA Cert: NOT required | • Client CA Cert: MANDATORY (Proxy Authority CA / GPO) |
| • WebBlocker: Domain-level only | • WebBlocker: Full URL paths (e.g., /path/file.html) |
| • Malware Scanning: BLIND | • Malware Scanning: FULL (GAV, APT Blocker, IPS) |
| • Resource Cost: Negligible CPU | • Resource Cost: Moderate CPU and memory buffering |
| • Application Compatibility: 100% | • Application Compatibility: Pinned apps need Allow rules |
+------------------------------------+--------------------------------------------------------------+
Configuring Domain Name Rules within HTTPS Proxy Actions
Within an HTTPS-Client proxy action, the Domain Name rules table directs every outbound encrypted session. The Firebox evaluates the domain name — taken from the TLS SNI extension, or from the server certificate Common Name when no SNI is present — and applies one of five operational actions.
+---------------------------------------------------------------------------------------------------+
| HTTPS PROXY ACTION - DOMAIN NAME RULES TABLE |
+-------------------+-----------------------+---------------+---------------------------------------+
| DOMAIN PATTERN | ACTION | PROXY ACTION | OPERATIONAL PURPOSE |
+-------------------+-----------------------+---------------+---------------------------------------+
| *.chase.com | Allow | N/A | Privacy compliance (GLBA/Banking) |
| *.wellsfargo.com | Allow | N/A | Privacy compliance (GLBA/Banking) |
| *.mayoclinic.org | Allow | N/A | Regulatory compliance (HIPAA/Health) |
| *.apple.com | Allow | N/A | Certificate pinning (Software update) |
| *.gambling.com | Deny | N/A | Policy violation (client is answered) |
| malware-c2.example| Block | N/A | Drop and add site to Blocked Sites |
| (no rule matched) | Inspect | HTTP-Client | "Action to take if no rule above is |
| | | | matched" setting: full DPI & AV |
+-------------------+-----------------------+---------------+---------------------------------------+
The Five Domain Name Rule Actions
WatchGuard documents exactly five actions for a Domain Name rule. There is no separate "Bypass" action — Allow is the action that exempts a domain from decryption.
| Action | Fireware Behavior | Typical Use |
|---|---|---|
| Allow | "Allows the HTTPS request (the proxy does not decrypt the connection)." The Firebox logs the connection and tracks TCP state, but the original client-to-server TLS session stays intact. | Inspection exceptions: banking, healthcare, and certificate-pinned applications. |
| Inspect | "Uses the specified HTTP proxy action or content action to inspect content." The Firebox terminates the client TLS session, re-signs the certificate with the Proxy Authority CA, decrypts the payload, and hands the cleartext stream to an HTTP proxy action (or an HTTP content action) for GAV, IPS, APT Blocker, WebBlocker, and MIME filtering. | General web browsing where deep threat prevention is required. |
| Deny | "Denies the specific request and sends a response to the client." The user sees an explicit denial rather than a silent failure. | Unsanctioned SaaS and policy violations where user feedback is wanted. |
| Drop | "Denies the request and drops the connection." No response is returned; the client times out. | Hostile or unwanted domains where you do not want to acknowledge the request. |
| Block | "Denies the request, drops the connection, and blocks the site." The source is added to the Blocked Sites list for the configured duration. | Confirmed malicious domains and command-and-control infrastructure. |
[!NOTE] In an HTTPS server proxy action, selecting Allow or Inspect in a Domain Name rule additionally lets you configure a routing action and port, so inbound requests for a published domain can be sent to a specific internal server and port.
Rule Order, Wildcards & the Unmatched-Domain Action
- Rule Order: Domain Name rules "are processed in the rule order listed if multiple rules match for a domain." Administrators reorder them with the Move Up and Move Down buttons, placing explicit hostnames (such as
login.microsoftonline.com) above broad wildcards. - Wildcard Syntax: Pattern matching accepts an asterisk (
*), a period (.), or a question mark (?) as wildcard characters. For instance,*.dropbox.commatcheswww.dropbox.comandclient.dropbox.com. - Unmatched Domains: The default disposition is not a catch-all row in the table. It is a separate, mandatory setting — "Action to take if no rule above is matched" — and it offers the same five actions. In a high-security configuration this is set to Inspect, so every domain that is not explicitly excepted is decrypted and scanned.
HTTP Content Actions: Host-Header Routing & TLS Offload
A content action is a distinct Fireware object that is easy to confuse with a Domain Name rule, and the exam objectives list the two together. Where a Domain Name rule decides whether to decrypt, a content action decides which internal server receives the request.
What a Content Action Does
WatchGuard defines the feature this way: "An HTTP content action enables the Firebox to route inbound HTTP requests to different internal web servers based on the content of the HTTP host header and the path in the HTTP request." Because the decision is driven by the domain in the host header, this behavior is also called host header redirect. A content action serves two purposes:
- Host Header Redirect: One public IP address can front many internal web servers. The Firebox reads the host header (and optionally the path) and forwards the request to the matching internal server, reducing the number of public IPv4 addresses an organization must buy.
- TLS/SSL Offloading: When a content action is used with an HTTPS server proxy action and content inspection is enabled, "the Firebox decrypts the inbound requests, and then sends unencrypted traffic to the internal web server." The Firebox carries the cryptographic load instead of the web servers.
+---------------------------------------------------------------------------------------------------+
| HTTP CONTENT ACTION - INBOUND HOST HEADER ROUTING |
+-------------------------------+-------------------+-----------------------------------------------+
| CONTENT RULE (host + path) | ROUTING ACTION | RESULT |
+-------------------------------+-------------------+-----------------------------------------------+
| shop.example.com /* | 10.0.2.51 : 8080 | Commerce farm receives the request |
| www.example.com /blog/* | 10.0.2.52 : 80 | Blog server receives the request |
| www.example.com /* | 10.0.2.50 : 80 | Corporate web server receives the request |
| (no rule matched) | Use Policy Default| Falls back to the SNAT settings in the policy |
+-------------------------------+-------------------+-----------------------------------------------+
Configuring and Applying a Content Action
- Create the object: In Fireware Web UI, select Firewall > Content Actions (in Policy Manager, the content action is created from the proxy action). Add the action and give it a name.
- Add content rules: Each rule specifies the pattern to match in the HTTP host header and the path in the request.
- Set the routing action: For each rule, choose Use and type the IP address of the internal server (and, if required, the port), or select Use Policy Default so the request falls back to the NAT settings configured in the proxy policy.
- Bind it to a policy: Use the content action in an inbound HTTP proxy policy, or — for encrypted traffic — in an HTTPS server proxy action with content inspection enabled, which is what allows the decrypted request to be examined and routed.
[!IMPORTANT] Routes specified in the content action override the NAT settings configured in the policy. If a published site suddenly reaches the wrong internal server after a content action is added, inspect the content rules before troubleshooting the SNAT action — the content action wins.
| Object | Question it answers | Where it lives | Requires content inspection? |
|---|---|---|---|
| Domain Name rule | Do we decrypt this HTTPS session, deny it, drop it, or block the site? | HTTPS proxy action (client or server) | No — Allow rules work on SNI alone |
| HTTP content action | Which internal web server and port should this inbound request go to? | Firewall > Content Actions, bound to an HTTP or HTTPS server proxy action | Yes, when used with the HTTPS proxy |
| SNAT action | Which internal IP does this public IP and port map to? | Network > SNAT, referenced in the policy To list | No |
Server Certificate Validation Controls
When HTTPS Content Inspection is active, internal client workstations place complete trust in the Firebox to validate the security posture of upstream web servers. If an external website utilizes an expired SSL certificate, a fraudulent root CA, or a revoked credential, the client browser will never see that defective certificate directly—it will only see the synthetic certificate generated by the Firebox.
Therefore, Fireware includes robust Server Certificate Validation controls within the HTTPS Proxy Action to prevent the firewall from blindly accepting and re-signing untrusted or compromised external certificates.
+---------------------------------------------------------------------------------------------------+
| SERVER CERTIFICATE VALIDATION ARCHITECTURE |
+---------------------------------------------------------------------------------------------------+
| |
| [External Web Server] |
| | |
| | Presents Server Certificate during TLS Handshake |
| v |
| [Firebox HTTPS Proxy Engine] |
| | |
| +---> 1. Expiration Check : Is certificate currently valid? (Not expired) |
| +---> 2. Certification Authority: Is issuer in Firebox Trusted CA Store? |
| +---> 3. Revocation Check (CRL) : Has serial number been revoked? |
| +---> 4. Revocation Check (OCSP) : Real-time query to OCSP Responder |
| +---> 5. Name Mismatch Check : Does CN / SAN match requested domain? |
| | |
| | IF VALIDATION FAILS: |
| +====================> Configured Action: BLOCK, DROP, or WARN (Send Alarm) |
| | |
| | IF VALIDATION SUCCEEDS: |
| +====================> Proceed to Re-Signing and Decrypted Content Inspection |
+---------------------------------------------------------------------------------------------------+
Core Validation Checks and Configurable Actions
Administrators configure validation actions under the Validation settings of the HTTPS Proxy Action:
- Expired Certificates: When an external web server presents a certificate whose expiration date has passed (or whose
Not Beforedate is in the future). The recommended enterprise action is Block/Drop to prevent connections to neglected, abandoned, or hijacked web servers. - Untrusted Certification Authority: Occurs when the external certificate was signed by a self-signed entity or an internal CA not present in the Firebox's trusted root store. The default action is Block/Drop. Administrators can manually import custom partner CA certificates into the Firebox if a legitimate business partner utilizes a private PKI.
- Certificate Revocation Status (CRL and OCSP):
- Certificate Revocation Lists (CRL): The Firebox downloads published lists of revoked certificate serial numbers over HTTP/LDAP.
- Online Certificate Status Protocol (OCSP): The Firebox transmits real-time queries to an OCSP responder specified in the certificate's Authority Information Access (AIA) extension.
- Action on Revocation Failure: If an external certificate is confirmed revoked (e.g., compromised private key), the Firebox immediately drops the connection. Administrators can also define fallback actions if the OCSP responder is temporarily unreachable (Allow or Drop).
- Common Name (CN) / SAN Mismatch: Occurs when the domain name in the URL does not match any name listed in the Subject Common Name or Subject Alternative Name fields. This is a classic indicator of a man-in-the-middle attack on the public Internet or a misconfigured web server; the Firebox drops matching sessions.
Regulatory Compliance & Certificate Pinning Exceptions
Deploying universal, blanket HTTPS inspection across an entire organization without exceptions is neither legally viable nor technically feasible. Two primary drivers necessitate the implementation of Inspection Exceptions: legal privacy mandates and application certificate pinning.
1. Regulatory Privacy Compliance (HIPAA, GLBA, GDPR)
In most jurisdictions, decrypting personal or financial communications of employees or patients introduces immense legal liability:
- Gramm-Leach-Bliley Act (GLBA): Mandates strict protection of non-public personal financial information. If an employer decrypts employee sessions to personal banking portals (e.g., Chase, Wells Fargo, Bank of America), personal bank account numbers, investment portfolios, and financial records are exposed in cleartext memory buffers, logs, and potential packet captures.
- Health Insurance Portability and Accountability Act (HIPAA): Governs Protected Health Information (PHI). Intercepting patient or employee connections to health insurance portals, medical clinics, or pharmacy systems constitutes unauthorized processing of health data.
- General Data Protection Regulation (GDPR) & State Privacy Laws: Prohibits the unlawful intercept, processing, or logging of sensitive personal data.
- Implementation via Domain Name Rules: The exception is expressed as a Domain Name rule whose action is Allow, which lets the session pass without decryption. Administrators typically maintain a curated list of financial, healthcare, and government domains (plus the WebBlocker category enforcement available in the HTTPS proxy action) rather than decrypting those sessions and accepting the liability.
2. The Challenge of TLS Certificate Pinning
Many modern cloud applications, mobile apps, operating system updaters, and collaboration platforms implement Certificate Pinning (also known as SSL Pinning or Public Key Pinning):
- The Pinning Mechanism: To prevent man-in-the-middle attacks, software developers hardcode (pin) the expected cryptographic hash of the server's public key or intermediate certificate directly inside the application binary.
- The Collision with HTTPS Inspection: When the Firebox intercepts a pinned application (such as Apple iOS software updates, Google Drive sync, Microsoft 365 telemetry, Dropbox desktop clients, or dedicated banking apps), it presents its synthetic certificate signed by the Proxy Authority CA. Even though the client operating system trusts the Proxy Authority CA, the pinned application compares the presented certificate's public key against its hardcoded hash.
- Application Failure: Because the keys do not match, the application detects an unauthorized intermediary, terminates the connection immediately, and logs a fatal cryptographic handshake failure. The application stops working entirely.
- The Remedy: Administrators must identify the specific destination FQDNs utilized by the pinned software and add Domain Name rules with the Allow action for those domains (e.g.,
*.apple.comor*.dropbox.com), so the Firebox passes the session through without re-signing the certificate.
Comparison Table: SNI Domain Filtering vs. Full HTTPS Content Inspection
The following table summarizes when to deploy SNI filtering versus full deep packet inspection:
| Criteria / Feature | SNI Domain Filtering (No Decryption) | Full HTTPS Content Inspection (DPI) |
|---|---|---|
| Primary Mechanism | Reads unencrypted ClientHello SNI header (falls back to certificate CN) | Terminates TLS, re-signs with CA, decrypts payload |
| Certificate Distribution | Zero client certificates required | Requires Proxy Authority CA on all endpoints (GPO) |
| Threat Protection Level | Blocks known malicious domains only | Scans full files, zero-day malware, scripts, and exploits |
| WebBlocker Granularity | Categorizes base domains only | Categorizes full URL paths and subdirectories |
| Performance Impact | Near-zero latency; negligible CPU usage | Requires cryptographic processing and stream buffering |
| Regulatory Risk | Very low (No private user data decrypted) | High unless sensitive categories are bypassed |
| Pinned App Compatibility | 100% compatible (Never breaks pinned apps) | Incompatible; pinned domains need Allow rules |
| Security Subscriptions | WebBlocker (Domain), Geolocation, Botnet | GAV, APT Blocker, IPS, WebBlocker (Full Path) |
An enterprise security policy requires that all general employee web browsing undergo full HTTPS Content Inspection, but employees accessing personal online banking portals (such as Chase, Wells Fargo, or Bank of America) must not have their sessions decrypted, because of corporate privacy liability and Gramm-Leach-Bliley Act (GLBA) compliance. How should the administrator configure the HTTPS proxy action?
A network administrator configures an HTTPS-proxy policy with Domain Name Rules to restrict access to unsanctioned websites. The administrator decides to use Server Name Indication (SNI) domain filtering without enabling full HTTPS Content Inspection. Which statement correctly identifies an operational capability and an architectural limitation of this configuration?
Following the activation of HTTPS Content Inspection across an enterprise, several users report that their desktop cloud storage sync application (such as Dropbox) and dedicated banking software fail to connect, generating SSL handshake errors. All domain workstations have the Firebox Proxy Authority CA certificate properly installed in their Windows certificate stores. What is the cause of this failure, and how should it be resolved?
An external web server's SSL certificate expired three days ago. An internal user attempts to connect to this server through an outbound HTTPS-proxy policy with Content Inspection enabled and default Server Certificate Validation settings active. How does the Firebox handle this connection?