What the Feature Is

Block pages and what they do

A block page is the user-facing notification that appears when someone attempts to reach a domain your policy restricts. It tells the user the site was blocked, which category matched, and who to contact — turning a silent failure into a self-explanatory one. This reduces helpdesk tickets and supports audit and user-education requirements.

Block pages are a notification feature, not an enforcement feature. Enforcement happens at DNS resolution. If the block page never renders, nothing was let through.

How block pages are delivered

1. A client requests a domain that policy blocks.
2. The CyberFOX resolver returns the block page service address instead of the real destination.
3. The browser connects to the block page service, which serves the block page.

Over plain HTTP, step 3 is unremarkable, and the page renders reliably. Over HTTPS, step 3 requires the block page service to complete a TLS handshake for a domain CyberFOX does not own — and that is where the difficulty lies.

The resolver and the block page service operate independently. The resolver enforces the block; the block page service only attempts to explain it. This is why a healthy block can coexist with a 502 or 504 from the block page service, and why the two are diagnosed separately below.

HTTPS and HSTS Behavior

Why HTTPS changes the problem

When a browser requests https://blocked-example.com, it verifies the certificate it receives against the hostname it asked for. Two independent conditions must hold:

Installing the root CA satisfies trust. It does not satisfy identity. Both are required, and a failure of either produces a certificate error.

What HSTS actually does — and does not do

The following video explains how HSTS works at the browser level and why security warnings cannot be bypassed.

HSTS (RFC 6797) is commonly blamed for this behavior. Precision matters, because the wrong mental model leads to hours spent on fixes that cannot work.

HSTS does not inspect, pin, or specify certificates. The standard defines exactly two directives — max-age and includeSubDomains — and neither references a certificate, a certificate authority, or a public key. Certificate pinning was a separate mechanism (HPKP, RFC 7469) that browsers removed years ago.

What HSTS does: per §2.2 and §8.4, it upgrades insecure references to HTTPS for known HSTS hosts and requires the browser to terminate the connection on any secure-transport error or warning. §12.1 ("No User Recourse") recommends doing so without offering the user a dialog to proceed.

The consequence:

HSTS is not the cause of the certificate failure. It is why the failure cannot be bypassed. The certificate problem is present on every HTTPS site; HSTS removes the escape hatch. This is why clearing an HSTS cache will not produce a block page.

Expected user experience

On a blocked HTTPS site, users may report:

• Your connection is not private (Chrome, Edge)
• Warning: Potential Security Risk Ahead (Firefox)
• NET::ERR_CERT_COMMON_NAME_INVALID
• NET::ERR_CERT_AUTHORITY_INVALID
• A warning with no option to proceed — the page cannot be bypassed at all
• On some sites, a warning that can be clicked through, after which the block page appears

Platform-Specific Steps

Block page behavior depends on the endpoint's certificate trust store and browser, so the steps below cover deploying and verifying the CyberFOX root CA per platform. DNS Filtering block pages have no WebApp or standalone desktop component; the relevant surfaces are the admin Portal and the endpoint operating systems.

Admin Portal

1. Sign in to the CyberFOX DNS Filtering portal.
2. Navigate to the policy or location where you want to configure the block page. See Configuring Block Pages.
3. Confirm the block page is enabled for the policy and that your custom messaging, logo, and contact address are set.
4. Download the root CA certificate from the portal's certificate section. See Installing the Root CA Certificate for HTTPS Block Pages.
5. Confirm outbound TCP 443 to *.dns.cyberfox.com is permitted at every site. See IP Addresses, URLs, and Ports to Allowlist.

Windows endpoints

Deploy the root CA to Local Machine > Trusted Root Certification Authorities, not the current-user store, so it applies to all users and services on the device.

Group Policy:

1. Open Group Policy Management and edit a GPO linked to the target OU.
2. Go to Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities.
3. Right-click, choose Import, and select the CyberFOX root CA file.
4. Force a refresh on a test endpoint with gpupdate /force, then verify.

PowerShell, for RMM script deployment:

Verify:

Per-RMM delivery:

macOS endpoints

Add the certificate to the System keychain and mark it as trusted:

Verify:

For managed fleets, deliver as a configuration profile payload through Jamf, Mosyle, Kandji, or Intune rather than scripting, so trust settings survive OS updates.

iOS and iPadOS

Certificates delivered outside MDM require a two-step user action, so MDM is strongly preferable.

• MDM (recommended): push the root CA as a certificate payload in a configuration profile. MDM automatically grants trust for MDM-installed roots.
• Manual: the user installs the profile via Settings > General > VPN & Device Management, then must separately enable it under Settings > General > About > Certificate Trust Settings. Skipping the second step leaves the certificate installed but untrusted, and blocked pages will continue to fail.

Android

• Managed devices: deploy via your EMM as a CA certificate for the work profile.
• Unmanaged devices: Settings > Security > Encryption & credentials > Install a certificate > CA certificate. Android displays a warning during installation; this is expected for any private CA.
• Chrome on Android honors the system store for user-installed CAs on most builds, but applications using certificate pinning or their own trust store will not. Block pages will not appear for traffic from those apps.

Mobile caveat

Mobile browsers and in-app webviews enforce certificate handling more strictly and offer fewer bypass paths than desktop browsers. Even after the certificate fix described below, expect block pages to be less consistently rendered on mobile than on managed desktops. Plan user communication accordingly.

Advanced Use Cases

Environments where block pages should stay off

In some deployments, the block page adds risk or noise rather than value:

• Server and infrastructure VLANs. A certificate error on an automated HTTPS call is more confusing to diagnose than a clean resolution failure. Consider policies that return a non-resolving response for these ranges rather than redirecting to the block page service.
• Environments where installing a private root CA is not permitted. Some CMMC, SOC 2, and FedRAMP-adjacent clients prohibit adding private roots to endpoint trust stores. Those clients can run DNS Filtering as a pure enforcement control with logging, and should be onboarded with the expectation that HTTPS block pages won't be available to them.
• BYOD populations. You won't reliably get a root CA onto unmanaged personal devices. Enforce and log; don't promise block pages.

Filtering alongside an existing TLS-inspecting proxy

If a client already runs a proxy or SASE gateway that terminates TLS, that device already presents substitute certificates, and its root is already trusted on the endpoints. Layering CyberFOX block pages underneath can produce confusing double-substitution behavior. Decide which layer owns user notification and disable the block page on the other.

Verifying enforcement without relying on the block page

Build acceptance testing around logs rather than screenshots:

1. Attempt a known-blocked domain from a test endpoint. See Testing Filtering Policies.
2. Confirm the block appears in the filtering logs with the expected category, policy, and location. See Query Logs: Viewing and Filtering DNS Requests.
3. Record the log entry as the evidence artifact.

This is the correct approach for compliance evidence in any case — a screenshot of a block page proves less than a log record tied to a policy.

Roaming clients and off-network endpoints

Roaming clients enforce policy off-network, so the same certificate conditions apply wherever the device is. Confirm the root CA is deployed to the device itself rather than relying on anything on the network side. See Using Roaming Clients for DNS Filtering.

Best Practices

Set expectations at onboarding

Tell clients during deployment that HTTPS block pages depend on a certificate being installed on every managed endpoint, and that unmanaged devices will show a security warning rather than a friendly page. Discovering this after go-live reads as a product defect; stating it up front reads as architecture.

Deploy the root CA as part of the standard build

Fold the certificate into your golden image or baseline RMM policy rather than deploying it reactively. A device that joins the network without it will behave differently from its peers, and that inconsistency is hard to troubleshoot later.

Never train users to click through certificate warnings

Where a bypass option exists, resist the temptation to tell users to use it. Clicking through certificate warnings is the exact behavior that TLS warnings exist to prevent, and habituating users to it undermines protections well beyond DNS filtering. Fix the certificate path instead.

Instrument the helpdesk for this symptom

Give tier-one staff a one-line decision rule: a certificate warning on a blocked site is expected and needs no escalation once the block is confirmed in the logs; a 502 or 504 is a service fault and does need escalation. This alone removes most of the ticket volume this behavior generates.

Keep an eye on which sites assert HSTS

You cannot change a third party's HSTS policy, and the share of the web asserting it grows every year. Treat "no block page on HTTPS" as the default expectation and the rendered page as the pleasant exception, rather than the reverse.

Troubleshooting

Step 1 — Classify the error

Checking whether the site asserts HSTS (via developer tools or response headers) tells you only whether the user will be able to click through the warning. It does not tell you whether the block succeeded, and it does not change the fix. Confirm the block in the logs instead — Step 4.

Step 2 — Known issue: certificate does not cover the requested hostname

Status: Fix in development · Affected: all HTTPS block page attempts, all platforms · Reference: [JIRA-KEY — see publishing notes]

The block page service currently presents a certificate that does not include the requested hostname in its Subject Alternative Name. Hostname verification therefore fails on every HTTPS site, not only HSTS-enabled ones. Root CA installation satisfies trust but cannot satisfy identity.

Engineering is implementing per-request certificate generation: the block page service will read the hostname from the TLS SNI value and issue a leaf certificate carrying that hostname, signed by the CyberFOX CA already deployed to endpoints. RFC 6797 §11.3 describes this pattern — operating a private CA in conjunction with HSTS — as workable, provided the root is deployed to endpoint trust stores.

No workaround produces a block page on HTTPS sites until this ships. Confirm enforcement through the logs.

You can verify what your own endpoints receive. First, get the block page service address the resolver is returning:

Then inspect the certificate it presents, substituting a domain your policy blocks:

If subjectAltName does not contain blocked-example.com, you are seeing this issue.

Step 3 — Verify root CA trust on the endpoint

Use the platform-specific verification commands above. Confirm the certificate is in the machine or system store, not a per-user store, and that it has not expired. On Firefox, confirm security.enterprise_roots.enabled is true.

Step 4 — Confirm the block itself

Look the domain up in your filtering logs. A logged block plus a certificate warning on the endpoint means enforcement succeeded and only notification failed. This is the single most useful diagnostic step and should come before any endpoint work.

Step 5 — Check service reachability and health

1. Confirm outbound TCP 443 to *.dns.cyberfox.com is open from the affected site, including through any upstream firewall or SASE gateway.
2. Check the Current Status page for block page service incidents.
3. Retry; 504s are frequently transient.

Step 6 — Test the HTTP path

Browse to the http:// version of a blocked site that does not immediately redirect. If the block page renders, DNS enforcement and the block page service are both healthy, and the fault is isolated to certificate handling.

Then compare a second endpoint and a second browser. Behavior that differs between devices points to inconsistent root CA deployment — check Step 3 on the failing device. Behavior that differs between browsers on the same device usually means Firefox is using its own trust store, or an app is pinning certificates. Behavior that is identical everywhere is the known issue in Step 2, which affects all platforms equally.

Step 7 — Clear cached HSTS state, for policy testing only

HSTS policies are cached per domain, persist across sessions, and are honored in private browsing. Clearing that cache gives you a clean test after a policy change. It will not make a block page appear, and preloaded domains cannot be cleared at all.

• Chrome / Edge: chrome://net-internals/#hsts → Delete domain security policies
• Firefox: clear site data for the domain, or Forget About This Site
• Safari: requires clearing website data

Step 8 — Escalate with evidence

Open a support ticket including the affected domain, a screenshot with the exact ERR_ code visible, the openssl s_client output if you can obtain it, browser and OS versions, and confirmation of whether the root CA is present in the endpoint's machine store.

Security & Sync Behavior

The security model

Displaying a block page on an HTTPS site means presenting a certificate for a domain CyberFOX does not control. That is certificate substitution, and from the browser's perspective it is indistinguishable in form from a man-in-the-middle. It is safe only because you, the administrator, deliberately install a root CA you control on endpoints you manage — the browser's trust decision is delegated to your judgment.

This is the same model every TLS-inspecting proxy and SASE gateway uses. It is legitimate, and it is also not nothing.

What DNS Filtering does not do:

• It does not decrypt, inspect, or log the contents of encrypted sessions.
• It does not substitute certificates for traffic it is not blocking. Only blocked domains are redirected to the block page service.
• It does not require a root CA at all if you accept enforcement-only operation without block pages.

Root CA handling

• Deploy through managed channels — GPO, MDM, EMM, or RMM. Never by emailing certificate files to users; that trains exactly the behavior a bogus-root phishing attack relies on, a risk RFC 6797 §11.3 and §14.8 both call out directly.
• Track the certificate's expiry and plan replacement ahead of it. An expired root produces ERR_CERT_AUTHORITY_INVALID on every blocked HTTPS site simultaneously.
• Removing the root CA cleanly reverts endpoints to enforcement-only behavior. Filtering continues; only block page rendering stops.

Cache and propagation behavior

When a policy change appears not to have taken effect, work through this table before opening a ticket — cached state accounts for most such reports.

Logs are the record of enforcement

Because the visual experience varies by site, browser, and platform, the filtering logs are the only reliable evidence of what was blocked. Build reporting, client-facing summaries, and compliance evidence on log data. See DNS Filtering Reports & Logs.

Related Articles

• Configuring Block Pages
• Installing the Root CA Certificate for HTTPS Block Pages
• Testing Filtering Policies
• DNS Filtering Troubleshooting Guide
• Understanding DNS Filtering
• IP Addresses, URLs, and Ports to Allowlist