Certbot failed to authenticate some domains (authenticator: nginx)

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. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: du.dubclub.wibn

I ran this command: sudo certbot --nginx

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Which names would you like to activate HTTPS for?


1: mj.dubclub.win


Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 1
Requesting a certificate for mj.dubclub.win

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Domain: mj.dubclub.win
Type: unauthorized
Detail: Invalid response from http://mj.dubclub.win/.well-known/acme-challenge/omMEM_wBFUqS6_VZyZHF-cVjhnwa6l1yQAXqsfeAtFg [2600:3c03::f03c:93ff:febb:cb54]: 404

Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible from the internet.

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

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

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

My hosting provider, if applicable, is: Linode

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

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

I can get the root website page (based on the IP Address) from another machine with ipV4 and ipV6 but cerbot can't seem to get a good response on ipV6

From the LOG:

      "validationRecord": [
        {
          "url": "http://mj.dubclub.win/.well-known/acme-challenge/N9o5JfdhFO30pv_RkHAr_zByifXOghXDrOu1dYFEfh8",
          "hostname": "mj.dubclub.win",
          "port": "80",
          "addressesResolved": [
            "172.104.10.135",
            "2600:3c03::f03c:93ff:febb:cb54"
          ],
          "addressUsed": "2600:3c03::f03c:93ff:febb:cb54"
        }

From ip addr

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether f2:3c:93:bb:cb:54 brd ff:ff:ff:ff:ff:ff
    inet 172.104.10.135/24 brd 172.104.10.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2600:3c03::f03c:93ff:febb:cb54/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 5209sec preferred_lft 1609sec
    inet6 fe80::f03c:93ff:febb:cb54/64 scope link
       valid_lft forever preferred_lft forever

Both ipv6 and ipv4 return the same home page which is a modified nginx "it works" page so connectivity is there and the addresses are valid. Not sure why certbot is failing.

Same sort of issue on another linode (du.dubclub.win). These are 2 of 3 clones that I created today, first one was no problems before noon, these two were after 8pm and failing the same way.

1 Like

Welcome to the community @boatcoder

What was the domain that worked? Might help to see diffs.

I don't see the same response from IPv4 or IPv6. Certbot talks to the Let's Encrypt Server. That LE Server will use IPv6 if an AAAA record exists for that domain. For mj.dubclub.win there is an AAAA record. I see this:

curl -I4 mj.dubclub.win/.well-known/acme-challenge/ForumTest
HTTP/1.1 404 Not Found
Server: nginx/1.18.0 (Ubuntu)
Date: Fri, 08 Apr 2022 02:19:42 GMT
Content-Type: text/html
Content-Length: 179
Connection: keep-alive
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: same-origin
Content-Security-Policy: script-src 'self' 'unsafe-inline' cdn.jsdelivr.net cdnjs.cloudflare.com www.googletagmanager.com browser.sentry-cdn.com polyfill.io js.stripe.comi static.woopra.com
Content-Security-Policy: font-src 'self' fonts.googleapis.com fonts.gstatic.com cdnjs.cloudflare.com

curl -I6 mj.dubclub.win/.well-known/acme-challenge/ForumTest
HTTP/1.1 404 Not Found
Server: nginx/1.18.0 (Ubuntu)
Date: Fri, 08 Apr 2022 02:19:47 GMT
Content-Type: text/html
Content-Length: 162
Connection: keep-alive

They are both "not found" but much different responses (both the headers shown here and index pages when those are requested).

We can look at other stuff but this is good place to start

3 Likes

ytc.dubclub.win worked

Looks like ipv6 routing is messed up outside of Linode. I was using curl from one linode to another in the same data center. Starting to smell like a linode routing issue

Hmmm. I get diff responses from ytc.dubclub.win too

curl -I4 http://ytc.dubclub.win
HTTP/1.1 301 Moved Permanently
Server: nginx/1.18.0 (Ubuntu)
Date: Fri, 08 Apr 2022 02:32:54 GMT
Content-Type: text/html
Content-Length: 178
Connection: keep-alive
Location: https://ytc.dubclub.win/

curl -I6 http://ytc.dubclub.win
HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Fri, 08 Apr 2022 02:32:59 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Fri, 27 Aug 2021 03:39:51 GMT
Connection: keep-alive
ETag: "61285e87-264"
Accept-Ranges: bytes

Similarly odd responses to httpS://ytc... with IPv4 and 6. IPv4 returns http 200 status with valid cert. IPv6 returns http 200 but invalid cert (self-signed). And, also different data. One is a simple Welcome page and one is an elaborate dubclub page.

3 Likes

You went after totally different URLs on those 2 machines, since certbot is not currently running why would the .well-known url be functional?

I'm seeing:

curl http://[2600:3c03::f03c:93ff:febb:cb54]
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>Hey certbot!  I'm legit, lets do this OK?</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

and

root@localhost:~# curl http://172.104.10.135
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>Hey certbot!  I'm legit, lets do this OK?</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Out of their datacenter in Germany which might still show something different but your first two URLS don't make sense while the cerbot is not running. The word well does not appear in any of my nginx files on ytc or on mj

Doing curl directly to the IP address will "fall into" the default server, if any, in nginx. If you use the form I used (curl -4 url with the domain name) you will get the SNI matched server block in nginx.

For example, I get different responses to:

curl -4 http://mj.dubclub.win
<!DOCTYPE html>

<html lang="en-US" dir="ltr">

  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no">


    <!-- ===============================================-->
    <!--    Document Title-->
    <!-- ===============================================-->
    <title>Welcome to DubClub</title>
(... much more omitted for brevity ...)

curl -4 http://172.104.10.135
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
(... a little more omitted for brevity ...)

It doesn't really matter whether I use the acme-challenge path in the request at this stage. The nginx server should respond the same for IPV4 and V6 and it does not.

Or, just remove the AAAA records from the DNS to be IPv4 only for now. That would simplify things.

If you want, post your nginx config by showing result of this command.

sudo nginx -T
4 Likes

I am signing off for the night but I just realized you probably have the wrong listen directives in your nginx server block. I don't think you are listening for IPv6. You should have something like:

listen 80;
listen [::]:80;

Something similar for port 443 server. Good chance this is what is causing your problems. If that doesn't help, post results of sudo nginx -T

3 Likes

This was indeed the problem. What I can't understand is how ytc didn't have the SAME problem, but that's OK. It's working now. Muchas Gracias!

3 Likes

That's probably because it's the default server.

3 Likes

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