Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TLS certificates for internal services done right

tuxnet.dev

Post reply on HN
Print view View original

91–100 of 177 posts

Re: TLS certificates for internal services done right

#91

Post by michaelt »

skywhopper wrote: post #61
boscillator wrote: post #19

The real answer here is that configuring HTTPS clients to trust a self-signed cert (or signed by an internal CA) shouldn't be as difficult as it is. I find it extremely annoying that every programming language has it's own idea of where certificates should live instead of just checking the os trust store.

Is there a commonly used language other than Java that doesn’t just defer to the OS trusted CAs by default?

The behaviour of curl depends on how your version was built.

Python? The widely used 'requests' relies on 'certifi' and skips the OS store - but 'pip' on the other hand does use the OS store.

A tool that might use java, like a database or IDE, means it might have its own store.

Node? Make sure you set NODE_USE_SYSTEM_CA=1

Firefox and Chrome AFAIK both have their own stores.

Building a Docker container? That's intentionally isolated from the host, of course your container won't inherit the OS trusted CAs. Running a VM locally? Same.

Installed something using snap? The container-like isolation means it won't pick up the OS trusted CAs.

And of course you need the certs set up right on your cloud servers, your CI servers, the dozen different smartphones the mobile team uses for testing.

Re: TLS certificates for internal services done right

#92

Post by WhyNotHugo »

greengreengrass wrote: post #65
boscillator wrote: post #19

The real answer here is that configuring HTTPS clients to trust a self-signed cert (or signed by an internal CA) shouldn't be as difficult as it is. I find it extremely annoying that every programming language has it's own idea of where certificates should live instead of just checking the os trust store.

Possibly a separate concern, but I have some degree of confidence that the requirements and oversight of the CA/B forum (or whomever else determines which root certs go into bundles) are sufficiently strict, and issuers kept under sufficient scrutiny, that I tend to trust those more than I trust myself to secure my own root CA keys adequately. The ideal would be for people setting up their own PKI to ensure their roo…

Personally, I use a custom local CA with name constraints so that it can only sign domains for The .internal TLD. This is the most important bit: because if the cert is ever leaked, it cannot be used to MITM connections to other domains.

I have to secure the CA's key, but I also have to secure all the keys for the certificate it signs, both being a similar level of challenge.

For personal use, or for very small organisations, using a passphrase-protected Yubikey as a "cheap HSM" should suffice.

Re: TLS certificates for internal services done right

#93

Post by WhyNotHugo »

afarah1 wrote: post #53
boscillator wrote: post #19

The real answer here is that configuring HTTPS clients to trust a self-signed cert (or signed by an internal CA) shouldn't be as difficult as it is. I find it extremely annoying that every programming language has it's own idea of where certificates should live instead of just checking the os trust store.

Even if all applications look at the OS trust store, in my experience there's always a gap distributing the CA to every consumer, leading to time spent on debugging from time to time... Maybe that's not the case in perfectly homogeneous or sufficiently small environments where every team uses the same infra / stack.

Yeah, adding CAs to the store sucks. On Linux it needs to be in /etc/ssl/certs (this varies slighly per distribution), which is only writable by root. A single user can't trivially trust a CA, and a great deal of applications/libraries don't support overriding the store's path.

Re: TLS certificates for internal services done right

#94

Post by tzs »

graton wrote: post #48
raffraffraff wrote: post #25

Hmm. I don't really care enough about leaking home network host names because they are all super generic names like 'router', 'laptop', 'tv', 'nas'. So I use my public zone on cloudflare. I just use internal ip addresses (eg: nas.example.com = 10.1.2.3) on the public zone and DNS01 challenge for let's encrypt. Anyone can resolve the ip for any of my hosts, but obviously you'd need to be on the wireguard vpn to hit th…

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 provides, which doesn't provide API access unless you upgrade to their paid DNS service and so if I could use a local DNS server for the ACME challenges for the home network I could pick one that is friendly to automation.

Re: TLS certificates for internal services done right

#95

Post by throw0101a »

graton wrote: post #48
raffraffraff wrote: post #25

Hmm. I don't really care enough about leaking home network host names because they are all super generic names like 'router', 'laptop', 'tv', 'nas'. So I use my public zone on cloudflare. I just use internal ip addresses (eg: nas.example.com = 10.1.2.3) on the public zone and DNS01 challenge for let's encrypt. Anyone can resolve the ip for any of my hosts, but obviously you'd need to be on the wireguard vpn to hit th…

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.

> I use the form of hostname.int.example.com […]

Note that int is a valid TLD:

* https://en.wikipedia.org/wiki/.int

* https://datatracker.ietf.org/doc/html/rfc1591

Re: TLS certificates for internal services done right

#96

Post by throw0101a »

WhyNotHugo wrote: post #92
greengreengrass wrote: post #65

Earlier quoted context omitted.

Possibly a separate concern, but I have some degree of confidence that the requirements and oversight of the CA/B forum (or whomever else determines which root certs go into bundles) are sufficiently strict, and issuers kept under sufficient scrutiny, that I tend to trust those more than I trust myself to secure my own root CA keys adequately. The ideal would be for people setting up their own PKI to ensure their roo…

Personally, I use a custom local CA with name constraints so that it can only sign domains for The .internal TLD. This is the most important bit: because if the cert is ever leaked, it cannot be used to MITM connections to other domains. I have to secure the CA's key, but I also have to secure all the keys for the certificate it signs, both being a similar level of challenge. For personal use, or for very small organ…

Yubi makes an 'actual' HSM product:

* https://www.yubico.com/products/hardware-security-module/

See also perhaps less expensive option:

* https://shop.nitrokey.com/shop/nkhs2-nitrokey-hsm-2-7

Re: TLS certificates for internal services done right

#97

Post by icedchai »

throw0101a wrote: post #95
graton wrote: post #48

Earlier 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.

> I use the form of hostname.int.example.com […] Note that int is a valid TLD: * https://en.wikipedia.org/wiki/.int * https://datatracker.ietf.org/doc/html/rfc1591

He’s using it as a subdomain.

Re: TLS certificates for internal services done right

#98

Post by Walf »

xurukefi wrote: post #67

Or... - Don't use split DNS. Don't use any special internal or dev domain. Leave it to your infrastructure to route/NAT those public IPs to your internal network. - Don't use the HTTP-01 challenge. Use DNS-01. - Don't run your own internal CA. Use Let's Encrypt. If you care about name leakage (CT Logs), use wildcard certs. Use a central reverse proxy/load balancer for termination.

>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 on LAN and VPN, and public.domain.example resolves everywhere, but the address changes depending on the network one is connected to.

Re: TLS certificates for internal services done right

#100

Post by iambvk »

Hamuko wrote: post #8

I use a registered domain with DNS validation and then CNAMEs that I resolve locally. Basically: 1. Register a domain ("server.com") and put it on some public DNS that can do DNS validation with acme.sh. 2. Use DNS validation to get a certificate on your domain from Let's Encrypt. You can just grab a wildcard one ("*.server.com"). 3. CNAME all of your services on a public DNS to an internal address ("email.server.com…

I like this approach. Thank you.

Would it work if a user's device that is already connected to the VPN, but has custom DNS override to say 8.8.8.8 ? How can I allow my users to be able to use 8.8.8.8 DNS override and still work seamlessly?

Post reply on HN