Subdomain with A record on different server

I have ServerA with CloudLinux where is served. On ServerA is the defined with an A record pointing to ServerB with Debian 9, Nginx 1.10.3 by IP (ServerB is a different remote server).

While trying to issue a cert with Certbot 0.28.0 on ServerB for I receive the following error: “Failed authorization procedure. (http-01). urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from”

Tried with: certbot nginx
as well as with: certbot certonly --staging --webroot -w /var/www/domain/ -d

The directories /.well-known/acme-challenge have both permission 755, a dummy file is accessible with curl and nginx is configured to always return content type /plain/text for this directory.

Nginx conf:

server {
listen      80;
listen      [::]:80 default_server ipv6only=on;

root /var/www/domain;

location ~ /\.well-known/acme-challenge {
    allow all;
    default_type text/plain;


A record of server B on server A? is server A authoritative name server for zone? (NS record fro from com zone tells server A’s IP?)

if not, A record set on server A won’t heard by anything. add proper A record for subdomain on where you bought the domain, or you use for DNS hosting

1 Like

The “A record” is defined on ServerA, pointing to on ServerB by IP.

Yes, has NS entry pointing to the hoster of ServerA where is served from. is accessible and works fine.

1 Like

if NS record direct to “Hoster” of server A, not A’s IP itself, then A record for subdomain must be added on hoster’s site menu.

1 Like

Thanks for your efforts!

Following DNS config is active:                       A      IP ServerA                       NS (different from IP ServerA)                       NS (different from IP ServerA)             A      IP ServerB

What do you mean with “A record for subdomain must be added on hoster’s site menu.”?
The “A record” pointing to ServerB was entered in the hoster’s web panel where config is done for

server A is red haring, so let’s turn it off(ignore it). would you expect your config to work if you do that?
if done right server B work even if server A is turned off.
use’s API/web menu for DNS records for any subdomain. using IP of server B.


If global DNS can resolve that IP, then you need only look at ServerB.
Any other DNS entry is irrelevant to satisfy a challenge request for ServerB.

1 Like

Yes, both of these work and shows the content of the file:


So were you able to get a cert?

Unfortunately not. Your answers helped me to understand it better, but nothing was changed in configs so far, so the same error as in the original post still appears. I run the certbot command as root

Then there is some issue with the --webroot and the real root...
Try making a dedicated location for the challenges:
[something like]
sudo mkdir /ACME-challenges/
sudo chmod 777 /ACME-challenges/
then modify this location section:

to specify the challenge root:
[and slightly modified location]

location /.well-known/acme-challenge/ {
 allow all;
 default_type text/plain;
 root /ACME-challenges/;

[restart/reload nginx]
Then place a testfle in that location and see if it is accessible from Internet and then rerun certbot.

Created the directory, and adopted nginx config per your suggestion. Instead of root /ACME-challenges/; I had to use the alias directive. The dummy file is accessible via browser. Ran certbot with certbot --staging --nginx.

Same error occurs: “Failed authorization procedure. (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization”

What is your real domain and subdomain? What is the complete error message?

Try adding
-webroot -w /ACME-challenges/

Forgot to mention, also tried it before with the same error result: certbot certonly --staging --webroot -w /ACME-challenges/ -d

Output from certbot:

Waiting for verification…
Cleaning up challenges
Failed authorization procedure. (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from : "\n<html style=“height:100%!(MISSING)”>\n\n<meta name=“viewport” content=“width=device-width, initial-scale=1, shrink-to-”


Does accessing that IP produce the testffile?
[maybe you are only checking IPv4 path]

No it doesn’t. Tested it with browser and curl -g. Should I test it in any other way?

Letsencrypt will always use ipv6 version first so if that can’t see file challenge will fail.

Hi @stabilo

checking your ipv6 there is a cPanel error message.

That’s one of the reasons your domain name is required: Too much missing informations.

If you have a cPanel, Certbot may not work. So your configuration is buggy.

If your test system has IPv6:
curl -6