New Certificate Failed to Create (DNS Check ok)

Help
1

I am trying to create a new certificate for an Ubuntu server as a reverse proxy (NGINX). I have used letsdebug.net to test with only DNS-01 passed. The firewall is managed by another party and it is likely acme-protocol issue for port 80 traffic. The log is basically fine with creation of .well-known/... testing data. So, I am trying to use DNS to do the challenge. What's wrong for my settings? (NGINX, standalone - same result)

My domain is: clientservice.archcloudcomputing.org

I ran this command: sudo certbot certonly --nginx -d clientservice.archcloudcomputing.org --preferred-challenges dns

https://letsdebug.net/ Testing with DNS-01 OK, HTTPS-01 failed, TLS-ALPN-01 failed.

It produced this output:

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 1.18

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

My hosting provider, if applicable, is:

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

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

1 Like
2

Those command options conflict. I am surprised there is no error message.

The --nginx option uses the nginx plug-in which uses the HTTP challenge. It takes priority over the --preferred-challenges option (at least in my quick test)

The Let's Debug test for http challenge fails.

I am signing off for night but someone else can help if this isn't enough to help you.

Note: standalone also uses HTTP challenge.

See also:
https://eff-certbot.readthedocs.io/en/stable/using.html#dns-plugins

3 Likes
3

Oh, it looks like you are affected by a firewall that blocks requests using the "user agent" of Let's Encrypt. The HTTP challenge is often easier than the DNS one so adjusting your firewall may be the easiest way forward.

See these example ACME challenge requests. The first failed with 404 Not Found as it should because the SampleToken does not exist. The second with the LE user agent fails with "reset by peer"

curl -I clientservice.tvb.com.hk/.well-known/acme-challenge/SampleToken
HTTP/1.1 404 Not Found
Server: nginx/1.18.0 (Ubuntu)
Date: Wed, 22 Jun 2022 04:05:18 GMT
Content-Type: text/html
Content-Length: 162
Connection: keep-alive

curl -I clientservice.tvb.com.hk/.well-known/acme-challenge/SampleToken -A "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
curl: (56) Recv failure: Connection reset by peer

We had similar issues with Palo Alto brand firewalls recently due to an Application setting they call the "acme challenge". Disabling that allowed it to work. Your symptom is a little different but may be related.

3 Likes
4

Thanks for your reply. If there is no certificate being created, I am not sure there is a SampleToken created.

2 Likes
5

I'm not 100% certain about that...
It might just use the nginx installer and NOT the authenticator.
But without --manual, I don't see how certbot could process the --preferred-challenges dns request.

But certonly does limit the --nginx to installer only.

So... this is a weird request command.

3 Likes
6

Thanks. You're right. So, I may ask the administrator to add the DNS records for _acme-challenge with the token value.

2 Likes
8

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