this post was submitted on 01 Dec 2023
62 points (100.0% liked)

Selfhosted

40382 readers
436 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS
 

Hi, I was looking at private CAs since I don't want to pay for a domain to use in my homelab.

What is everyone using for their private CA? I've been looking at plain OpenSSL with some automation scripts but would like more ideas. Also, if you have multiple reverse-proxy instances, how do you distribute domain-specific signed certificates to them? I'm not planning to use a wildcard, and would like to rotate certificates often.

Thanks!


Edit: thank you for everyone who commented! I would like to say that I recognise the technical difficulty in getting such a setup working compared to a simple certbot setup to Let's Encrypt, but it's a personal choice that I have made.

top 50 comments
sorted by: hot top controversial new old
[–] [email protected] 22 points 1 year ago (2 children)

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.

[–] [email protected] 2 points 1 year ago

From where I sit, not a lot of reason to do it. It’s a bigger pain to deal with your own CA than to just use LE.

[–] MigratingtoLemmy 2 points 11 months ago (1 children)

I realise that it is more work than using Let's Encrypt, but this is a personal choice I'm making to not use a public domain for my internal network. I also do not like the idea of tailscale having access to my domain names, but then again, I'm likely not going to use Tailscale at all.

[–] [email protected] 2 points 11 months ago

No judgement here. I think it’s a worthy goal just not one I am particularly interested in at this point. Maybe if the automation was a bit easier and the mobile device management was easier I might join you.

[–] [email protected] 14 points 1 year ago (2 children)

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.

[–] [email protected] 2 points 11 months ago* (last edited 11 months ago)

As someone who has done both I couldn't agree more.

I run Home Assistant and could just pay their subscription to get external access, which also supports development. But I'm a cheap Yorkshireman so I went with DuckDNS, Let's Encrypt, Nginx and all that jazz for a long time. I'm just trying to hook my home up to Google so I can talk to it, I don't wanna pay money!

I had so many bloody glitches! I'd have to sign things in on a weekly basis, Google lost access all the damn time and it was just a nuisance.

I have a rule for hobbies, I do it cheap for at least a few months to see if I lose interest. If I get a bit obsessive, it's worth spending money on the hobby.

So after a year or two of fucking around with Nginx and DuckDNS I found the cloudflare plugin, which worked for free for a while. It was night and day, everything remained connected!

It ultimately bugged out one day and I decided to just bite the bullet and buy a domain. It's a hobby I've invested enough time in that a few quid for a solution that just works is worth it.

I think I dropped £35 for 5 years (I forget, it might be a decade) of owning my own .com domain name, which cloudflare manages for me.

I now have to reconnect my Google home to my home assistant once every couple of months instead of every week.

I haven't missed the money, and I certainly haven't missed the fucking tinkering to get it to work.

[–] MigratingtoLemmy 1 points 11 months ago (1 children)

Thanks, I recognise the challenge in getting this working rather that simple relying on Let's Encrypt. A little bit of money is not the problem here though; I have made a personal choice to use a private, reserved domain for my internal network and simply do not want to use a public domain for it.

[–] [email protected] 2 points 11 months ago (1 children)

You don't have to make the public domain, well, public. You can not hook up any DNS records for it, so externally it won't resolve anywhere and just use internal DNS.

load more comments (1 replies)
[–] deepdive 12 points 1 year ago* (last edited 1 year ago) (2 children)

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 !

[–] NeoNachtwaechter 4 points 1 year ago (1 children)

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 !

I'm curious, what's the reason?

load more comments (1 replies)
[–] MigratingtoLemmy 1 points 11 months ago (1 children)

Thank you. Could you explain a bit more about your setup and the aspects I should be looking at? Specifically:

  • Certificate chain of trust: I assume you're talking about PKI infrastructure and using root CAs + Derivative CAs? If yes, then I must note that I'm not planning to run derivative CAs because it's just for my lab and I don't need that much of infrastructure.
  • I have yet to figure out the CRL part with OpenSSL, I'll have to read more about it. Thanks.
  • I do not know what X.509 extensions are and why I need them. Could you tell me more?
  • I'm also considering client certificates as an alternative to SSO, am I right in considering them this way? I will also have to think about what I could do what clients without a client certificate or my root CA's certificate in their certificate store (maybe run another instance which doesn't need all of the encryption and setup I'm doing and somehow redirect such clients there whilst logging their traffic?).

Thanks for the mention, I was looking at a script to automate certificate generation and revocation too.

Since we're talking about reverse-proxies, I'll mention that I plan to run an instance of HAProxy per podman pod so that I terminate my encrypted traffic inside the pod and exclusively route unencrypted traffic through local host inside the pod. I'm doing this because I do not want to see any unencrypted traffic in my network. Of course, this is some more overhead but I think this is doable. I got this idea from another post I made a while back. Of course, that means that every pod on my network (hosting an HAProxy instance) will be given a distinct subdomain, and I will be producing certificates for specific subdomains, instead of using a wildcard.

Thanks, I'll be sure to document my progress as I go.

[–] deepdive 2 points 11 months ago* (last edited 11 months ago) (1 children)

Certificate chain of trust: I assume you’re talking about PKI infrastructure and using root CAs + Derivative CAs? If yes, then I must note that I’m not planning to run derivative CAs because it’s just for my lab and I don’t need that much of infrastructure.

An intermediate CA could potentially be useful, but isn't really needed in self-signed CA. But in case you have to revoke your rootCA, you have to replace that certificate on all your devices, which can become a lot of hassle if you share that trusted root CA with family/friends. By having a intermediate CA and hiding your root CAs private key somewhere offline, you could take away that overheat by just revoking the intermediate CA and updating the server certificate with the newly signed Intermediate bundle and serving that new certificate through the proxy. (Hope that makes sense? :|)

I do not know what X.509 extensions are and why I need them. Could you tell me more?

This will probably give you some better explanation than I could :| I have everything written in a markdown file, and reading through my notes I remember I had to put some basic constraints TRUE in my certificates to make them work on my android root store ! Some are necessary to make your root CA work properly (like CA:True). Also if you want SAN certificates (multidomaine) you have to put them in your x509 extensions.

’m also considering client certificates as an alternative to SSO, am I right in considering them this way?

Ohhh, I don't know... I haven't installed or used any SSO service and thinking of MFA/SSO with authelia in the future ! My guess would be that those are 2 different technologies and could work together? Having self-signed CA with a 2FA could possible work in a homelab but I have no idea how because I haven't tested it out. But thinks to consider if you want clients certificates for your family/friends is to have a intermediate CA in case of revocation, you don't have to replace the certificate in their root store every time you sign a new Intermediate CA.

I’ll mention that I plan to run an instance of HAProxy per podman pod so that I terminate my encrypted traffic inside the pod and exclusively route unencrypted traffic through local host inside the pod.

I have no idea about HAProxy and podman and how they work to encrypt traffic. All my traffic passes through a wireguard tunnel to my docker containers/proxy which I consider safe enough? Listening to all my traffic with wireshark seamed to do exactly what I'm expecting but I'm not an expert :L So I cannot help you further on that topic. But I will keep your idea in my notes to see If there could be further improvement in my setup with HAProxy and podman compared to docker and traefik through wireguard tunnel.

Of course, that means that every pod on my network (hosting an HAProxy instance) will be given a distinct subdomain, and I will be producing certificates for specific subdomains, instead of using a wildcard.

Openssl SAN certificates are going to be a life/time saver in your setup ! One certificat with multidomian !


I'm just a hobby homelaber/tinkerer so take everything with caution and always double check with other sources ! :) Hope it helps !


Edit

Thinking of your use case I would personally create a rootCA and an intermediateCA + certificate bundle. Put the rootCA in the trusted store on all your devices and serve the intermediateCA/certificate bundle with your proxy of choice. Signing the certificate with SAN X.509 extension for all your domains. Save your rootCA's key somwhere offline to keep it save !

The links I gave you are very useful but every bit of information is a bit dispatched and you have to combine them by yourself, but it's a gold mine of information !

[–] MigratingtoLemmy 2 points 11 months ago (2 children)

Thank you for your comment. My apologies in replying so late.

After reading a bit more and thinking about my setup, I think I will run intermediate CAs. Specifically, because I want to set up an ad-hoc mTLS setup, I might keep intermediate CAs for different classes of devices/different purposes. I will need to delve deeper into it, but for now, I think I have a grasp on the idea I need to implement, in which case, intermediate CAs will likely be a better idea. Thank you.

Thanks for the material, it would seem that I have a lot of reading left to do :)

load more comments (2 replies)
[–] MTK 8 points 1 year ago* (last edited 1 year ago) (1 children)

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.

[–] MigratingtoLemmy 2 points 11 months ago

I would not like to use a public domain for my internal traffic, even if the traffic is not routed outside. This is more of a personal choice than me looking for the easiest technical solution. I do own a domain, but I'll keep that specifically for elements facing the internet.

Thanks!

[–] TCB13 6 points 1 year ago (1 children)

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.

[–] MigratingtoLemmy 2 points 11 months ago (1 children)

Thanks, could you tell me why one would run this over plain OpenSSL with automation? Also, what risks would I run running a private CA? I'd love to know!

[–] TCB13 2 points 11 months ago* (last edited 11 months ago) (1 children)

could you tell me why one would run this over plain OpenSSL with automation?

Those projects essentially are the automation...

what risks would I run running a private CA? I’d love to know!

https://security.stackexchange.com/questions/205174/what-are-the-risks-of-installing-a-ca-on-the-same-machine-as-openvpn-server

More or less you're adding a root certificate to your systems that will effectively accept any certificate issues with your CA's key. If your PK gets stolen somehow and you don't notice it, someone might be issuing certificates that are valid for those machines. Also real CA's also have ways to revoke certificates that are checked by browsers (OCSP and CRLs), they may employ other techniques such as cross signing and chains of trust. All those make it so a compromised certificate is revoked and not trusted by anyone after the fact.

[–] MigratingtoLemmy 1 points 11 months ago (6 children)

I do realise the security problem in keeping the private key safe. I plan to use a VM with encrypted storage underneath. Do you think that's OK for a homelab, or should I invest time into integrating HSM modules from Nitrokey?

load more comments (6 replies)
[–] [email protected] 6 points 1 year ago (1 children)

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.

[–] deepdive 2 points 1 year ago (1 children)

Step CA is really nice if you want to learn more about how a real CA works. Had some fun playing with it but yeah it's a bit overkill for home lab xD.

You can achieve the same result with openssl with less complexity !

[–] MigratingtoLemmy 1 points 11 months ago

Thanks, I have been recommended Step-CA a few times under this post, I'll take a look!

[–] vegetaaaaaaa 6 points 11 months ago* (last edited 11 months ago) (1 children)

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.

[–] MigratingtoLemmy 1 points 11 months ago (2 children)

Finally got around to replying to the comments I got haha!

Thanks for the explanation. I'm curious why you're not running your own CA since that seems to be a more seamless process than having to deal with ugly SSL errors for every website, every time you rotate the certificate.

I'm wondering about different the process is between running an ACME server and another daemon/process like certbot to pull certificates from it, vs writing an ansible playbook/simple shell script to automate the rotation of server certificates.

About my clients: I am likely never going to purchase Apple products since I recognise how much they lock down their device. Unfortunately, there are not that many android devices in the US with custom ROM support. With that said, I do plan to root all of my Android devices when KernelSU matures (in about a year, I think) - I'm currently reading up on how to insert a root and client certificate into Android's certificate store, but I think it's definitely possible. Other than that, I might have a throwaway Windows VM sometimes, which is doable, alongside a Void linux box with a Debian chroot. All in all, fairly doable, just a bit of work to automate.

Thanks!

load more comments (2 replies)
[–] akash_rawal 4 points 1 year ago (1 children)

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.

[–] MigratingtoLemmy 1 points 11 months ago (1 children)

I would be very interested in your setup. Could you give me a high-level overview of how your setup works?

I'd also like a link to your automation/configuration if you would. Thanks!

[–] akash_rawal 4 points 11 months ago (1 children)

I just uploaded to Github: https://github.com/akashrawal/nsd4k

I only made it for myself, so expect very rough edges in there.

load more comments (1 replies)
[–] TechAdmin 3 points 11 months ago (1 children)

Self-host your own ACME server. Then you can use certbot pointed there.

These instructions are old so not sure if newer/better ways, https://blog.sean-wright.com/self-host-acme-server/

load more comments (1 replies)
[–] [email protected] 3 points 11 months ago* (last edited 11 months ago) (1 children)

I run easy-rsa on a linux box. Just manually generate CSR's and sign them via SSH.

And simply trust the CA cert in windows, linux and whatever extra places (normally firefox cert store).

Post the crl.pem to /var/www/html/ and let NGINX use that.

For most things public like plex or whatever i just use letsencrypt. Easy-rsa is really just for internal stuff like my NAS, VPN etc.

[–] MigratingtoLemmy 1 points 11 months ago (1 children)

Just manually generate CSR’s and sign them via SSH.

Could you tell me what you mean by "signing with SSH"?

load more comments (1 replies)
[–] [email protected] 2 points 11 months ago

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

[–] [email protected] 2 points 1 year ago (1 children)

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.

[–] MigratingtoLemmy 1 points 11 months ago (1 children)

I'd be very interested to hear your reasoning behind using a private CA for clients but using Let's encrypt for servers. Thanks for the explanation on the OpenSSL setup!

[–] [email protected] 2 points 11 months ago (1 children)

I'm just doing mutual TLS to authenticate clients which I use the pricate CA for.
I could use the orivate CA for the server instead of lets encrypt and trust that on devices, but letsencrypt is easy enough and useful for other things that I open publicly. mTLS avoids needing a vpn for more sensitive services

[–] MigratingtoLemmy 2 points 11 months ago* (last edited 11 months ago) (1 children)

Did you design your lab infrastructure to operate in a zero trust security framework? I'm very interested; I never really grasped mTLS, but I'm going to try and read more about it. Thanks!

Edit: Alright, I understand the high-level concept of mTLS. Just need to check the implementation details with my reverse-proxy

[–] [email protected] 2 points 11 months ago (1 children)

Not really, although now that I have certs for those anyway, maybe I should.
More like I'm using some services on the go that I want to always work, whether I'm on the LAN or on the go.
Opening home automation or 3d printers to the Internet is unwise to say the least.
mTLS in the reverse proxy for those allows me to have more security without having to establish a VPN first.

[–] MigratingtoLemmy 2 points 11 months ago (1 children)

Oh, that's a great idea! Indeed, using certificates to identify yourself would work quite well in such a scenario. Whilst I would always use a VPN server, this has given me something new to think about! Thanks!

[–] [email protected] 2 points 11 months ago (1 children)

What's nice is it provides a similar level of protection to using a VPN with PKI, but just for that specific subdomain. While a VPN would be have to be connected manually before use (or all the time), this is built-in.

The odds of someone breaking through the mTLS and breaking through that application's security at the same time are much smaller than either separately.
If you don't have a valid cert, you're dropped by the reverse proxy before anything even gets passed to the server behind it.

I'm a big fan of it.

[–] MigratingtoLemmy 2 points 11 months ago

I'll take a look, thanks!

[–] [email protected] 1 points 1 year ago (1 children)

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.

[–] MigratingtoLemmy 1 points 11 months ago

It's just a personal feeling really, I feel better having them being rotated. Of course, when it comes to rotating client certificates, I might have to think long and hard about the pain I'm about to inflict on myself.

I'll take a look at MCS, although I'd prefer not having to trust Microsoft on things critical to my lab

load more comments
view more: next ›