No IPV4 addresses found

1

I would like to implement letsencrypt and obtain a certificate on CentoOS 6.7.
letsencrypt was successfully installed; port 443 is open and a standard web server has been running for some time on port 80 (stopped for certificate request).

The machine has two URLs, email.uoxray.uoregon.edu and an externally registered alias, http://www.uoxray.uoregon.edu that both point to the same IP address.

Attempts to get a certificate using the standalone process lead to the following error message. Evidently, the standalone server that is implemented can’t resolve either address, but a ping from another machine to http://www.uoxray.uoregon.edu works fine. It does not matter if I remove the request for a certificate for uoxray.uoregon.edu.

Suggestions would be most welcome!

[code][root@email ~]# service httpd stop
Stopping httpd: [ OK ]
[root@email letsencrypt]# ./letsencrypt-auto certonly --standalone --email myemail@uoregon.edu -d www.uoxray.uoregon.edu -d uoxray.uoregon.edu
Updating letsencrypt and virtual environment dependencies…
Requesting root privileges to run with virtualenv: /root/.local/share/letsencrypt/bin/letsencrypt certonly --standalone --email myemail@uoregon.edu -d www.uoxray.uoregon.edu -d uoxray.uoregon.edu
Version: 1.1-20080819
Version: 1.1-20080819
Failed authorization procedure. uoxray.uoregon.edu (tls-sni-01): urn:acme:error:unknownHost :: The server could not resolve a domain name :: No IPv4 addresses found for uoxray.uoregon.edu, www.uoxray.uoregon.edu (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: uoxray.uoregon.edu
    Type: urn:acme:error:unknownHost
    Detail: No IPv4 addresses found for uoxray.uoregon.edu

  • The following errors were reported by the server:

    Domain: www.uoxray.uoregon.edu
    Type: urn:acme:error:connection
    Detail: Failed to connect to host for DVSNI challenge
    [/code]

2

% host uoxray.uoregon.edu uoxray.uoregon.edu mail is handled by 0 email.uoxray.uoregon.edu.

This is what I’m seeing on my end. An IPv4 address is missing for uoxray.uoregon.edu, which is exactly what the error message is stating.

Not sure why the authorization fails for www. Could you perhaps try adding the --verbose flag to letsencrypt-auto to get some more info about what’s going on. Note that tls-sni-01 uses port 443.

Another option is to use the webroot http://letsencrypt.readthedocs.org/en/latest/using.html#webroot method, since you already have apache running. With webroot, you don’t have to stop an already running apache instance when issuing certs.

3

Thanks very much!

./letsencrypt-auto --verbose did not provide any additional insight.

I followed the instructions in the link you provided to the --webroot option, but they did not seem to be quite correct (there seems to be no executable named letsencrypt in the default path).

However, the following command succeeded for www.uoxray.uoregon.edu, with the webserver running, but failed for uoxray.uoregon.edu. I will go with what I have.

./letsencrypt-auto certonly --verbose --webroot -w /home/public -d www.uoxray.uoregon.edu

Result:
IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at
    /etc/letsencrypt/live/www.uoxray.uoregon.edu/fullchain.pem. Your
    cert will expire on 2016-05-10. To obtain a new version of the
    certificate in the future, simply run Let’s Encrypt again.
    …
4

@JimRemington, @eridan911 is right to point out that there is no IPv4 address in the DNS for uoxray.uoregon.edu. If you had one, you could get a certificate covering both names by running

./letsencrypt-auto certonly --verbose --webroot -w /home/public -d www.uoxray.uoregon.edu -d uoxray.uoregon.edu

assuming that the web server is also configured to respond for both names and to serve their content from /home/public. (If you ran this after running your previous command, it would probably also detect the previous certificate and offer to expand it by replacing it with the new certificate that covers both names.) However, creating an A record in DNS for uoxray.uoregon.edu (if you want people to be able to access it via HTTPS) is definitely a prerequisite for this.

5

Thanks, schoen and eridan911 – everything is working now!