My experience is it’s really a lot of work and with the prevalence of letsencrypt, there is not a lot of automated setups for this use case (at least that I have been able to find). It is kind of a pain in the ass to run your own CA, especially if you plan to not use wildcard and to rotate certs often. If you use tailscale, they offer https certs with a subdomain given to you:

[server-name].[tailnet-name].ts.net

That’s honestly what I’m moving towards.

If you want to run your own pki with self-signed certificate in your homelab I really encourage you to read through this tutorial. There is a lot to process and read and it will take you some time to set everything up and understand every terminology but after that:

• Own self-signed certificate with SAN wildcards (https://*.home.lab)
• Certificate chain of trust
• CSR with your own configuration
• CRL and certificate revocation
• X509 extensions

After everything is in place, you can write your own script that revoks, write and generates your certificate, but that is another story !

Put everything behind your reverse proxy of choice (traefik in my case) and serve all your docker services with your own self-signed wildcard certificates ! It’s complex but if you have spare time and are willing to learn something new, it’s worth the effort !

Keep in mind to never expose such certificates on the wild wild west ! Keep those certificate in a closed homelab you access through a secure tunnel on your LAN !

edit

Always take notes, to keep track of what you did and how you solved some issues and always make some visuals to have a better understanding on how things work !

I’d just buy a single domain, it’s like £5 a year and use a letsencrypt wildcard and have it auto renew via DNS challenges. Very easy. You can do what you’re doing with letsencrypt, but you’ll have to set up HTTP challenges for each sub domain, or DNS challenges for each sub domain. Obviously doable, but more work.

Doing it without letsencrypt and just doing it privately? I dunno if I’d bother with that, firstly you’ll have to go through the hassle of making sure any browser and computer that connects to it has the root cert of the private CA, or you’ll get self signed errors, which is a faff. I’d honestly just pay the £5 or so a year, you’ll spend more time (and time is ultimately money) doing it without it.

I’m using step-ca. Its running on dedicated SBC. ACME certs created for each service renewing automatically daily. Honestly this setup wouldn’t be worth it if it wasn’t for daily cert rotation. I’m not using wildcard certs with own CA as it’s bad practice and defeats the purpose. There are bunch of different ACME renewal scripts/services. K8s cert manager handling kubernetes services automatically. Opensense has ACME cert plugin, nginx proxy manager is using external cert managed by script. I’m validating certs with DNS using TSIG. Step-ca have several integrations with different DNS services. I chose TSIG because it’s universal. There is pi-hole integration if you using that. Buying valid domain is not needed as long as you have internal DNS. You need to Install root Ca on every machine that will be connecting to services. If you have many VM’s configuration management is the way to go.

Use something like no-ip, you can get a domain for free and renewing it every 30 days with a few clicks is much easier then managing a CA.

The only downside is the TLD but if you don’t care to much about how your domain name looks it really is the best option.

I use no-ip with letsencrypt, the LE bot does the certificate stuff for me, I use a single domain with different ports for each service and no-ip sends an email every 30 days to reconfirm the domain. Simple and easy.

Written in go, very small and portable: https://github.com/FiloSottile/mkcert. There’s also step-ca, bigger and uses ACME to deploy certificates, never used it tho.

Just be awake of the risks involved with running your own CA.

I don’t at the moment, because I don’t have a need for it, but I did for a while run a PoC with Step CA, and that seems like the easiest way to get up and running, even if its features are overkill for a home lab.

I run a crude automation on top of OpenSSL CA. It checks for certain labels attached to kubernetes services. Based on that it creates kubernetes secrets containing the generated certificates.

I’m not using a private CA for my internal services, just plain self-signed certs. But if I had to, I would probably go as simple as possible in the first time: generate the CA cert using ansible, use ansible to automate signing of all my certs by the CA cert. The openssl_* modules make this easy enough. This is not very different from my current self-signed setup, the benefit is that I’d only have to trust a single CA certificate/bypass a single certificate warning, instead of getting a warning for every single certificate/domain.

If I wanted to rotate certificates frequently, I’d look into setting up an ACME server like [1], and point mod_md or certbot to it, instead of the default letsencrypt endpoint.

This still does not solve the problem of how to get your clients to trust your private CA. There are dozens of different mechanisms to get a certificate into the trust store. On Linux machines this is easy enough (add the CA cert to /usr/local/share/ca-certificates/*.crt, run update-ca-certificates), but other operating systems use different methods (ever tried adding a custom CA cert on Android? it’s painful. Do other OS even allow it?). Then some apps (Web browsers for example) use their own CA cert store, which is different from the OS… What about clients you don’t have admin access to? etc.

So for simplicity’s sake, if I really wanted valid certs for my internal services, I’d use subdomains of an actual, purchased (more like renting…) domain name (e.g. service-name.internal.example.org), and get the certs from Let’s Encrypt (using DNS challenge, or HTTP challenge on a public-facing server and sync the certificates to the actual servers that needs them). It’s not ideal, but still better than the certificate racket system we had before Let’s Encrypt.

deleted by creator

Why bother with certificate rotation in a homelab environment? You could issue certificates for three years and just call it a day.

Personally, I have experience with Microsoft Certificate Services, which works pretty well out of the box and is also quite well supported. But you need a Windows Server for it.

I run a private CA for client SSL.
For traditional server SSL I just use let’s encrypt, although I already have the domain (less than $10 a year) for my public facing stuff, and just use a subdomain of that one for my homelab.

I have a container with openssl for the private CA and generating user certs as well as renewing the let’s encrypt ones. I just use openssl without anything fancy.
The output folder is only mounted rw in that one container
I only ever mount the subfolders in read-only in other containers that need those certs.
All these containers are running on the same server so I don’t even have to copy anything around, the containers don’t even need connectivity between them, it’s just mounted where needed.

I do have Vault PKI set up but I don’t use it that much. It’s only if I want to do mTLS with something.

For almost all of my actual services, I use a wildcard cert that covers something like *.int.example.com. I use acme.sh to create and renew the cert then have a python script that copies it to any vms or services that need it

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

[Thread #324 for this sub, first seen 1st Dec 2023, 23:25] [FAQ] [Full list] [Contact] [Source code]