Solved: Letsencrypt-auto failed to connect to wrong IP address

Please fill out the fields below so we can help you better.

My IP is: ip_address_1
My domain is:

I ran this command: ./letsencrypt-auto --apache -d

It produced this output:
Failed authorization procedure. (tls-sni-01): urn:acme:error:tls :: The server experienced a TLS error during domain verification :: Failed to connect to ip_address_2:443 for TLS-SNI-01 challenge


  • The following errors were reported by the server:

Type: tls
Detail: Failed to connect to ip_address_2:443 for TLS-SNI-01

My operating system is (include version): Ubuntu LAMP 16.04

My web server is (include version): Apache 2.4.18

My hosting provider, if applicable, is: DigitalOcean

I can login to a root shell on my machine (yes or no, or I don’t know): Yes.

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): No.

Please note:
a) Entering in a browser takes me to the right IP address
b) whois lists NameCheap which is with whom we registered the domain name
c) whois lists WhoIsGuard as the Registrant and Admin
d) whois lists CloudFare as the Name Server which is who we went for DNS
e) nslookup lists 2 non-authoritative IP addresses. One is ip_address_2 and the other is slight variation on ip_address_2 (one is X.X.190.X and the other is X.X.191.X)
f) whois ip_address_1 gives DigitalOcean as the organization
g) nslook ip_address_1 gives a strange result. Non-authoritative answer =,
h) whois ip_address_2 gives CloudFare as the organization
i) nslook ip_address_2 gives Authoritative answer = CloudFare
j) Initial attempt (~6 days ago) had a failure error with a third IP address that points to NameCheap, with whom we registered the domain name. About 3 days ago, the error message started giving ip_address_2

If you’re using any of Cloudflare’s other features besides just DNS, then the TLS-SNI-01 challenge (which is the default for the apache plugin) won’t work. You could maybe try the webroot challenge instead.

Interesting, thank you. I believe I tried the webroot challenge correctly but I’m still getting an error.

Command used:
certbot-auto certonly --webroot -w /var/www/html/ -d

I used /var/www/html/ because that’s what I see within /etc/apache2/sites-enabled/000-default.conf and it’s the only .conf file in that folder


Type: connection
Detail: Could not connect to ip_address_1
To fix these errors,… If you’re using the webroot plugin, you should also verify that you are serving files from the webroot path you provided.

Okay, I’m glad it lists ip_address_1 but there is still something wrong. I think the last sentence may be a clue. How do I verify that I am serving files from the webroot path?

@pj87, something like

echo hello > /var/www/html/testfile.html curl -v

Much appreciated for the help! Below is a screenshot of the result from using curl. I then re-ran my certbot-auto command. I received the same error message.

Does it make sense that when running curl -v, it first connects to ip_address_2?

Is that Location: http://ip_1/ or Location: http://ip_1/testfile.html?

It is Location: http// ip_address_1 without a trailing / and without /testfile.html

So if you use wget -L http://domain_1/testfile.html, it will fail?

It did not fail
’testfile.html’ saved [1324/1324]

Hmmm, I don’t understand how that’s possible. I suggest that you tell us what the actual domain name is. :slight_smile:

The actual domain name is

Thanks! That was immediately helpful.

So, the redirect is not working properly. If you look at the testfile.html that got saved, it’s not the file that you put in your webroot directory on your server, but rather an autogenerated file from DigitalOcean that says “Please log into your droplet via SSH to configure your LAMP installation.”

So, you’ll have to figure out how to get your hosting environment to allow you to serve individual files from that directory.

I think from what we saw above that the biggest problem is actually the redirect: instead of sending you to their specified path on what you called ip_1, it sends everyone to the home page or top level of ip_1. If you try to access any specific file, you instead get the ip_1 home page, which is the not about needing to configure the server.

You’re right, when I do cat testfile.html it is not the file we created. I’m not sure if this is good news or not. Any suggestions on how to proceed? I have no experience in this domain unfortunately

Do you have some kind of tech support from DigitalOcean?

It looks like you can’t effectively post any content at all on, which will preclude your passing the HTTP-01 challenge that webroot uses. You have to be able to post content there in order to pass the challenge. :slight_smile:

Thank you very much Schoen for your help (and time). I created a support ticket with DigitalOcean. I’ll keep this thread updated

Success. Thank you jmorahan and schoen!

Another user was responsible for purchasing the domain name via NameCheap and setting up CloudFare account. Turns out they did not direct the .org to the correct IP address.

Once that was fixed, I was able to use:

  1. Create placeholder html code
    sudo mkdir /var/www/
    sudo chown -R $USER:$USER /var/www/
    sudo chmod -R 755 /var/www
    nano /var/www/
    Enter placeholder html code

  2. Create apache .conf for the domain
    sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/
    Open the .conf and update server details to and update DocumentRoot to /var/www/

  3. Enable host files
    sudo a2ensite

  4. Restart apache
    sudo service apache2 restart

  5. Verify
    Go into browser and go to http:/

  6. Run certbot-auto with webroot
    /usr/local/sbin/certbot-auto certonly --webroot -w /var/www/ -d

  7. Set up cron to autorenew

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.