Certbot fails when using an invalid /etc/hosts configuration and does not print a specific diagnostic error.

[leaf-node]

I set up a server with an incorrect ip address associated with the host name of the server in its /etc/hosts file, causing certbot-auto to fail when attempting to create a certificate with the --apache method. It would be nice if certbot detected this specific issue and printed a helpful message specific to the error.

2016-12-07 16:55:49,372:DEBUG:certbot.reporter:Reporting to user: The following errors were reported by the server:

Domain: my.domain
Type:   connection
Detail: Failed to connect to 111.111.111.111:443 for TLS-SNI-01 challenge

To fix these errors, please make sure that your domain name was entered correctly and the DNS A record(s) for that domain contain(s) the right IP address. Additionally, please check that your computer has a publicly routable IP address and that no firewalls are preventing the server from communicating with the client. If you're using the webroot plugin, you should also verify that you are serving files from the webroot path you provided.

I set up my server using xen and a custom fai system, but using an incorrect ip address. I corrected the host's dns entry and fixed /etc/network/interfaces and the /etc/xen/my.domain.cfg file, but I did not change /etc/hosts until I debugged the source of the issue. To test this issue, you could try setting up Trisquel 7 or any GNU/Linux system and adding (or changing) an entry in /etc/hosts, inserting the incorrect ip address for the FQDN and PQDN of the host. As far as I know, the incorrect ip address I used was not in use by any other host on the internet at the time of testing.

As an aside, apache2 was serving http over the https port when incorrectly configured like this. You can see this by running:

curl http://my.domain:443/

If you would like more details, see the following thread:

• https://community.letsencrypt.org/t/certbot-auto-unable-to-complete-tls-sni-01-challenge-on-ubuntu-14-04/23657

Thank you.

[pde]

@joohoi interested in investigating this?

[joohoi]

AFAIK the connection error you are seeing, is reported by boulder, and hence the invalid /etc/hosts entry should not play any role in this issue. The boulder server is resolving the IP address from authoritative DNS server associated to your domain, tries to connect it, and in this case, fails to do so.

Can you confirm that your firewall configuration allows connections to port 443 to the IP address that the authoritative DNS server resolves your domain to?

[cpu]

@joohoi In this case I verified from the Boulder side that the TLS-SNI-01 challenge connection does make it to their server. Boulder's VA produces an error about an oversized record indicative of HTTP instead of HTTPs. It won't be a firewall or DNS issue in this case, but Apache configuration (perhaps as generated by Certbot?) related.

[joohoi]

Thanks for clearing this up @cpu ! @sudoman could you check that it is apache2 that's occupying port 443. I'll take a look into Trisquel to see if there's something strange going on. The /etc/hosts entries shouldn't matter here however (other than apache2 warnings for unresolvable names).

[leaf-node]

Sorry that I haven't looked at this in a while. I do believe that port 443 was listed as opened by apache2 according to lsof. As for the /etc/hosts file misconfiguration, I tried reproducing the error on an Ubuntu machine, but wasn't able to reproduce the problem.

[jsoref]

This sounds like a variation of #3981

[bmw]

Closing for now, but if you're still having issues please comment adding more information about how to reproduce the problem and we'll reopen.