Protecting a Local Blocklist with a Locally or Self-Signed Certificate

[sproggit]

According to the Technitium DNS documentation, if you want to use a custom blocklist hosted on an internal server using a self-signed certificate, one must either use a trusted CA-issued certificate or bypass HTTP-to-HTTPS redirection issues, for example by using "file://" URLs in the blocklist input field and then placing your blocklist in the web root directory of your Technitium DNS installation. From what I've read, the reason for this limitation is that, under the hood, Technitium DNS uses some .Net Code [it's a portable .Net application] to validate the certificates of remote blocklist serving web sites - and if the root CA of those sites is not "well known" to .Net, you'll see errors in your Technitium DNS logs.

All of which feels a bit disjointed.

Well... some good news may be at hand - at least for some Technitium DNS Users. I will show you, below, how I managed to add a locally-hosted blocklist, signed by a locally-hosted Certificate Authority, and got everything to work.

1. Local Infrastructure
I am using SmallStep CA as my own in-house Certificate Authority. I run that on a dedicated ubuntu Virtual Machine on one of my NAS boxes, but as long as you have your own CA, what follows should work for you.
I am also using a pair of Raspberry Pi 4B machines to host a Primary/Secondary pair of Technitium DNS Servers, on which I run a combination of my own local Zones, Blocklists, and of course upstream name resolution for local clients. I'm not using Docker or any form of virtualisation on the Pi's - Technitium is installed and running locally.

2. Set Up your Local Blocklist-Hosting Web Server
I used "openssl" on my Mint Linux workstation to to generate my key pair, but that isn't necessary - you can create your key pair using other tools if you prefer.
I then used the StepCA client on my workstation and the command line to sign the generated CSR and produce the certificate [.crt] for my local blocklist host web server. In fact, I chose to set up a dedicated Apache2 instance just for blocklists - it hosts both the Technitium DNS Blocklist, but also one for "AdBlock Plus", which I run on my browser. Obviously you don't need both...

3. Add your Web Cert to your Local Blocklist Host
I'm running an Apache2 instance on another Raspberry Pi, and chose to host a virtual server there as a home for my custom blocklist. I deployed my signed certificate and used a web browser to test and ensure that I got a clean TLS connection with no reported issues. I used Firefox as my browser and I have previously imported my Root Certificate there in order to access other web resources securely.

4. On your Technitium DNS Host - Add your Local CA's Root Certificate to the System CA Store
The RaspberryPi OS is basically Debian compiled on the ARM64 platform, with a few local customizations, but basically all I needed to do was copy the Root Certificate file from my CA to the relevant system folder :-

sudo cp root_ca.crt /usr/local/share/ca-certificates/

and then tell the local host that I'd done so and that it needed to assimilate this new root certificate in to it's list of locally-trusted CAs :-

sudo update-ca-certificates

I got an update message that stated, "1 added, 0 removed; done." as a confirmation... and that was that.

5. Add your local Blocklist to Technitium DNS Blocklists:-
IMPORTANT: When you come to add the URL for your local Blocklist server, the chances are that it will be hosted on one of your local servers and that the FQDN of that local server should be in a Zone of your Technitium DNS instance. I'm sure this is going to be self-evident when you think about it... but it is worth being explicit and stating - that before you add a "local" URL to the Blocklist table, you must have added that URL as an "A" Record in one of your local Zones. Simply because... you're going to need Technitium to resolve that address for you. And note: you really do need to do this via URL and not simply hand-hack in an IP address, because the Technitium code will insist on having a TLS connection to your local list server, not merely HTTP or IP. So it's a good idea [as in: essential] to hold off the addition of your own local Blocklist until after you have your local Zone set up and working...

Authenticate to the Web Admin page for your Technitium DNS. Select Settings >> Blocking. Scroll down the page until you see a large text box with the label, "Allow / Block List URLs" ... and then add the URL of your locally-hosted, custom blocklist to that text box on a new line.

Once you've done that, if you want it to be incorporated immediately [there is a 24-hour refresh by default], then simply scroll down a little bit further, find the button, "Update Now" and give it a click.

6. Validate the Custom List works
Before you start celebrating... take a moment while you're authenticated to the Web Admin interface to navigate to "Logs" on the Top Level Menu and then select "View Logs". Select the most recent log - it will usually have the current date as the name and scroll all the way to the bottom.

If you have any issues with the configuration you've just set up, you'll see 2 log messages:

[2026-04-15 10:08:46 UTC] DNS Server is downloading block list: https://blocklist.{domain}.{tld}/technitium.txt
[2026-04-15 10:08:46 UTC] DNS Server failed to download block list and will use previously downloaded file (if available): https://blocklist.{domain}.{tld}/technitium.txt

You might also see:

System.Net.Http.HttpRequestException: The remote certificate is invalid because of errors in the certificate chain: PartialChain (blocklist.{domain}.{tld}:443)

However, once you update the local host's store of trusted root certificates, you should see a "success" log message, which looks like this:-

[2026-04-15 14:53:51 UTC] DNS Server successfully downloaded block list (1.24 KB): https://blocklist.{domain}.{tld}/technitium.txt

7. Test the New Blocklist
Once you have established that your instance of Technitium is accepting your custom local blocklist, you can start to add custom URLs and then test them. For example, right now I'm using a workstation running the Mint Linux OS, which is based on Ubuntu Linux. As a result, the kernel makes repeated "connectivity checks" to the CNAME: "connectivity-check.ubuntu.com"... This is largely harmless ... but if you have a bunch of these machines this is just completely pointless network chatter you don't actually need. I simply added that URL to my "technitium.txt" file, asked Technitium DNS to refresh it's blocklists using the button on the Admin web page... and that was that.

Now, quite how you set up your actual local blocklist is entirely up to you. In my case, even though my local "blocklist" web site is running on a Raspberry Pi 4B, I used an NFS mount and a symbolic link in the Pi's file system so that I can keep my actual blocklist text file on a QNAP NAS host. That way, I get something that is protected by a RAID-6 disk subsystem, is presented on one of my "Admin Shares" - which makes it trivially easy for me to edit the file in real time and test the results. One of the main reasons I set up my blocklist in this way [rather than use "file://" is simply because I'm running a Primary/Secondary pair for my DNS setup... and that would potentially mean having two copies of the file. I didn't want to add network services to either host to allow it to share a single copy of the file, so using NFS mounts to my QNAP NAS seemed like a sensible approach. And it works.

And that's it.

If you're running Technitium on a Windows host rather than Linux, then you have a slightly different process to get your root CA cert to be accepted by your local host. For windows you should:-

1. Run mmc.exe as a local Administrator

2. Add the Certificate Snap-In
   Select File -> Add/Remove Snap-In -> Certificates ->Computer Account -> Local Computer

3. Import your Root Cert
   Navigate to Trusted Root Certificate Authorities -> Certificates.
   Right-click, select "All Tasks" -> Import, and then choose your certificate file using the file dialogue box.

Hopefully what I've described here is sufficiently "tech neutral" that others will be able to adapt this to their own needs.