Failed authorization procedure with nginx and subdomain

Hello everyone, I have the following error while trying to obtain a certificate.

I run: certbot certonly -a webroot --webroot-path=/var/www/html/mysite -d sub.domaincom -d www.sub.domain.com

and I get:

Failed authorization procedure. sub.domain.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: NXDOMAIN looking up A for sub.domain.com

  • The following errors were reported by the server:

    Domain: sub.domain.com
    Type: connection
    Detail: DNS problem: NXDOMAIN looking up A for sub.domain.com

I have two A records on Namecheap pointing to a different server (digital ocean) which are these:

Name: www.sub.domain.com
TTL: 1200
Type: A
Address: my.ip.add.ress (digital ocean server ip)

Name: sub.domain.com
TTL: 1200
Type: A
Address: my.ip.add.ress (digital ocean server ip)

My nginx configuration is this:

server {
   listen 80;
   root /var/www/html/mysite;

   server_name sub.domain.com;

   location ~/.well-known {
      allow all;
   }

   location / {
      proxy_pass http://localhost:port;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection 'upgrade';
      proxy_set_header Host $host;
      proxy_cache_bypass $http_upgrade;
    }
}

Please note that I have more 3 different websites under /var/www/html and I am trying to get the certificate for one of them which is a node.js webapp.

Any ideas on what I am missing?

Thank you very much.

Hi @zisis,

In this case your web server configuration is probably not relevant at all. I would suggest that you either tell us the domain or use some online DNS checkers to see if you can find a problem with the DNS configuration.

Note that the ability to reach the site in a browser is not necessarily good enough because the Let’s Encrypt CA will follow the DNS standards more strictly and reject some DNS configurations that have errors, even if a browser might accept them.

Hi @schoen,

Thank you for replying this fast. Could you suggest me a DNS checker and what problems should I be looking for?

I don’t happen to remember which ones would be best in this situation. We had a previous discussion thread about which DNS checker to recommend to Let’s Encrypt users who were reluctant to share their domain names, and we didn’t reach a clear conclusion about which was best.

Unfortunatelly I am not allowed to share the domain. I used https://intodns.com/ but it can’t test for subdomains, only for domains so i tested the main domain and got the following warning:

“SOA EXPIRE Your SOA EXPIRE number is: 3600000. That is NOT OK”

Could this be the issue?

I also tested it on https://mxtoolbox.com and got this:

dmarc mydomain.com DNS Record not found More Info
https mydomain.com The Certificate has a name mismatch More Info
dns maydomain.com SOA Refresh Value is outside of the recommended range More Info
dns mydomain.com SOA Expire Value out of recommended range More Info
smtp mail.mydomain.com Reverse DNS does not match SMTP Banner More Info
smtp mail.mydomain.com Warning - Does not support TLS. More Info
smtp mail.mydomain.com 15.141 seconds - Not good! on Transaction Time

Maybe try with

http://dnscheck.pingdom.com/

and

You can check a subdomain with these.

At dnsstuff.com I get :

SOA record check: No nameservers provided an SOA record for the zone. You should configure your nameservers to have a master slave relationship. The update of the zone information to the slave nameservers should be handled through the SOA record.

MX records check: No MX records exist within the zone. This is legal, but if you want to receive E-mail on this domain, you should have MX record(s). The program can’t continue in a case like this, so we are assuming you don’t receive mail on this domain.

On dnscgeck.pingdom.com I get :

Delegation not found at parent.: No delegation could be found at the parent, making your zone unreachable from the Internet.

Not enough nameserver information was found to test the zone sub.domain.com, but an IP address lookup succeeded in spite of that.

It's worth noting that once you issue a certificate from Let's Encrypt, this domain will be publicly (and permanently) exposed on the certificate transparency list. For the time being, using other CAs will avoid placement on this list, but that will change early 2018 when all public CA-signed certificates will be added to this list.

@jared.m
Thank you for the information but, can you explain me what the transparency list is about? Sorry I am a bit newbie on this kind of stuff.

Certificates issued by publicly-trusted CAs are treated as a sort of public record by several companies, and will soon be treated as such in general. The certificate transparency logs are a public record of issued certificates designed to provide increased security around several key aspects of the certificate infrastructure at large. For example, it makes it extremely difficult for someone to issue a certificate for a domain you own without the ability for you to be aware of this. It also limits the stealthiness with which a rogue CA could operate under while issuing unauthorized and/or malicious certificates. More information is available here: https://www.certificate-transparency.org/

One site that can query the certificate transparency logs is https://crt.sh. For example, to see all the certificates issued for this forum, you can search for community.letsencrypt.org. Once you issue a Let’s Encrypt certificate, that certificate (and all domains included) will be logged here as well, and visible to anyone just querying the full logs.

It’s not a bad idea, if you’re particularly concerned about malicious certificate issuance, to peruse this list for your own domains from time to time and ensure that all issued certificates were indeed authorized.

2 Likes

I know there have been some false positives about this, but it seems like those SOA errors could also be causing the problem.

There is a tool that replicates what Let’s Encrypt does in trying to look up your domain name at

https://unboundtest.com/

It provides a lot of technical information which can be pretty hard to understand, but you can also see whether it seems to complain about the same problem.

I runned the tool and it didn’t give me any errors at all. I also contacted namecheap and they didn’t find anything wrong with the DNS.

Unfortunately, I doubt that we can find a way to help you further without knowing the domain name.

Seems like it had to do with the guide or the commands from the guide that I used. Followed this guide https://www.linuxbabe.com/linux-server/install-lets-encrypt-free-tlsssl-certificate-nginx-debian-8-server going with the standalone installation and it worked like a charm.

Thanks again for your support

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