How to properly setup local certificate authorities for sub domains?
Hello everyone,
A bit of background on how things are configured: I have many local services and am in the process of setting up two local domains, namely local1.publick.com and local2.publick.com. I own the domain name publick.com and manage it through Cloudflare.
Local1 is for the Windows domain and is using Active Directory, while local2 is for the Linux domain and is using RHEL IDM.
Now, as I am also exploring Single Sign-On (SSO) with Keycloak and a few other things, I would like to properly set up SSL for all these subdomains. Can I configure two local certificate authorities? One for local1.public.com and another for local2.publick.com? I would then use these to create certificates for service.local1.publick.com and service.local2.publick.com. Since the AD domain controller and RHEL IDM controller are authoritative for these two domains, can I still integrate two CAs with this setup?
Do you want to create your own certs? You can use let's encrypt certs on internal only local subdomains using DNS challenge.
https://youtu.be/liV3c9m_OX8
I do this with traefik and authentik and use SSO for both internal and external domains.
I just get why one would go over 2343 different pieces of software, containers, portainer, integrations and whatnot when it is as simple as issuing the wildcard certificate for the domain on a public facing machine and then transferring it to the private network.
DNS challenge makes it even easier, since you don't have to go through the process of transferring it yourself
Still easier whats to setup that than what's described. Even the Certbot tool is able to setup it up with a simple command.
Certbot also does DNS challenge, fwiw
Maybe use DNS challenge? https://notthebe.ee/blog/easy-ssl-in-homelab-dns01/
I am already using this for publick services i have things jellyfin.publick.com domains. Which works fine for that usecase. What I am looking for here is to make SSL work properly for services that are part of the 2 local domains. where the 2 controllers are authoritative of those 2 domains.
Not sure if you use OPNSense, but the acme plugin allows you to automatically upload certificates (via ssh) to the appropriate servers whenever the certificates are updated.
One other way would be to use a reverse proxy internally (if you only need SSL for web interfaces).
Would that prevent you from using a DNS challenge?
Years (decades) ago it wasn't uncommon to create self-signed/local CAs for active directory, but it's really uncommon today since everything is internet facing and we have things like Let's Encrypt.
It's so old, the "What's New" article from Microsoft references Windows Server 2012 which is around when I stopped working on Windows Server. I kinda remember it, and you needing to add the server's cert to your trusted roots. (I don't know about Linux, but the concept is the same, I'm sure. I never tried generating certificates, but know all the other client -side stuff. Basically you need a way to fulfill CSRs.)
https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/
What you'd want to do it in Windows is all there, and Microsoft made that pretty easy back then to integrate with all their platforms and services, but I'd caution, do you really want to implement 10+ year old tech?
If you want a local CA for just a few low assurance certificates (say for a test stack), the CA.pl script in the openssl distro is simple and sort of usable. If you want to be more serious you sort of have to know what you are doing. If you just want people's browsers to accept your subdomains, use a wildcard certificate (*.whatever.com). LetsEncrypt issues those and Cloudflare also might.
NO. JUST NO. Fucks sake that thing is written in Perl. Instead use https://github.com/FiloSottile/mkcert OR https://github.com/smallstep/certificates
But yes, a wildcard is mostly way to go, less risks and more results.
You can also use certbot on the subdomain servers if they are on the Internet, to auto-renew individual subdomain certificates. To run a "real" CA you need a lot of opsec and infrastructure regardless of what software you use. For basic dev-level purposes, CA.pl works and has been around forever, though I'm sure there is better stuff out there.
Re perl, see also: https://xkcd.com/224/ :)
Yes, I agree with you and I always tell everyone to stay away from creating a CA. - it's just not worth it the workload and the risks. Either way certbot can be even used without exposing local servers to the internet with DNS challenges and other means of authentication. The wildcard has the advantage of not having to publish those subdomains publicly in some for (DNS) or another (crt.sh).
https://github.com/FiloSottile/mkcert is the way to go for that.
One of the keys to selecting the solution from the provided answers is if you need this to be publicly trusted.
I use an internal openssl ca root, created intermediate ca for each active directory domain or Forest. Also, I wanted to create internal PKI smart cards with yubikeys and his c1150 cards. For you know, fun.
I didn't care that other hosts don't trust my stuff because all my hosts are configured with root ca, and I only use VPN for access.
You want external trust, must do some of the other suggestions. Setting up internal CA is a chore with understanding AIA, CDP points, line of sight to PKI urls for renovation checking, more...
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
5 acronyms in this thread; the most compressed thread commented on today has 7 acronyms.
[Thread #447 for this sub, first seen 23rd Jan 2024, 10:05] [FAQ] [Full list] [Contact] [Source code]