No valid IP addresses found for (my domain)

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. |, so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:
sudo certbot --staging --nginx

It produced this output:

Obtaining a new certificate
Performing the following challenges:
http-01 challenge for
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. (http-01): urn:acme:error:unknownHost :: The server could not resolve a domain name :: No valid IP addresses found for


  • The following errors were reported by the server:

    Type: unknownHost
    Detail: No valid IP addresses found for

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address.

My web server is (include version):
nginx/1.10.3 (Ubuntu)

The operating system my web server runs on is (include version):
Ubuntu 16.04.4 LTS

My hosting provider, if applicable, is:

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

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
No            1799    IN      A            1799    IN      A

You have a private IP address listed for your domain.

That’s why it fails.

1 Like

I was curious about that. What would a public IP address be? Would that be my dnsleaktest IP (

Also, should this be changed in the A record on the domain registrar account (NameCheap), or is this something I should change on my server itself?

The reason that is private is that it is not routable on the internet. It is usually used on LAN networks - .

Your other A record, , points to Namecheap’s URL forwarding service.

Now, if you want to issue a certificate using Certbot for your domain name, you need to remove both of these records at Namecheap, and add an A record that points to the IP address of the actual web server running nginx.

The domain needs to point at your web server, otherwise Certbot is not able to prove that you control the domain, which is required in order for you to issue a certificate.

To add, not only does the domain need to point to your web server, your web server also needs to be accessible from the outside internet. So if you are running this nginx server behind a residential connection with a modem/router, this might involve forwarding ports 80 and 443 on the router to the computer running nginx. Keep in mind that some residential internet providers block port 80, making this impossible.

If you can’t organize this, there is an alternative. You can use DNS validation rather than the default validation method that --nginx uses (which is HTTP/webroot).

In this variant, you would need to manually setup TXT records in Namecheap.

You can ask Certbot to guide you through that by running:

sudo certbot -a manual -i nginx --preferred-challenges dns -d
1 Like

Certainly. I was confused this entire time about because I knew it was a router IP.

I'm honestly not sure where is. I don't see that in my NameCheap A records.

So, I just need to understand which public IP address is my server. Is that the result of a whatismyipaddress?

Make sure ports 80 and 443 are forwarded. I will look into that.

I have BIND set up, for DNS validation (that's why I wasn't sure whether the A records were wrong on NameCheap or my server itself, or both).

I will give that line of code a try: sudo certbot -a manual -i nginx --preferred-challenges dns -d

It may appear as a 'URL forwarding' option or something like that. You should ask Namecheap support if you can't figure out how to rid yourself of it.

If you're on the same internet connection as your server, probably, yes.

Your domain has its nameservers configured to those of Namecheap right now. If you want to use your own nameserver, then you would need to change the nameserver delegation on Namecheap to your Bind server. However, running a single authoritative nameserver off a residential internet connection is pretty sketchy and I wouldn't advise it.

1 Like            1799    IN      A            1799    IN      A

What did you do to find that info? I’d like to check that for myself as well.

I used e.g.

dig +trace

(+trace to avoid cached answers)

You can also use , which will more accurately represent what Let’s Encrypt sees.

The URL forwarder record appears to be gone now.

1 Like

Ah, a dig. Thank you. I cleared out my NameCheap A records (why you shouldn’t see the redirect anymore). Doing another dig, I believe I have to change my local DNS record to reflect the public IP.

I’m still seeing my private IP using dig +trace That’s gotta be something on my end.

Did you update the A record at Namecheap? Can you take a screenshot of the record list?

The attached image is what I changed it to about 30 minutes ago or so.

That looks like it would work. You may just have to wait longer for the nameservers to update. :slightly_frowning_face:

(The “” and “” records are probably not necessary, though. They probably expand to “” and “” respectively.)

1 Like

Oh, so making the Host (@ or www) the domain is not accurate and results in that comical repeated string you’ve shown. Wondered about that too. I appreciate the clarification. I put them there as a “I’m just going to put records of everything here and see what sticks”, which is not my usual way, but this is definitely giving me a challenge.

I will remove those two A records and

Edit: I have heard one mention of NameCheap being slower. I think I can increase the TTL to 1 minute.

Edit 2: I think NameCheap beat me to the punch.

Looks good, I can access your webserver. Running certbot --nginx should be all you need now.

Ran this to test it: sudo certbot --staging --nginx -d -d (because I ran into the problem, running that without --staging, of limits. I didn’t read ahead on that one.

But, that was successful. I did give me a cert, chain, and key, because running without --staging told me I already had one.

So, it seems like it went live automagically, but I’m not trusted (, and there is a ton to read through and comprehend on that page.

No, it's because it's fake, right?

Issuer Fake LE Intermediate X1

because it was --staging, right?

Nope, don’t get why it’s not trusted.

Seems like you fixed it?

Yeah, but I’m not trusted. So I’m not sure what’s happening there.