No IPV4 addresses found


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, and an externally registered alias, 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 works fine. It does not matter if I remove the request for a certificate for

Suggestions would be most welcome!

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


  • The following errors were reported by the server:

    Type: urn:acme:error:unknownHost
    Detail: No IPv4 addresses found for

  • The following errors were reported by the server:

    Type: urn:acme:error:connection
    Detail: Failed to connect to host for DVSNI challenge


% host mail is handled by 0

This is what I’m seeing on my end. An IPv4 address is missing for, 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 method, since you already have apache running. With webroot, you don’t have to stop an already running apache instance when issuing certs.


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, with the webserver running, but failed for I will go with what I have.

./letsencrypt-auto certonly --verbose --webroot -w /home/public -d


  • Congratulations! Your certificate and chain have been saved at
    /etc/letsencrypt/live/ 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.


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

./letsencrypt-auto certonly --verbose --webroot -w /home/public -d -d

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 (if you want people to be able to access it via HTTPS) is definitely a prerequisite for this.


Thanks, schoen and eridan911 – everything is working now!