Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt
31–40 of 94 posts
Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt
#32Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt
#33Earlier quoted context omitted.
While you'll get the hostnames leaked - you could register them as fake addresses (say an A record for 192.168.0.1 for every address), and have a local DNS server overriding with the real addresses. Whether this is worthwhile or not is debatable. Is the fact your internal server 'gubbins.mydomain.com' exists, or even that it exists on 10.0.41.43 really much use? The other option for internal certificates is to get a…
> when you import a root certificate you can't typically allow that CA to only be used to authenticate a given subdomain. While, true, there are some workarounds, that are, ehm, workaroundy. 1. For _your_ domain, you can have CAA records in your DNS. (That solves it for your domains, not for others, if they do not use CAA) 2. Some CA implementations, like FreeIPA one, allow you to issue certificates only for your own…
This is especially problematic if I want someone else to trust my certs in their browser, I'm asking them to trust any certificate I generate, including google.com, mybank.com, etc.
Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt
#34TLDR: - have a proper worldwide domain - obtain a certificate for that domain - point the domain to local IPs in your network and use the certificate on the local server. Doesn't change that you'd need to self-sign certs for .local or other funky domains.
More controversially I think you should give things globally unique addresses from the Internet's global address system but it's more important to at least give them names from the globally unique system even if you insist on using RFC1918 numbers.
Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt
#35Earlier quoted context omitted.
While you'll get the hostnames leaked - you could register them as fake addresses (say an A record for 192.168.0.1 for every address), and have a local DNS server overriding with the real addresses. Whether this is worthwhile or not is debatable. Is the fact your internal server 'gubbins.mydomain.com' exists, or even that it exists on 10.0.41.43 really much use? The other option for internal certificates is to get a…
> Is the fact your internal server 'gubbins.mydomain.com' exists, or even that it exists on 10.0.41.43 really much use? Pretty much this. What does it matter if you know certain hostnames or internal IPs on my network? It's all firewalled anyway, and if it wasn't it would be trivial to find them out on your own...
"Hi it's Bob down in IT, any chance you could reboot 'funkyserver123', it's on 172.18.12.5, for some reason I can't get in"
Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt
#36Keep in mind, adding local entries to your external DNS will expose internal details of your network, such as hostnames and IPs. Same goes for Let's Encrypt, due to Certificate Transparency logging.
While you'll get the hostnames leaked - you could register them as fake addresses (say an A record for 192.168.0.1 for every address), and have a local DNS server overriding with the real addresses. Whether this is worthwhile or not is debatable. Is the fact your internal server 'gubbins.mydomain.com' exists, or even that it exists on 10.0.41.43 really much use? The other option for internal certificates is to get a…
You're probably aware of tools such as dnsdumpster (dnsdumpster.com) that attempt to map internal networks using dns. It is common to use descriptive prefixes (eg. intranet, gw, fw, dns, jira, mysqldb, etc) that also give some insight on the internal tools and topology. Using the CT logs you can also collect over time changes in network, for servers/endpoints with non-wildcard certificates.
Its not a huge risk. But why give a map of the place to a potential attacker, when - as you quite well proposed - you can use simple ways of avoiding it?
Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt
#37Keep in mind, adding local entries to your external DNS will expose internal details of your network, such as hostnames and IPs. Same goes for Let's Encrypt, due to Certificate Transparency logging.
Is that actually valuable information though? I mean internal IP addresses are fairly generic (like the 192.168.x range mentioned in the article).
Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt
#38Earlier quoted context omitted.
> Is the fact your internal server 'gubbins.mydomain.com' exists, or even that it exists on 10.0.41.43 really much use? Pretty much this. What does it matter if you know certain hostnames or internal IPs on my network? It's all firewalled anyway, and if it wasn't it would be trivial to find them out on your own...
I guess it could be useful for human level attacks, something like "Hi it's Bob down in IT, any chance you could reboot 'funkyserver123', it's on 172.18.12.5, for some reason I can't get in"
Edit: I don't know why this is being downvoted. The OP is about a home k8s setup, so unless you live in some castle or palace I very much doubt there will be a Bob down in IT.
Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt
#39Earlier quoted context omitted.
> when you import a root certificate you can't typically allow that CA to only be used to authenticate a given subdomain. While, true, there are some workarounds, that are, ehm, workaroundy. 1. For _your_ domain, you can have CAA records in your DNS. (That solves it for your domains, not for others, if they do not use CAA) 2. Some CA implementations, like FreeIPA one, allow you to issue certificates only for your own…
I'm thinking more that if you create your own CA and trust it as a root CA, you are responsible for the security of that CA - it can be used against you. This is especially problematic if I want someone else to trust my certs in their browser, I'm asking them to trust any certificate I generate, including google.com, mybank.com, etc.
For some other purposes, where the Web PKI isn't applicable, you might have a solid argument for why people should trust your PKI. But then they aren't trusting certificates in their browser but in some other likely very constrained system that's easier to reason about.
For example I've operated (for past employers) a service that was available over HTTPS to a handful of insurance and financial outfits using mutual TLS. I'd issue client certificates for them, and then they'd use their private key and their certificate to access the service over HTTPS. In that case I ran the CA, and so they're trusting me. But only narrowly to identify customers of the service I run, so it's not tricky to reason about.
Now, technically you could use certificates from Let's Encrypt as client certificates, they have the right EKU for that purpose but then your identity has to be an Internet FQDN and you need new certificates every ninety days, which sucks. So although I'd have accommodated a paying customer who firmly insisted on doing that, none of them did.
Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt
#40Keep in mind, adding local entries to your external DNS will expose internal details of your network, such as hostnames and IPs. Same goes for Let's Encrypt, due to Certificate Transparency logging.
While you'll get the hostnames leaked - you could register them as fake addresses (say an A record for 192.168.0.1 for every address), and have a local DNS server overriding with the real addresses. Whether this is worthwhile or not is debatable. Is the fact your internal server 'gubbins.mydomain.com' exists, or even that it exists on 10.0.41.43 really much use? The other option for internal certificates is to get a…