Earlier quoted context omitted.
Because hostname.tail62bc83.ts.net is a mouthful.
You can change it to something a tiny bit nicer a few times!
Oh! I did not know it was changeable. That’s useful!
TLS certificates for internal services done right
131–140 of 177 posts
Re: TLS certificates for internal services done right
#132Earlier quoted context omitted.
I never understood the issue with DNS-01. if you have a process that you trust to maintain a zone's TLS identity what is the big deal about letting it control a record in that zone?
You can even put it in a seperate zone (which I do) by using a CNAME for _acme-challenge.domain.tld. I have it to a seperate subdomain, which is served by a seperate desec.io account, which is only used for this specific subdomain.
TIL, thanks! This makes dns challange automation more approachable for me. I always had an issue with API keys which scope can't be limited to TXT records. This seems to be a nice workaround
... and it is even already documented at https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo...
Re: TLS certificates for internal services done right
#133Earlier quoted context omitted.
That's for the cert part, yeah, got it. I thought you have a solution to overcome not having to do split DNS where I define public IP in public DNS and internal IP within some local hosted DNS. Like how to make so that when connecting from inside local network the router recognize that by connecting to public IP, he has to route it back onto some local IP address?
Hairpin NAT (or "NAT hairpinning") is the term for "...connecting from inside local network the router recognize that by connecting to public IP, he has to route it back onto some local IP address", and the Linux NAT implementation supports it. For a homelab situation split-horizon DNS is just fine. You're going to have minimal duplication of records from the public DNS into the private DNS. The canonical frustrating…
Okay, thanks. I thought split-DNS is a hack even at home.
Totally agree on the AD part - luckily we had an option to migrate to different domain and name our AD correctly :)
Re: TLS certificates for internal services done right
#134Earlier quoted context omitted.
I never understood the issue with DNS-01. if you have a process that you trust to maintain a zone's TLS identity what is the big deal about letting it control a record in that zone?
We have a few subdomains for white labeling 3rd party SaaS where we do what is basically the AWS ACM equivalent and add a persistent record from a vendor. With this setup, I don't have to grant 3rd parties DNS access. I actually made a webhook that allows per hostname API keys to wrap dnsimple because they only had per zone keys and I didn't want each VM to have access to the entire zone. These challenges would have…
Our current level of granularity allows you to give read or write access to a specific zone, but it does not go down to the level of giving read or write access to a specific RRset type yet, if that's what you're looking for.
Re: TLS certificates for internal services done right
#135Earlier quoted context omitted.
Came here to say the same. I use DNS-Challenge rather than HTTP-challenge, and that makes internal servers trivial. You need a DNS provider which supports API calls (I use DNSimple) but the core is all very straightforward. To prevent having to include DNSimple authentication on the client's internal server I have a small API server on the web which does the Acme work.
> You need a DNS provider which supports API calls (I use DNSimple) but the core is all very straightforward. Library/CLI that speaks the API of several dozen DNS providers so you don't have to re-invent the wheel: * https://github.com/dns-lexicon/dns-lexicon
Interesting, this is the first time I've seen this project. One thing I saw that concerns me a bit is that they provide command-line options for passing your user credentials and multi-factor code. I'm not a fan of giving anything that level of access when a resource-specific access token will do, but that's me.
Re: TLS certificates for internal services done right
#136OP, why mess with acme.sh's cron schedule with your own cron job that calls its cron job? You might instead consider running acme.sh again with the "--install-cert" flag, coupled with its "--reloadcmd" flag, in order to automatically have it do the cert+key copying and nginx reloading for you when it renews:
acme.sh --install-cert -d grafana.tuxnet.dev --key-file /etc/ssl/private/grafana.tuxnet.dev.key --fullchain-file /etc/ssl/certs/grafana.tuxnet.dev.crt --reloadcmd "systemctl reload nginx"
Then you can ditch your custom cron and let acme handle everything on its own, as intended.
Re: TLS certificates for internal services done right
#137Earlier quoted context omitted.
> He’s using it as a subdomain. Lots of folks were using "dev" as a sub-domain which was fine until ICANN decide to give Google a TLD: * https://en.wikipedia.org/wiki/.dev So if you generally had "search example.com" in you resolv.conf , and were in the habit of having "web01.dev" in places, behaviour may have changed if you were suddenly on a machine that had the "search" line missing (or something else).
What you describe is a user and resolver configuration problem. There are 100's of TLDs and there's always a chance they will conflict with subdomains, either now or in the future as new TLDs are created. I've been using both "int" and "dev" as subdomains since at least 2000 and never had an issue.
> What you describe is a user and resolver configuration problem.
That won't prevent me from getting a ticket saying "the network is down".
Re: TLS certificates for internal services done right
#138Earlier quoted context omitted.
What you describe is a user and resolver configuration problem. There are 100's of TLDs and there's always a chance they will conflict with subdomains, either now or in the future as new TLDs are created. I've been using both "int" and "dev" as subdomains since at least 2000 and never had an issue.
> What you describe is a user and resolver configuration problem. That won't prevent me from getting a ticket saying "the network is down".
Okay, I guess the only solution is to always use FQDNs.
Re: TLS certificates for internal services done right
#139Earlier quoted context omitted.
Fair, but what about names that are specific enough to give an attacker a clue to a potential attack surface, like "authelia.example.com" - now they know you've likely got an Authelia setup, and can start digging for exploitable CVEs etc. I'm in the process of removing all my individual certs and replacing with a wildcard cert served by Traefik. Is that a bad idea?
How many people out there have attackers doing individualized research to identify services on their home LAN so they can chain a network attack with CVEs in their self-hosted service?
Everyone, now that you can just toss the work at an LLM.
Re: TLS certificates for internal services done right
#140Earlier quoted context omitted.
How many people out there have attackers doing individualized research to identify services on their home LAN so they can chain a network attack with CVEs in their self-hosted service?
Everyone, now that you can just toss the work at an LLM.
Where are you seeing this? LLMs make it easier to do bulk data analysis / scale attack patterns, but I've not seen anything to suggest they're incentivizing people to do OSINT against random individuals to fire off targeted attacks on home LANs.
The juice isn't really worth the squeeze for the token spend any more than it was worth the human energy.