Can't verify even right IP

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 --nginx -d

It produced this output:

 - The following errors were reported by the server:

   Type:   unauthorized
   Detail: Invalid response from
   []: "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML+RDFa

   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 version: nginx/1.16.1

The operating system my web server runs on is (include version): Centos 7

My hosting provider, if applicable, is: Self host

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):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 1.11.0

I can't verify my domain with certbot the error show me error about A record. But when I check - Make your website better - DNS, redirects, mixed content, certificates everything's ok
Others domain I can verify successfully.
What should I do in this case? Is there anything wrong from NameCheap (domain provider)?
Any help would be much appreciated! Thanks in advance!

1 Like

There is no problem with the A or AAAA record, the error message is misleading. The problem is that the web server does a redirection to a logon page instead of serving the challenge reply:

curl -v '



header. You may want to change the configuration of the web server not to give redirection for the challenge URLs.


I'd check the other HTTP vhost configs to see why they work.

If all else fails to point out the problem...
You can use something like this in the HTTP vhost to redirect only the NON-challenge requests and provide a dedicated path for the challenge requests:

  location ^/(?!\.well-known) {            # skip challenge requests
    return 301 https://$host$request_uri;  # send all requests to HTTPS
  }# location
  root /new/dedicated/challenge/path;      # path for challenge requests

I've tried both of above solutions but it didn't work.
I use nginx as reverse proxy
Here is my conf

server {
        listen 80;


        location / {
                proxy_pass_header Authorization;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_http_version 1.1;
                proxy_set_header Connection "";
                proxy_buffering off;
                client_max_body_size 0;
                proxy_read_timeout 10000s;
                proxy_redirect off;

With other domains, it's fine with the configurations. Only didn't work.
What's the different?

If you show one of the other vhost config, then maybe we can see the difference.

For now, I would have to say there is something in the config that you have overlooked.


I agree with @rg305, we need to see the other server blocks to see what may be different.

But, do you really need https:// for your proxy_pass? Seems unnecessary for a self-hosted site and that http:// would be fine. It is not wrong - just unusual. Could that be what is different?


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