Domain fails DVSI Challenge

Help
1

Anytime I run the client trying to connect to a virtualhost I had setup, I receive this error. I made sure that ufw is not blocking port 443 and I can access the site. I have no idea what could be causing this, please help!

./letsencrypt-auto --apache -d alexkey.es
Checking for new version…
Requesting root privileges to run letsencrypt…
sudo /home/pi/.local/share/letsencrypt/bin/letsencrypt --apache -d alexkey.es
Failed authorization procedure. alexkey.es (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to host for DVSNI challenge

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: alexkey.es
    Type: connection
    Detail: Failed to connect to host for DVSNI 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.

2

I tried connecting and got connection refused. So it looks like the firewall isn’t blocking 443, but Apache isn’t listening on it.

3

Oh, okay I didn’t realize that you needed both apache to be listening as well as ufw to not be blocking port 443. So all I need to do now is edit the apache conf file to make it listen on 443 right?

4

Yes, get it working with a self-signed cert 1st, then the client should swap it for for the proper one.

5

Thanks for the advice man! I figured out the problem was not that I couldn’t setup a cert, it’s that my domain wasn’t pointing to my IP. It was pointing to my registrars IP then Redirecteding to my IP. After changing the DNS it worked!

6

That's not fully necessary. The official client will/can pick the non-TLS <VirtualHost> from Apaches configuration file and transfer it to a HTTPS one. This way one doesn't have to generate a self signed certificate. In any case, the LE client will generate its own certificate with a part of the token as a Common Name in it and temporary use it for the tls-sni-01 challenge. Afterwards, it'll swap this temporary cert for the real deal. Even if a self signed certificate was installed, it isn't used during the validation and issuing process.