Subdomain with A record on different server

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

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