Webroot plugin's http request does not resolve to ip address placed in directory by Certbot

Running 4 Docker containers (MySQL, Wordpress, NGNIX and Certbot) on an EC2. FQD is coldhalo.com. This is well used code from Digital Ocean that provisions a Wordpress site. The A record on the FQD (via registrar GoDaddy) clearly associates coldhalo.com with the public ip on the EC2 (54.198.253.252) and the visual propagation tool: DNSMap - Worldwide DNS Propagation Checker - Global test clearly shows this. Moreover, readily navigate to coldhalo.com. So, no issue with DNS resolution.

All containers start and run with exception of certbot. Certbot initially executes with, "Attaching to certbot, db, webserver, wordpress" then stops and gives the, "exited (1)" error. Followed by, "there is a problem with the address." The Certbot should exit at (0). The , "there is a problem with the address" message means that the HTTP request made by the webroot plugin to verify coldhalo.com is for some reason not being associated with the file inserted in to the webroot directory (html). Yet, a standard DNS query for coldhalo.com clearly resolves to the EC2 instance at 54.198.253.252

Any thoughts are greatly appreciated.

My domain is:www.coldhalo.com

I ran this command:docker compose up

It produced this output: Exit (1)

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

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

My hosting provider, if applicable, is: Platform = AWS EC2

I can login to a root shell on my machine (yes or no, or I don't know):Y

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

The Certbot webroot plugin does no such thing. It does not verify anything, it simply places a file at the designated path. Nothing more, nothing less. All verification which requires a lookup of the hostname is done by the ACME server.

Please provide the actual error with the context around it please, because due to the fact you've got the above concept incorrect, I think there might be some other incorrect conclusions.

2 Likes

No, it doesn't:

 ✘ dan@Dan-MacBook-Pro-2019  ~  dig coldhalo.com

; <<>> DiG 9.10.6 <<>> coldhalo.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59098
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;coldhalo.com.                  IN      A

;; ANSWER SECTION:
coldhalo.com.           3600    IN      A       54.198.253.232

;; Query time: 116 msec
;; SERVER: 10.1.42.1#53(10.1.42.1)
;; WHEN: Tue Sep 10 08:05:54 EDT 2024
;; MSG SIZE  rcvd: 57

Note that the last octet is 232, not 252.

Edit: I can't, of course, speak to what your dashboard may be showing--but this is what the public DNS is reporting. I suspect this is a simple typo, but that's just an informed guess on my part.

5 Likes

A curl like the HTTP Challenge sees a server identifying as nginx 1.15.12. Not v1.24

curl -i http://coldhalo.com/.well-known/acme-challenge/Test404
HTTP/1.1 404 Not Found
Server: nginx/1.15.12

Maybe this is related to what Dan said about the DNS. Or maybe something else. In any case something seems off.

3 Likes

You are right. It was a typo. The last octet is 232.

1 Like

Thanks for your reply Osiris. The problem might be related to AWS. I am trying this on the AWS t2. micro free tier and the experience has been rocky. In addition to the Certbot problem, the site crashes for no reason. Then, must restart all the containers. I am heading over to Digital Ocean and will try my luck there with a paid account. Thanks again. I'll be back with an update.

1 Like

Yea, that is good to know. Now, I am thinking there are two web servers running: 1 in the container and 1 on the EC2. Thanks.

2 Likes

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