Using a reserved TLD

Picking a domain

I made two decisions early on about my self-hosted environment:

Using a domain with a reserved TLD bypasses the need to purchase a specific domain for what will ultimately never be exposed to the internet.

Of the available set, .home seemed the most like what I was aiming for, though I ran into some instances that assumed one wouldn’t have an entire TLD to oneself. I believe the first instance of this I ran into was with smallstep/step-ca which wouldn’t generate a wildcard certificate for *.home, home.

While I ended up moving over to cfssl/cfssl which does support certs for *.home, I consider this a warning of sorts. Other services that I spin up might not play well with such short domains. Additionally, home.lan isn’t too arduous to type.

Generating the certs

cfssl’s documentation is pretty clear on the whole process. You’ll generate three configuration files and use those to instruct cfssl to generate your root cert/key and your wildcard cert/key. I ran this through Docker with the following:

docker run -it -v $PWD:/etc/cfssl --entrypoint /bin/bash cfssl/cfssl
cfssl gencert -initca root.json | cfssljson -bare ca
cfssl gencert -ca=root.crt -ca-key=root.key -config=config.json wildcard.json | cfssljson -bare wildcard

Certificate deployment

cfssl easily generates me a root certificate and a wildcard certificate, but I’m going to have to install the root certificate on all relevant devices. A few laptops, a few desktops, a few phones. This approach likely isn’t scalable for any businesses, but it’s honestly not too bad for a home environment. The root cert is good for 10 years.

Update from the future

This all being said, it shouldn’t come as a surprise that the “yes, I’m going to run on a reserved domain” decision has complications I didn’t foresee. Turns out that some devices cannot have a custom root certificate installed and they have need to talk to services that use my home.lan cert. I’ll cover the details of this in a later post.