Certbot failed to authenticate some domains

Help
1

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. https://crt.sh/?q=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: node-4.mv.sovnet.nchain.cloud

I ran this command: sudo certbot --nginx -d node-4.mv.sovnet.nchain.cloud

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for node-4.mv.sovnet.nchain.cloud

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
  Domain: node-4.mv.sovnet.nchain.cloud
  Type:   connection
  Detail: 54.246.253.78: Fetching http://node-4.mv.sovnet.nchain.cloud/.well-known/acme-challenge/kgmja_1afm5-ywyOCiBFFZBFtCj3lBNeN3jDQvJFf3Y: Connection refused

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.22.1

The operating system my web server runs on is (include version): cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" NAME="Debian GNU/Linux" VERSION_ID="12" VERSION="12 (bookworm)" VERSION_CODENAME=bookworm ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/"

My hosting provider, if applicable, is: AWS

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): certbot 2.1.0

Part of /var/log/letsencrypt/letsencrypt.log file:

2025-02-24 15:24:45,260:DEBUG:acme.client:Storing nonce: ozgn15WXm9kfluLODd4QJ8hR39Kf0v2VWYl1knVEeNALchFtCEs
2025-02-24 15:24:45,260:INFO:certbot._internal.auth_handler:Challenge failed for domain node-4.mv.sovnet.nchain.cloud
2025-02-24 15:24:45,260:INFO:certbot._internal.auth_handler:http-01 challenge for node-4.mv.sovnet.nchain.cloud
2025-02-24 15:24:45,260:DEBUG:certbot._internal.display.obj:Notifying user:
Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
  Domain: node-4.mv.sovnet.nchain.cloud
  Type:   connection
  Detail: 54.246.253.78: Fetching http://node-4.mv.sovnet.nchain.cloud/.well-known/acme-challenge/kgmja_1afm5-ywyOCiBFFZBFtCj3lBNeN3jDQvJFf3Y: Connection refused
2

The HTTP Challenge (which --nginx uses) requires your domain to respond to an HTTP request on port 80. Your domain is not responding to any HTTP requests on that port not even for your "home" page.

Check your EC2 Security Group, any VPC ACL Rules, and o/s firewalls. Also check that the IP in the DNS is your current public IP address for that EC2 instance.

Let's Debug is a good tool to test changes you make: Let's Debug

Another site to test world-wide connectivity: Check website performance and response : Check host - online website monitoring

1 Like
3

My node-4.ngnix config:

upstream registration-node-4 {
    server test-node-4.sovnet:8082;
}

upstream funding-node-4 {
    server test-node-4.sovnet:8083;
}

server {
    server_name node-4.mv.sovnet.nchain.cloud;
    listen 80;
    listen [::]:80;

    location /user_registration {
        proxy_set_header Host $host;
        proxy_pass http://registration-node-4;
    }

    location /funding {
        proxy_set_header Host $host;
        proxy_pass http://funding-node-4;
    }
    client_max_body_size 1G;
    proxy_buffering off;
    proxy_request_buffering off;
}
4

Regarding security groups, the EC2 instance uses the same security group as other instances. Please see the screenshot.

image
image2029×837 88.9 KB

5

Firewall is inactive on the instance:

sudo ufw status
Status: inactive
6 
sudo dig  node-4.mv.sovnet.nchain.cloud

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> node-4.mv.sovnet.nchain.cloud
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62353
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;node-4.mv.sovnet.nchain.cloud. IN      A

;; ANSWER SECTION:
node-4.mv.sovnet.nchain.cloud. 300 IN   CNAME   ec2-54-74-191-59.eu-west-1.compute.amazonaws.com.
ec2-54-74-191-59.eu-west-1.compute.amazonaws.com. 20 IN A 192.168.101.131

;; Query time: 20 msec
;; SERVER: 192.168.0.2#53(192.168.0.2) (UDP)
;; WHEN: Mon Feb 24 16:19:39 UTC 2025
;; MSG SIZE  rcvd: 136
7

Instance's private IP address: 192.168.101.131
Instance's public IP address: 54.74.191.59

8 
nslookup 54.74.191.59
59.191.74.54.in-addr.arpa       name = ec2-54-74-191-59.eu-west-1.compute.amazonaws.com.

nslookup 192.168.101.131
131.101.168.192.in-addr.arpa    name = ip-192-168-101-131.eu-west-1.compute.internal.
9

We are not a general purpose forum for helping setup your comms config. We often identify connectivity problems but you may need to seek help on fixing that elsewhere. Perhaps some other volunteer will offer help anyway. But, I don't have any further suggestions than what I have said.

Are you able to connect to your domain from a different machine on the public internet?

Like

curl -i http://node-4.mv.sovnet.nchain.cloud

Because, as I showed with the earlier links no one seems able to connect using HTTP port 80.

2 Likes
10

Nothing in VPC ACL rules prevents connections.

12

No, I'm not able to connect to the domain from a different machine on the public internet:

curl -i http://node-4.mv.sovnet.nchain.cloud
curl: (7) Failed to connect to node-4.mv.sovnet.nchain.cloud port 80 after 218 ms: Couldn't connect to server
13

Well, now you know what to fix first :slight_smile: Once you get that working try getting a cert again.

2 Likes
14

I've solved the problem. Please close this topic. Thank you for your help.

15

You can close the topic by marking the most helpful post as the Solution.

There should be a checkbox item on the bottom of each post.

If it was something different, it would be helpful for you to describe briefly what was needed so can help future people.

3 Likes
16

I made mistake in defining Route53 DNS record for my instance. Once I fixed that, nginx worked. Sorry for bothering.

2 Likes