Installing the Root CA Certificate for HTTPS Block Pages
Understand why SSL certificate trust is required for HTTPS block pages, what happens when it is not installed, and how browser security affects DNS filtering behavior.
Table of Contents
Overview
The DNS Filtering Root CA certificate enables browsers to trust block page redirects for HTTPS websites. Without this trust, browsers will display security warnings instead of the expected block page when a site is blocked.
This article explains not only how to deploy the Root CA certificate, but also how DNS Filtering behaves with HTTPS, what users should expect, and how to position this functionality correctly for end users and customers.
Before You Proceed
Even with SSL certificates installed, some websites using strict HTTPS (HSTS) may still show browser warnings instead of block pages. If you deploy the DNS Filtering Agent, the CyberFOX Root Certificate will be automatically installed during agent installation, which will allow non-HSTS sites to properly display a block page. See: Why Block Pages Do Not Appear on Some Websites (HTTPS / HSTS)
Expected Behavior
Why a Trusted Certificate is Required
DNS Filtering uses a redirect model to present block pages for restricted domains. When a user attempts to access a blocked site, the request is redirected away from the original destination to a block page service.
For HTTPS connections, the browser expects the certificate presented to match the domain being requested. Because the block page uses a different certificate than the original site, the browser detects a mismatch and raises a security warning.
Installing the Root CA certificate allows the browser to trust the block page response. This enables the redirected content to be displayed as intended instead of being blocked by certificate validation
User Experience Tradeoffs
| Scenario | User Experience |
|---|---|
| Root CA installed and trusted | Block page displays normally |
| Root CA not installed | Browser shows certificate warning |
| HSTS-enforced site | Warning may not be bypassable |
| HTTP site (non-secure) | Block page always displays |
Blocking behavior is consistent — only the visual experience changes.
What End Users Will See
When the Root CA certificate is not installed, users may encounter browser error pages such as “Your connection is not private” or similar certificate warnings. These messages can vary slightly by browser, but they all indicate that the certificate presented does not match the requested domain.
When the Root CA is installed and trusted, users will instead see the DNS Filtering block page, providing a clear explanation of why access was restricted.
Even when a browser warning is shown, the request has still been blocked successfully. The warning reflects browser security behavior, not a failure in filtering.
Browser & Certificate Constraints
Modern browsers enforce strict validation rules for HTTPS connections. Certificates must match the requested domain, be issued by a trusted authority, and maintain a valid trust chain.
For sites that use HSTS, browsers will not allow users to bypass certificate warnings. This can prevent block page redirects from displaying, even when DNS Filtering is functioning correctly.
Certificates may also require periodic updates or redeployment as part of standard lifecycle management. Differences in browser behavior, certificate stores, and local policies can affect how trust is applied across devices.
Installing the Root CA Certificate
Installing the Root CA certificate enables browsers to trust the DNS Filtering block page when a blocked HTTPS site is accessed. Because DNS Filtering relies on redirecting requests for blocked domains, the browser would normally detect a certificate mismatch and display a security warning.
By installing and trusting the Root CA, the browser can validate the block page response, allowing it to render properly instead of being blocked by certificate errors. This results in a consistent and user-friendly experience where end users see the intended block notification rather than a browser security warning.
Certificate Installation Behavior
When deploying the DNS Filtering Agent, the Root CA certificate is typically installed automatically as part of the setup process.
However, this step may not complete successfully in all environments. If users continue to see browser security warnings after installing the agent, it usually indicates that the certificate was not installed or is not trusted on the device.
In these cases, you should proceed with the manual installation steps below and verify certificate trust. For more details on how the agent configures DNS and certificate behavior, see: DNS Filtering Agent Behavior
Browser Certificate Stores
While most browsers rely on the operating system’s trusted certificate store, some—such as Firefox—use their own independent certificate store. Because of this, installing the Root CA certificate on the device alone may not be enough. The certificate must also be manually imported into the browser to establish trust for HTTPS filtering behavior.
Manual Installation
Step 1: Download the Root Certificate
Download the root certificate from CyberFOX: 👉 https://cdn.passwordboss.com/dns-client/rootCA.cer
Step 2: Install the Certificate
On Windows
- Double-click
rootCA.cer. - Click Install Certificate.
- Choose Local Machine and click Next.
- Select Place all certificates in the following store.
- Browse to Trusted Root Certification Authorities.
- Click Next, then Finish.
On macOS
- Open
rootCA.cerwith Keychain Access. - Drag it into the System keychain.
- Double-click the certificate, expand Trust, and set When using this certificate to Always Trust.
- Close and authenticate to save.
On Linux
- Copy the file to
/usr/local/share/ca-certificates/. - Run:
sudo update-ca-certificates
Step 3: Verify
Visit a blocked HTTPS site. If the certificate is installed correctly, the CyberFOX DNS Filtering Block Page should appear instead of a browser warning.
Deploy using a PowerShell Script.
Using your RMM tools, you can download the Root Root certificate and deploy it automatically using this PowerShell script as an administrator.
# Copyright (c) 2026 CyberFOX LLC
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
# * Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
# * Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution.
# * Neither the name of the AutoElevate nor the names of its contributors
# may be used to endorse or promote products derived from this software
# without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
# DISCLAIMED. IN NO EVENT SHALL CYBERFOX BE LIABLE FOR ANY DIRECT, INDIRECT,
# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,
# OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
# LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
# NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
# EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
<#
Installs the Root Certificate for CyberFOX DNS Filtering to reduce errors on block pages. REQUIRES ADMIN RIGHTS TO DEPLOY
#>
# Download the Certificate from the source location
$Uri = "https://cdn.passwordboss.com/dns-client/rootCA.cer"
$Tmp = Join-Path $env:TEMP "rootCA.cer"
Invoke-WebRequest -Uri $Uri -UseBasicParsing -OutFile $Tmp
# Validate thumbprint
$Expected = "6AC54D30EE60A4A95D709D805D7A0DA12ED6E03D".ToUpper()
$Actual = (Get-PfxCertificate $Tmp).Thumbprint.ToUpper()
if ($Actual -ne $Expected) { throw "Thumbprint mismatch: expected $Expected, got $Actual" }
# Import to machine root store (requires admin)
Import-Certificate -FilePath $Tmp -CertStoreLocation "Cert:\LocalMachine\Root"
# Verify
Get-ChildItem Cert:\LocalMachine\Root |
Where-Object Thumbprint -eq $Expected |
Select-Object Subject, Thumbprint
You can verify the installation of the Certificate with this command:
Get-ChildItem Cert:\LocalMachine\Root |
Where-Object Thumbprint -eq "6AC54D30EE60A4A95D709D805D7A0DA12ED6E03D" |
If you need to remove the Root Certificate, deploy the following script:
# Copyright (c) 2026 CyberFOX LLC
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
# * Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
# * Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution.
# * Neither the name of the AutoElevate nor the names of its contributors
# may be used to endorse or promote products derived from this software
# without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
# DISCLAIMED. IN NO EVENT SHALL CYBERFOX BE LIABLE FOR ANY DIRECT, INDIRECT,
# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,
# OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
# LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
# NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
# EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
<#
Removes the Root Certificate for CyberFOX DNS Filtering. REQUIRES ADMIN RIGHTS TO DEPLOY
#>
$thumb = "6AC54D30EE60A4A95D709D805D7A0DA12ED6E03D".ToUpper()
$store = New-Object System.Security.Cryptography.X509Certificates.X509Store("Root","LocalMachine")
$store.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite)
$cert = $store.Certificates | Where-Object { $_.Thumbprint.ToUpper() -eq $thumb }
if ($cert) { $store.Remove($cert); "Removed: $($cert.Subject) [$thumb]" } else { "Not found" }
$store.Close()
Deploy using Intune.
- Admin Center: https://intune.microsoft.com
- Devices → Windows → Configuration profiles → Create profile
-
Platform: Windows 10 and later
- Profile type: Templates → Trusted certificate
-
Basics
- Name: Trusted Root CA – CyberFOX DNS
- Description: Deploy CyberFOX DNS Root CA (thumbprint 6AC5...E03D) to Computer\Root
- Configuration settings
- Trusted certificate: Upload the rootCA.cer certificate
- Destination store: Computer certificate store – Root
- Scope tags (optional): apply your RBAC tags.
-
Assignments
- Include: your Windows device groups (e.g., All Windows Devices).
- Exclude: any groups that should not receive the CA.
- Review + Create
Why Computer\Root? It ensures system‑wide trust for services (VPN/Wi‑Fi/agents). Use User\Root only for very specific user‑scoped scenarios.
Guidance to give to End Users
When to Deploy the Root CA
The Root CA certificate is best deployed on managed devices where you control certificate trust and want users to consistently see block pages instead of browser warnings. This is typically limited to corporate-owned endpoints with centralized management.
For unmanaged environments—such as guest networks or personal devices—deployment is usually not practical. In these cases, users should expect browser security warnings when accessing blocked HTTPS sites, even though the block is still being enforced.
Tradeoffs to Consider
| Deployment Decision | Benefit | Tradeoff |
|---|---|---|
| Install Root CA | Clean block page experience | Requires device management |
| Do not install | Simpler deployment | Users see browser warnings |
How to Explain to End Users
When communicating this behavior to end users, keep the explanation simple and outcome-focused. A clear way to frame it is:
“We’re blocking the site before it loads. If the browser shows a security warning instead of a block page, that’s because it’s enforcing HTTPS protections — not because filtering failed.”
The key point is to reinforce that blocking occurs at the DNS level, before any content is delivered, and that browser warnings are a built-in security measure. Installing the Root CA improves how the block is presented to the user, but it does not change the underlying security or filtering effectiveness.
Best Practices
Deploy the Root CA through centralized management tools such as GPO or MDM to ensure consistent certificate trust across managed devices. At the same time, set expectations early by including this behavior in onboarding or training materials so users understand what they may see when accessing blocked HTTPS sites. Support teams should be familiar with the difference between browser warnings and block pages, and rely on logs or reporting to confirm enforcement rather than visual confirmation in the browser.
Troubleshooting
Block Page Not Appearing
This scenario is most commonly caused by HTTPS enforcement and certificate trust issues, rather than a failure in DNS Filtering itself.
If a block page is not displayed, start by confirming that the domain is actually being blocked by policy. From there, determine whether the site is using HTTPS or HSTS, as this can prevent the block page from rendering. You should also verify that the Root CA certificate is installed and trusted on the device. Even when the block page is not shown, the request is still being blocked as expected.
Certificate Warnings Persist
If users continue to see certificate warnings, confirm that the Root CA certificate is trusted at both the operating system and browser level. Some browsers maintain their own certificate stores, which may require additional configuration. It is also important to check that the certificate is still valid and has not expired.
Inconsistent Behavior Across Devices
Differences in behavior between devices are typically caused by gaps in management or certificate deployment. Validate that all endpoints are properly covered by your MDM or Group Policy deployment, and check for unmanaged or non-compliant devices that may not have the certificate installed.
Security & Sync Behavior
Security Model
DNS Filtering operates without decrypting HTTPS traffic and does not impersonate destination domains. Instead, it relies on standard browser trust mechanisms when presenting block pages, which is why certificate trust becomes a factor in how the experience is displayed to the user.
Sync Behavior
For consistent results, the Root CA certificate must be deployed and trusted across all endpoints. Differences in operating systems, browsers, and local policies can affect how that trust is applied, and browser caching or stored policies may also influence behavior during testing or after changes are made.