Do you want to create your own certs? You can use let's encrypt certs on internal only local subdomains using DNS challenge.
I do this with traefik and authentik and use SSO for both internal and external domains.
this post was submitted on 23 Jan 2024
25 points (100.0% liked)
Selfhosted
39640 readers
286 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:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
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.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 1 year ago
MODERATORS
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.
CA.pl script
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/ :)
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
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).
For basic dev-level purposes, CA.pl works and has been around forever, though I’m sure there is better stuff out there.
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:
| Fewer Letters | More Letters |
|---|---|
| CA | (SSL) Certificate Authority |
| DNS | Domain Name Service/System |
| SSL | Secure Sockets Layer, for transparent encryption |
| SSO | Single Sign-On |
| VPN | Virtual Private Network |
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]