NL Dutch
FR French
IT Italian
JP Japanese
DE German
US English (US)
ES Spanish

Contact Us

If you still have questions or prefer to get help directly from an agent, please submit a request.
We’ll get back to you as soon as possible.

  • Contact Us
English (US)
NL Dutch
FR French
IT Italian
JP Japanese
DE German
US English (US)
ES Spanish
  • Home
  • CyberFOX DNS Filtering
  • Managing your DNS Filtering Policies

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.

Written by Owen Parry

Updated at May 19th, 2026

Contact Us

If you still have questions or prefer to get help directly from an agent, please submit a request.
We’ll get back to you as soon as possible.

  • AutoElevate Knowledgebase
    New to AutoElevate? START HERE AutoElevate Features & Troubleshooting Managing Rules in AutoElevate Integrations for AutoElevate AutoElevate FAQ Selling AutoElevate
  • Password Boss Knowledgebase
    Using Password Boss Administrating Password Boss Legacy Password Boss
  • CyberFOX DNS Filtering
    Getting Started with DNS Filtering DNS Filtering Concepts Network Requirements for DNS Filtering DNS Filtering Company and Location Setup Managing your DNS Filtering Policies Using Roaming Clients for DNS Filtering DNS Filtering Reports & Logs DNS Filtering Troubleshooting
  • Marketing Toolkit
    MSP Marketing & Education Toolkit CyberFOX Brand Guidelines
  • Changelogs for Autoelevate and Password Boss
  • CyberFOX Product Roadmap
  • Current Status
+ More

Table of Contents

Overview Before You Proceed Expected Behavior Why a Trusted Certificate is Required User Experience Tradeoffs What End Users Will See Browser & Certificate Constraints Installing the Root CA Certificate Certificate Installation Behavior Browser Certificate Stores Manual Installation Deploy using a PowerShell Script. Deploy using Intune. Guidance to give to End Users When to Deploy the Root CA Tradeoffs to Consider How to Explain to End Users Best Practices Troubleshooting Block Page Not Appearing Certificate Warnings Persist Inconsistent Behavior Across Devices Security & Sync Behavior Security Model Sync Behavior Related Articles

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


When accessing a blocked HTTPS website, users may see either a block page or a browser security warning depending on the device and browser configuration.
 
This does not indicate a failure in DNS Filtering. The domain is still being blocked before the website loads. The difference is how the browser presents the result based on certificate trust and HTTPS enforcement.
 
Installing the Root CA certificate allows the block page to display correctly in most managed environments, but some websites—particularly those enforcing HSTS—may still show browser warnings.

 

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

  1. Double-click rootCA.cer.
  2. Click Install Certificate.
  3. Choose Local Machine and click Next.
  4. Select Place all certificates in the following store.
  5. Browse to Trusted Root Certification Authorities.
  6. Click Next, then Finish.
 
 

On macOS

  1. Open rootCA.cer with Keychain Access.
  2. Drag it into the System keychain.
  3. Double-click the certificate, expand Trust, and set When using this certificate to Always Trust.
  4. Close and authenticate to save.
 
 

On Linux

  1. Copy the file to /usr/local/share/ca-certificates/.
  2. 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.


  1. Admin Center: https://intune.microsoft.com
  2. Devices → Windows → Configuration profiles → Create profile
  3. Platform: Windows 10 and later
    1. Profile type: Templates → Trusted certificate
  4. Basics
    1. Name: Trusted Root CA – CyberFOX DNS
    2. Description: Deploy CyberFOX DNS Root CA (thumbprint 6AC5...E03D) to Computer\Root
  5. Configuration settings
    1. Trusted certificate: Upload the rootCA.cer certificate
    2. Destination store: Computer certificate store – Root
  6. Scope tags (optional): apply your RBAC tags.
  7. Assignments
    1. Include: your Windows device groups (e.g., All Windows Devices).
    2. Exclude: any groups that should not receive the CA.
  8. 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.

 

Related Articles


  • CyberFOX DNS Filtering
  • Why Block Pages Do Not Appear on Some Websites (HTTPS / HSTS)
  • DNS Filtering Troubleshooting Guide
  • Configuring Block Pages
filters dns certificates ssl https https block page ssl certificate root ca dns filtering ssl trust chain trusted certificate block page https dns security connection not private certificate warning hsts dns resolver content filtering browser security certificate mismatch endpoint management mdm deployment gpo certificate secure browsing dns policies filtering behavior

Was this article helpful?

Yes
No
Give feedback about this article

Related Articles

  • Configuring Block Pages
  • Why Block Pages Do Not Appear on Some Websites (HTTPS / HSTS)
  • DNS Filtering Troubleshooting Guide
Request a Demo
  • Get Pricing
  • Start Trial
  • Contact
  • Support Center
  • Login
Solutions
AutoElevate
  • AutoElevate Overview
  • Remove Admin Privilege
  • Just-in-Time Admin
  • Blocker
Password Manager
  • Password Manager Overview
  • Features
DNS Filtering
  • DNS Filtering Overview
MSPs
IT Departments
  • Overview
  • State and Local Government
  • K-12 Education
  • Manufacturing
  • Higher Education
Resources
  • Resource Center
  • Group Demos
  • Events
  • The Simple 7™
Company
  • About
  • Leadership
  • Culture & Values
  • News & Press
  • Awards
  • Partnerships
  • Referral Program
  • Trust Center
CyberFox Logo

CALL US (813) 578-8200

© 2025 CYBERFOX LLC ALL RIGHTS RESERVED | Privacy Policy | Terms of Service | Sitemap


Knowledge Base Software powered by Helpjuice

Expand