Live data from Hacker News

Ask HN: What's your solution for SSL on internal servers?

news.ycombinator.com

31–40 of 79 posts

Re: Ask HN: What's your solution for SSL on internal servers?

#31
post #7

Earlier quoted context omitted.

It appears to me the issue is browser warning dialogs that imply it is always very dangerous. There should be either more context explained in those dialogs or a recognition of/mode for sites that are supposed to be self signed.

(Untested idea) I'd suggest creating your own Root CA with an expire-date far in the future. Install it's public key as a trusted certificate and all derived certificates should not prompt any issues anymore

That's not untested insofar as that's how I've always seen self-signed certs managed in an org.

Re: Ask HN: What's your solution for SSL on internal servers?

#32
post #15

I'm using subdomains on a domain I own and request Let's Encrypt certificates with the DNS challenge.

Just beware that the records of the TLS certs are public. So you'll leak a some hostnames. This might or might not be ok.

not if you use wildcard domain in the cert. LE already support wildcard certs

Re: Ask HN: What's your solution for SSL on internal servers?

#33
post #7

Earlier quoted context omitted.

It appears to me the issue is browser warning dialogs that imply it is always very dangerous. There should be either more context explained in those dialogs or a recognition of/mode for sites that are supposed to be self signed.

(Untested idea) I'd suggest creating your own Root CA with an expire-date far in the future. Install it's public key as a trusted certificate and all derived certificates should not prompt any issues anymore

Please don't. I've been in orgs doing this and it sucks. There seems to just be to many edge cases, and to many custom scripts for setup.

Re: Ask HN: What's your solution for SSL on internal servers?

#35
post #3

Personally I avoid it where I can and use wireguard for all internal traffic. Hopefully someone more knowledgeable here can tell me if it's a good or bad idea.

Same here, Tailscale and their DNS LetsEncrypt service does all the HTTPS management for me. Works just fine really.

Re: Ask HN: What's your solution for SSL on internal servers?

#37
I have one main Nginx server that all other services are behind, regardless if they're internal or external. This box is where NAT port forwards 80,443 to.

I also use only subdomains of the domains I own, even for internal stuff. This means I also run a small bind9 DNS server with minimal zones to direct traffic to the proxy inside the network, and most of the records just don't exist outside, ie. they return NXDOMAIN from my public DNS provider.

On the nginx box, I have a snippet like this:

    deny all;
    allow 10.x.0.0/16;
Then, when I configure something as 'internal only' I just add this line to its config file:

    include /etc/nginx/private.conf
This means that I can decouple the certificate status from the internal/external status of the site. All sites get valid certs, and most of them get 401's from outside the network.

In reality, I manage the nginx config with ansible templates, so what I really do is set a boolean "public" flag to "true" on sites I want accessible outside, everything else is private by default.

Re: Ask HN: What's your solution for SSL on internal servers?

#38

Earlier quoted context omitted.

I thought Let's Encrypt wouldn't give you a cert if the domain on the cert resolves to a private IP. Good to know - thx.

You just resolve the domain to a private IP on your internal network, Let's Encrypt can see it as whatever you want, for all they care it's 1.1.1.1.

Friendly reminder that 1.1.1.1 is a real, valid, public IP. Seen plenty of networks that don’t recognize this, use it for some internal purpose, and break https://1.1.1.1/

Re: Ask HN: What's your solution for SSL on internal servers?

#40
post #15

Earlier quoted context omitted.

Just beware that the records of the TLS certs are public. So you'll leak a some hostnames. This might or might not be ok.

not if you use wildcard domain in the cert. LE already support wildcard certs

That's not really ideal either...one copy of the cert that isn't protected well becomes a master key of sorts for someone already inside your internal network.
Post reply on HN