this post was submitted on 10 Nov 2023
1 points (100.0% liked)

Homelab

371 readers
3 users here now

Rules

founded 1 year ago
MODERATORS
communick@selfhosted.forum
rglullis
1
Let's Encrypt: public domain [-> CF proxy] -> pfSense -> HAProxy -> local domain (alien.top)
submitted 1 year ago by pproba@alien.top to c/homelab@selfhosted.forum
4 comments fedilink hide all child comments
 

Hi all, I'm currently running the following setup:

  • registered domain .com
  • Cloudflare
    • A record for dynamic homelab IP (updated via pfSense)
    • CNAME Alias entries for each service: ..com
  • pfSense
    • domain: .com
    • Let's Encrypt wildcard certificate for *..com via ACME plugin
    • HAProxy for mapping host names to services in my network and serving the LE certificate
    • DNS Resolver host overrides for each ..com entry for split DNS -> resolved to HAProxy

This has worked quite well for a couple of years now.
Clients (mostly me) see a Cloudflare certificate from outside the network (if CF proxy is active) or my own wildcard certificate from inside the network (or if CF proxy is disabled).

I'm currently preparing 3 new (virtualized) router/firewall installations in parallel: pfSense, OPNsense and Sophos.
Before I try to configure the new installations equally, I'd like to simplify my current setup. One small inconvenience is the number of places I have to add a new service to:

  • Cloudflare CNAME Alias (optional, only for public availability)
  • HAProxy backend (unavoidable)
  • HAProxy frontend ACLs
  • HAProxy frontend actions
  • DNS Resolver host override

I've thought about using a wildcard override in the local DNS resolver in order to route all my service hostnames to HAProxy instead of listing each entry separately.
However, if I did this, all local host names would also be resolved to the same IP address, which is obviously not what I want.

Therefore I thought about changing my local domain to either .home.arpa or .lan.
Then I could resolve all *..com requests to HAProxy without influencing the host name resolution for my local machines.

Now I've tried to read up on *.home.arpa and similar local domain names and came across many people saying that it's not possible to get a Let's Encrypt certificate if you're not using a 'real' domain. Now I'm unsure and I don't feel like I really know what I'm doing anymore.
Is my situation different or does this limitation really apply in my case?
Do you have any comments? Would my setup still work if I changed the local domain to .home.arpa? Is there an alternative way to simplify my setup that you can think of?

Thanks in advance!

​

TL/DR: can I use ACME to get a wildcard certificate for *..com which will be served by HAProxy, even if my local domain is not .com?

top 4 comments
sorted by: hot top controversial new old
[–] SomethingAboutUsers@alien.top 1 points 1 year ago (1 children)

You need to provide proof of ownership of a domain in order for letsencrypt to issue the cert which is done via either an HTTP challenge where the domain in question resolves to a real HTTP server that has the challenge data available on it, or a DNS challenge where letsencrypt can see a TXT challenge record put there for the job.

[–] pproba@alien.top 1 points 1 year ago (2 children)

I assume that I'm currently using the DNS challenge approach. The ACME plugin takes care of this by using my account information and API keys.

[–] SomethingAboutUsers@alien.top 1 points 1 year ago

[ Removed by Reddit ]

[–] savvykms@alien.top 1 points 1 year ago

The challenges are part of the ACME protocol for issuing DV certificates. DV certs are for validating control of a given domain. If you successfully get a .arpa cert that's trusted by everyone, particularly a wildcard cert, you could perform MITM attacks on untold numbers of networks. It's not likely to happen.

You'll probably.need to make your own CA cert, trust it on devices, and issue certificates from it (or a sub CA cert, which you'd then have to bundle with others). If you only do this with a handful of haproxy nodes, the server cert config shouldn't be too hard, but the trust store gets stupid to manage quickly. A lot of software requires its own config for this to work.

The way I handled this issue myself is to make an "internal" subdomain, e.g. "internal.domain.tld", you can then split names between your root zone and a sub zone; this allows issuance of letsencrypt or other dns01 acme issuers to work via DNS challenges. Also useful if you don't want to or cannot do split horizon DNS resolution - you can still make public facing DNS records with private IPs. The biggest risk here is that internal-only services' names can be exposed via certificate transparency logs (CT logs). If you use LE for both internal and external names, you also increase names per domain usage which could have an impact on quotas/API limits.

Good luck with whatever you choose