Easy Self-Signed Certificates for Selfhosted Services + DNS Rewrites for privacy front-ends

Introduction

DNS and SSL are two of the most infuriating aspects of selfhosting. In all my years of selfhosting, every time something broke in the most incomprehensible way, SSL and DNS have been the culprits.

DNS and SSL are the backbones that allow end users to experience the internet seamlessly and securely, but they are god awful to work with. Honestly, if you enjoy your sanity, don't even bother trying anything fancy, just use Nginx Proxy Manager, Let's Encrypt, and have a nice day.

But, if you hate yourself, enjoy learning a little more, or are just bored, stick around and learn how I managed to get DNS redirects working on my home network, and how you can avoid a day of troubleshooting :')

How do DNS & SSL work?

Disclaimer: I am not a networking engineer - nor even someone who has done any amount of professional study or work in networking. I'm just a girl ⸜(｡˃ ᵕ ˂ )⸝♡

Way oversimplified crash course on DNS & SSL

You can think of how DNS and SSL work in the same way as GPS navigation.

Let's say you are trying to go to your friend Stacy's apartment. You have their street address saved in the map, so you ask your navigation provider (Google) to route you to "Stacy's House". The app translates that nickname into the street address saved, and then reaches out to Google's servers. Google, who has a list of where every address is and can calculate how to best get there, routes you to the apartment complex.

You arrive at the complex and take a look at the complex map. That map tells you where Stacy's apartment number is. That is your final destination and now you can begin walking towards it.

With DNS, it's roughly the same.

You type in a domain name. That domain name is sent to a DNS server who checks where that domain name is meant to go for the type of traffic. It then returns a public IP address. Once you connect to that server's public IP address, the reverse proxy in that network tells you what private IP address to connect to.

DNS routes you to where you need to go. SSL ensures that everything you do when there is private.

Going back to our analogy, imagine you and Stacy are spies and are meeting for the first time. You need her to give you a password before you can enter her house and have a private conversation with her.

Your spy org has a main body and independent cells. Each cell has its own unique password. Stacy gives you the password of your local cell. You trust that Stacy is part of your cell, and go inside her apartment to talk in private.

What happens if the main body was giving out the passwords? Why does each local cell need its own password?

Imagine the main body's big book of passwords was stolen. Suddenly, every agent could be impersonated. You would have to go to every agent and tell them to rotate to a new password. This would need to be done rapidly to avoid them getting caught and compromised. It would be expensive and intensive, with no guarantee of success.

By having passwords set by local cells, agents can be assured that individuals are part of the larger organization, while also limiting risk. If any local cell's password is compromised, then damage is limited to that small cell, and not the entire spy organization. It still has the same problems, but a much lower blast radius.

SSL certificates do the same thing - The website you are connecting to gets a trustworthy "password" (public key) from an intermediate certificate authority, who in turn gets their authority from the root certificate authority. This model: root CA -> intermidiate CA -> End entity Certificate is commonly referred to as the chain of trust.

When you connect to that service, Your device and the service conduct a "handshake" where encryption keys for the rest of the session are created. An SSL certificate allows you the trust to encrypt your data, hiding it from being read by anyone in between yourself and the service you are trying to connect to.

So why use self-sign certificates? Why do they need to be added to your browser, and why can you not just use a public service like Let's Encrypt for your services?

There are generally three classes of certificate authorities:

• Commercial
• Non-Profit
• Private

Most operating systems / software have a list of certificate authorities they trust by default. These are your "globally" trusted certificate authorities. Commercial CAs made up all of those before Let's Encrypt. If you wanted your website to work with the public out of the box, you had to pay for it.

Eventually Let's encrypt, a non-profit, was formed and they became the largest globally trusted free certificate provider for the public. More have joined, and other for-profit organizations like Cloudflare also started providing free SSL certificates.

Nowadays, commercial CAs are mostly used by bigger companies that are trying to pass audits. Certain regulations require that the root certificate authority be located in a specific country, have specific standards for storing the root certificate authority key, or require stricter authentication methods.

Most public certificate authorities only allows you to set up SSL certificates for domains that you own. This level of verification is referred to as Domain Validation This is to help prevent DNS spoofing attacks.

A DNS spoofing attack is the technique we will use later to set up our redirects.

Domain validation is why you have private or self-signed certificates and authorities. Sometimes you need an internal network that can't have public attestation. Sometimes, you want to a certificate for a domain you don't own. .internal is a top-level domain that is reserved for internal usage. No one can own one. When creating something such as Amaelia.internal, no public certificate authority will be able to issue me that certificate. It doesn't exist. Public DNS providers won't have any records. I need to have a self-signed certificate.

At this point you should have some basic understanding of what DNS records, reverse proxies, and SSL certificates do and how they interact.

At its simplest: DNS records tell you what public network of computers to connect to. Reverse proxies in that network tell you what server is actually running the service you are trying to connect to, and SSL certificates give you the trust to encrypt and share your data with that service. Your data remains hidden from all intermediate devices and attackers.

Now... Lets actually get started with this

*Side tangent - if you ever see payment / login / messaging services talking about "military-grade AES-256 bit encryption" or similar, or see VPN services talking about how they totally 100% prevent your ISP / router from seeing what you are sending your friend Stacy and they would if they didn't, please mock them. They are just using technical jargon marketing and very very very technically correct scare tactics respectively to try and convince you they are doing more than just the bare minimum for industry standards. Transport security & privacy are fairly standardized at this point, and methodologies that matter are forward looking on how to stop the various services from correlating your action to your identity... something that is not in most of their interests...

What are we even doing?

This tutorial can be used for just setting up your own local domains like Amaelia.home homelab.internal or even use public TLDs like Ameliashomelab.com. However, with a little bit of spit and some poor usability practices, we can even start redirecting public services to our local infrastructure.

For this example, I want to make it so every time I click a Reddit link, I get taken to my selfhosted instance of Redlib

Side tangent 2 - I cannot stand companies experimenting with their UX experiences. Very rarely have I seen an update come in where I have been like... Oh, this is experience is unfamiliar or different from previous ones... I like that! I get that you don't care and are just trying to find what statistically will give you the most user retention, but dear god, let me just use your service in piece.

For this redirect, I do not want to use extensions. I use a mix of browsers, and for all my browsers, all storage data is deleted when I close the browser. This would make it difficult to use something like LibRedirect, as I would need to reset my settings each time I restarted the browser. I also wanted to make it something that I could force onto all clients on my network without needing them to setup a browser extension.

Insert, . ݁₊ ⊹ . ݁˖ . ݁ DNS rewrites . ݁₊ ⊹ . ݁˖ . ݁ - since I run a local DNS server through Adguard Home, I can perform a Man-In-The-Middle (MITM) attack by

1. Capturing the outgoing DNS request for reddit.com before it gets resolved by a public DNS server (MITM)
2. Return my personal DNS results to the client and connecting it to my reverse proxy (DNS Spoofing)
3. Having the reverse proxy tunnel that traffic to my private service, while still showing the domain reddit.com
4. Have my reverse proxy provide a trusted certificate, allowing me to have encrypted traffic between my device and my server.

DNS redirects are not a perfect solution. Most apps rely on network requests to Reddit and expect a result in a specific format. This is why I only use redirects on devices that I am comfortable using the web experience on. For me, that is all of them.

However, this is not an issue if you are using self-signed certificates to stand up applications natively.

Instructions

Step 0 - Run your Redlib, Nginx Proxy Manager, Adguard Home and OpnSense services.

I am not going to walk you through how to set up each one - there are a variety of options, and ultimately it comes down to your particular setup.

Here is what I did:

• OpnSense is installed a MiniPC
• Adguard Home is running as a plugin on OpnSense
• Nginx Proxy Manager is running on a TrueNas Scale instance via their official apps section.
• Redlib is also running on TrueNas Scale using a docker-compose.yaml file in their custom apps section.

Step 1 - Making a Certificate Authority & Intermediate Authority:

This is basically a rewrite of the [OpnSense Docs](https://docs.opnsense.org/manual/how-tos/self-signed-chain.html), but tailored to DNS rewriting an exisiting service for your own purpose

Navigate to System -> Trust -> Authorities and hit the + icon to create a new root authority

Save, then hit + again and create an intermediate authority

Return to the System -> Trust -> Authorities page and download the certificates for your root CA and intermediate CA.

Step 2 - Making a certificate for your front-end:

Navigate to System -> Trust -> Certificates and hit the + icon to create a new root authority

After that has been made - return to System -> Trust -> Certificates and download your certificate and key.

Step 3 - Setting up Nginx Proxy Manager

Head over to NGINX and open up SSL Certificates. Here you will click Add SSL Certificate, then create a custom certificate.

Upload your certificate, key, and the intermediate certificate key. Name it something descriptive so you can remember what it is later.

Once that is uploaded, head over to Hosts -> Proxy Hosts and stand up a new proxy host pointing at your selfhosted service.

Read note above for wildcard information - you will replace the domain names just as you did up there

Step 4 - Setting up Adguard Home Rewrites

Navigate to Filters -> Custom Filtering Rules and paste in the following:
||reddit.com^$dnsrewrite=NOERROR;CNAME;{REVERSE_PROXY_IP_HERE},ctag=~device_other

If you are not rewriting an existing domain and are setting up a new internal domain, it would look like this

||*.amaelia.internal^$dnsrewrite=NOERROR;A;{REVERSE_PROXY_IP_HERE},ctag=~device_other

To break it apart:
|| = start of the (sub)domain
^ = end of the domain
$ = everything after this is a modifier
dnsrewrite=NOERROR;A;{REVERSE_PROXY_IP_HERE} Calls the DNS rewrite rule, tells it to return the NOERROR Code, to return an A record of your reverse proxy's IP address
, = new rule
ctag=~device_other = Making the rule apply for all clients on the network except those explicitly marked with device_other. ~ is the exclusion modifier

To set up persistent clients, head over to Settings -> Client Settings and set up a persistent client. If you are not assigning static IPs to your devices, you can use their mac address to issues. Remember that this would create an exclusion to the rule above.

Step 5 - Setup your browsers

There are two ways to get your browsers to trust your domain.

Either

• You individually have each browser you use trust your certificate authority
• You have each browser trust your operating system certificate store.

I've done the latter, but it varies wildly based on your operating system and browser. If all else fails, you can simply import the certificate authority certificates into Chromium / Firefox in the Settings section - look up certificates, and then add in your Intermediate Certificate Authority and Root Certificate Authority.

Success! It works! Navigate to your browser and wonder at your private reddit.com or selfhosted service!

Conclusion

Congratulations! You have a working redirect! It's not perfect, but it works, and more importantly, you somewhat understand why! Enjoy free access to the products you love, all under your control.

Cheers
~ Amaelia