4 ms·

You can get a Let's Encrypt certificate for an internal subdomain: https://security.stackexchange.com/questions/103524/lets-encrypt-for-intranet-websites#121187

by zaik 5y ago

You can get a Let's Encrypt certificate for an internal subdomain: https://security.stackexchange.com/questions/103524/lets-encrypt-for-intranet-websites#121187 https://security.stackexchange.com/questions/103524/lets-enc...

Hamuko 5y ago
Yeah, this. I have a dedicated domain for my internal network (it's just 9€ per year so might as well) and just use a LE certificate with the DNS verification, so no need to have any external web traffic.
dheera 5y ago
One of the problems of that is now you need to list all your internal IP addresses in a public DNS server. It shouldn't theoretically be an issue but it might be stuff you don't want to just lay out there in public view just in case. Also you might just not want a domain like "my-top-secret-project.amazon.com" to actually exist and resolve to an IP (even if an intranet IP) in public DNS, but you might still want an easy-to-remember intranet hostname that employees can use.
- Hamuko 5y ago
  >One of the problems of that is now you need to list all your internal IP addresses in a public DNS server. You don't actually. You can just have them resolve in your local DNS server alone. My current setup is that the public DNS records for my internal network just return CNAME records, so "mail.myserver.com" has a CNAME record to "mail.myserver.internal" and my private DNS server has an A record for "mail.myserver.internal".
  - jbverschoor 5y ago
    Still, you're exposing your infrastructure. It's kind of nice to know that there is a mongo1.profiles.company.com somewhere.
    - Hamuko 5y ago
      You can just obfuscate your names if you really need to keep it hidden. profiles.company.com? coffee.company.com. mail.company.com? tomato.company.com. passwords.company.com? tincan.company.com. If you're really paranoid, you can just flood a bunch of misdirects in there as well. If you need 10 internal subdomains, add 100 subdomains with random CNAMEs.
    - aaomidi 5y ago
      You can use wildcard certificates so you're not exposing any infrastructure. Also, you should really consider all your subdomains to not be private information. It's risky to build security based around that assumption. Tons of DNS services actually sell their queries, and those can be used to reconstruct these "private" subdomains.
      - pixl97 5y ago
        With this said, wildcards are massive security risks in themselves when devices start getting compromised. You can then chain together things like DNS poisoning and arp attacks to MITM further devices on the network. And confirming what you said. DNS leaks everywhere, so don't consider its obscurity a form of security.
  - hultner 5y ago
    I’m going to steal this one, I’ve never thought about this. Also useful for local development with mdns. E.g. MacBook-X.local as an CNAME: "MacBook-X.internal.hultner.se CNAME MacBook-X.local" should just work for LE on my local dev machine when roaming between the home, office or on the go and the actual IP changes wildly.
- amarshall 5y ago
  You don’t need to if you use ACME DNS challenge. I have split horizon where the ACME creates the temporary challenge record, LetsEncrypt sees it, and then the record is removed. There is never a public A record, and the window for enumerating the challenge record is short. That said, I never really understood worrying about exposing DNS records because someone has to brute-force enumerate the domain names, and because it just obfuscates. I do split horizon for different reasons and am currently moving away from it. Regardless, if you do care, you should be concerned about certificate transparency logs. The “workaround” for that is wildcard certs.
  - hultner 5y ago
    LE publishes all issued certs so you might as well just keep it public anyway in that case.
    - Hamuko 5y ago
      Wildcard certs?
      - edoceo 5y ago
        Yep. The CN is something like "*.edoceo.com" And you can make self-signed too.
    - amarshall 5y ago
      Yes, I said this. Wildcard certs, as I mention, largely avoid the issue because it’s just one cert for a higher-level domain and largely uninteresting from an information disclosure perspective, at least compared with individual domain certs.
bombcar 5y ago
Just setup letsencrypt to give you a wildcard cert and copy it where it’s needed. I do it for my home network and it’s a script to run every three months.
xg15 5y ago
It's worth noting that split-horizon DNS can cause problems with DoH. If your "public" DNS entry has an A/AAAA record, DoH-enabled browsers will resolve your domain to that external IP instead of fetching the internal DNS record. So if you do split-horizon, don't put an A/AAAA-entry into the internet-facing side, instead use the ACME DNS challenge as described in the sibling comments.

by zaik 5y ago

Hamuko 5y ago

Yeah, this. I have a dedicated domain for my internal network (it's just 9€ per year so might as well) and just use a LE certificate with the DNS verification, so no need to have any external web traffic.

dheera 5y ago

One of the problems of that is now you need to list all your internal IP addresses in a public DNS server. It shouldn't theoretically be an issue but it might be stuff you don't want to just lay out there in public view just in case. Also you might just not want a domain like "my-top-secret-project.amazon.com" to actually exist and resolve to an IP (even if an intranet IP) in public DNS, but you might still want an easy-to-remember intranet hostname that employees can use.

Hamuko 5y ago
>One of the problems of that is now you need to list all your internal IP addresses in a public DNS server. You don't actually. You can just have them resolve in your local DNS server alone. My current setup is that the public DNS records for my internal network just return CNAME records, so "mail.myserver.com" has a CNAME record to "mail.myserver.internal" and my private DNS server has an A record for "mail.myserver.internal".
- jbverschoor 5y ago
  Still, you're exposing your infrastructure. It's kind of nice to know that there is a mongo1.profiles.company.com somewhere.
  - Hamuko 5y ago
    You can just obfuscate your names if you really need to keep it hidden. profiles.company.com? coffee.company.com. mail.company.com? tomato.company.com. passwords.company.com? tincan.company.com. If you're really paranoid, you can just flood a bunch of misdirects in there as well. If you need 10 internal subdomains, add 100 subdomains with random CNAMEs.
  - aaomidi 5y ago
    You can use wildcard certificates so you're not exposing any infrastructure. Also, you should really consider all your subdomains to not be private information. It's risky to build security based around that assumption. Tons of DNS services actually sell their queries, and those can be used to reconstruct these "private" subdomains.
    - pixl97 5y ago
      With this said, wildcards are massive security risks in themselves when devices start getting compromised. You can then chain together things like DNS poisoning and arp attacks to MITM further devices on the network. And confirming what you said. DNS leaks everywhere, so don't consider its obscurity a form of security.
- hultner 5y ago
  I’m going to steal this one, I’ve never thought about this. Also useful for local development with mdns. E.g. MacBook-X.local as an CNAME: "MacBook-X.internal.hultner.se CNAME MacBook-X.local" should just work for LE on my local dev machine when roaming between the home, office or on the go and the actual IP changes wildly.
amarshall 5y ago
You don’t need to if you use ACME DNS challenge. I have split horizon where the ACME creates the temporary challenge record, LetsEncrypt sees it, and then the record is removed. There is never a public A record, and the window for enumerating the challenge record is short. That said, I never really understood worrying about exposing DNS records because someone has to brute-force enumerate the domain names, and because it just obfuscates. I do split horizon for different reasons and am currently moving away from it. Regardless, if you do care, you should be concerned about certificate transparency logs. The “workaround” for that is wildcard certs.
- hultner 5y ago
  LE publishes all issued certs so you might as well just keep it public anyway in that case.
  - Hamuko 5y ago
    Wildcard certs?
    - edoceo 5y ago
      Yep. The CN is something like "*.edoceo.com" And you can make self-signed too.
  - amarshall 5y ago
    Yes, I said this. Wildcard certs, as I mention, largely avoid the issue because it’s just one cert for a higher-level domain and largely uninteresting from an information disclosure perspective, at least compared with individual domain certs.

bombcar 5y ago

Just setup letsencrypt to give you a wildcard cert and copy it where it’s needed. I do it for my home network and it’s a script to run every three months.

xg15 5y ago

It's worth noting that split-horizon DNS can cause problems with DoH. If your "public" DNS entry has an A/AAAA record, DoH-enabled browsers will resolve your domain to that external IP instead of fetching the internal DNS record. So if you do split-horizon, don't put an A/AAAA-entry into the internet-facing side, instead use the ACME DNS challenge as described in the sibling comments.