Securing Private Intranet Sites

[hamishmacewan]

@schoen

There's no authoritative way to confirm whether someone really does or doesn't control a site unless they can make some publicly-visible change that we can see over the Internet.

dns-01 authentication tells you nothing about whether a site even exists, so I find the argument without much merit.

Yes, I do make a "publicly-visible change," in that case to the domain I must control, which http-01 doesn't accept even in the SAN for a domain which resolves.

That is not "simply claiming" but making as strong a demonstration as required and accepted by dns-01.

@hamishmacewan

CertBot repeatedly complained that local.macewan.nz did not resolve. It did, but it appears that resolving to a private IP is the same thing as not resolving. It would be nice if the error was a little more helpful if this is the case.

Could you confirm my suspicion that the ACME server (plus forgive any incorrect nomenclature, this is a complex and arcane business) falsely complains that a name does not resolve if it does resolve to a private IP? Whatever the policy it is deceitful to mislead users in this way, making troubleshooting problems harder.

Thanks for the service, hopefully it will be massively adopted.

[pfg]

@hamishmacewan

dns-01 authentication tells you nothing about whether a site even exists, so I find the argument without much merit.

Yes, I do make a "publicly-visible change," in that case to the domain I must control, which http-01 doesn't accept even in the SAN for a domain which resolves.

That is not "simply claiming" but making as strong a demonstration as required and accepted by dns-01.

I'm having a hard time trying to understand what you're suggesting, maybe you could clarify this bit?

We basically have two verification mechanisms (I'm leaving out TLS-SNI-01, it's similar to HTTP-01): One that works by making a visible change to a site, which can be verified using a HTTP request (HTTP-01), demonstrating that you have full control over the site's content, and one that works by making a change to the site's DNS by having you create a TXT record with a token (DNS-01), which demonstrates that you have full control over the domain's DNS.

The HTTP-based mechanism requires that the IP address of your domain is publicly routable and accessible from the internet (or more specifically: from Let's Encrypt's validation servers), as that's the only way Let's Encrypt can be sure the domain actually belongs to you. DNS-based challenges do not have this requirement. If private IPs were to be accepted for HTTP-01, the validation server (which sits in Let's Encrypt's data center) would not be able to connect to confirm the verification files are present. If the verification were to be a client responsibility, it could simply lie about the files being present, allowing you to get a certificate for any domain. That's basically the worst thing that could happen to a CA, short of the root key being compromised.

@hamishmacewan

Could you confirm my suspicion that the ACME server (plus forgive any incorrect nomenclature, this is a complex and arcane business) falsely complains that a name does not resolve if it does resolve to a private IP? Whatever the policy it is deceitful to mislead users in this way, making troubleshooting problems harder.

Your suspicion is correct, you can track this issue to follow the progress of getting this fixed:

Unclear error message when using private IPs