[mnahkies]

Personally I think wildcard certs are more secure in many instances - if you're just running one load balancer/reverse proxy then all the private keys are going to the same place anyway. You get the upside of not leaking your subdomains to transparency logs, and having fewer certs to renew.

It also forces you to use DNS challenges, which means you don't require the publicly route able address.

Personally what I do is: - Predominantly use wildcards

- Run a tiny coredns instance with my A records for a internal subdomain of my normal domain

- Configure tailscale to use the coredns resolver

- Run two haproxy instances, one for internal services, one for public facing. The public facing one can't route directly to the internal services.

When even the obscure DNS provider I'm using is supported for DNS challenges, I really don't see much upside to using HTTP challenges anymore

[waynesonfire]

> - Run two haproxy instances,

This made me consider my haproxy architecture. I use haproxy acl rules and the use_backend directive to enforce security policy and routing. It denies http requests based on source ip address per service (host header)

I think a good middle-ground is to use a single haproxy but two frontends; one binds to the public interface and one for private. haproxy is now no longer responsible for routing, the router is.

[mnahkies]

Yeah you could run a single instance with multiple frontends - but the way I'm currently running things the public haproxy instance doesn't have network connectivity to the private services, meaning there is no way I can misconfigure things and expose an internal service to the internet.