to help with passive reconnaissance, here are tuxnet.dev's SSL certificates and associated subdomains: https://www.certkit.io/tools/ct-logs/?query=tuxnet.dev
¯\_(ツ)_/¯
Not quite done right.
TLS certificates for internal services done right
151–160 of 177 posts
Re: TLS certificates for internal services done right
#152Earlier quoted context omitted.
Once dns-persist-01 becomes available/usable[1], it should make dns validation even easier. [1]: https://letsencrypt.org/2026/02/18/dns-persist-01
At this point, can't we make a standard that skips the middlemen and just embeds the certificate directly inside the DNS entry? It seems the challenge system is converging towards that anyway.
That would be DANE with TLSA (RFC 6698, not the stock ticker symbol). You've still got just another chain of trust with the DNSSEC requirement, and the recent DENIC outage breaking that for the entirety of .de isn't the greatest advertisement :D
Re: TLS certificates for internal services done right
#153I am looking forward to finally using DNS-PERSIST-01 for validation. No more dynamic DNS updates, DNS credentials or forwarding necessary.
Sadly most tools still doesn't support it: https://github.com/cert-manager/cert-manager/issues/8373#iss... And then the issue is protecting the private key of the issuer and monitoring certificates (it's a good idea to do that anyway).
One of the draft authors is already working on a cert-manager implementation. I'm optimistic it'll make it into cert-manager once the spec is ready and CAs actually start to implement it.
Re: TLS certificates for internal services done right
#154Earlier quoted context omitted.
At this point, can't we make a standard that skips the middlemen and just embeds the certificate directly inside the DNS entry? It seems the challenge system is converging towards that anyway.
That would be DANE with TLSA (RFC 6698, not the stock ticker symbol). You've still got just another chain of trust with the DNSSEC requirement, and the recent DENIC outage breaking that for the entirety of .de isn't the greatest advertisement :D
It's also a dead letter: browsers won't implement it (they did at one point, and then withdrew it).
Re: TLS certificates for internal services done right
#155Personally 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…
> - 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…
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.
Re: TLS certificates for internal services done right
#156Earlier quoted context omitted.
I do the same thing. I'm not worried about them seeing my FQDNs. I use the form of hostname.int.example.com for everything inside my home network. None of which is accessible to the outside world. I use LetsEncrypt with DNS validation to get the certificates.
If you are going to have all the home stuff on a subdomain (int.example.com) would it work to delegate int.example.com to a DNS server running at home what has internet access, and could handle the ACME DNS challenges for machines on int.example.com? If it does then you don't have to mess with your public DNS whenever you want to add or renew certificates for home machines. I'm using the free DNS my registrar provide…
Yes, you're describing a fundemental feature of DNS.
Re: TLS certificates for internal services done right
#157Bogus nonsense. Sign your internal certs with an internal CA, make your clients trust the CA. Use it properly.
> "make your clients trust the CA"
There's no single trust store: the OS has one, Firefox, Java (cacerts), Python (certifi), Node, Go containers, all your Docker images, ...
Failure? People just toggle TLS verification off.
Easy to do in a one-man shop, but almost impossible in any big company. Try grepping for verify=False / -k / InsecureSkipVerify in any fortune 500 and you'll find plenty
Re: TLS certificates for internal services done right
#158Earlier quoted context omitted.
At this point, can't we make a standard that skips the middlemen and just embeds the certificate directly inside the DNS entry? It seems the challenge system is converging towards that anyway.
That would be DANE with TLSA (RFC 6698, not the stock ticker symbol). You've still got just another chain of trust with the DNSSEC requirement, and the recent DENIC outage breaking that for the entirety of .de isn't the greatest advertisement :D
Yes, which goes back to the old question: why the heck are we using a bunch of insecure systems with awkward bolted-on workarounds instead of just using DNSSEC?
Re: TLS certificates for internal services done right
#159Bogus nonsense. Sign your internal certs with an internal CA, make your clients trust the CA. Use it properly.
> "make your clients trust the CA" There's no single trust store: the OS has one, Firefox, Java (cacerts), Python (certifi), Node, Go containers, all your Docker images, ... Failure? People just toggle TLS verification off. Easy to do in a one-man shop, but almost impossible in any big company. Try grepping for verify=False / -k / InsecureSkipVerify in any fortune 500 and you'll find plenty
Yes, it feels like I echo the same sentiment at work every few weeks. No, we can’t tick the PR with verify=false. Yes, you have to configure the trust store. Yes, it’ll take maybe an hour to work this out. Go do so please.
The only reason is laziness.
Re: TLS certificates for internal services done right
#160Earlier quoted context omitted.
>Don't use split DNS So what's your solution when you have a wholly private service that will never have a public v4 address, nor a publicly routable v6? How do clients get the address for a nice domain name without the addresses in public DNS? I use acme.sh with DNS validation, and use common domains that have both public and private services on subdomains. I use split horizon so private.domain.example resolves only…
Wait…what? You have a fully internal service and you dont have an internal DNS server? I guess those exist in theory, but not in practice. :) If you have a heavy enough tech stack to run fully internal services, than you can also run an internal DNS service (even pihole is enough) and load internal only entries there. Or add everything to your hosts file if you have a central config service.
What, indeed. Yes, I have internal DNS servers. They are what handle the split horizons. How would one do split horizon without an internal DNS service?