Certificate renewal not working but challenge/response is flowing

My domain is: www.colonialwarstn.org

I ran this command: dehydrated -f config -c --force --force-validation

It produced this output: # INFO: Using main config file config
Processing www.colonialwarstn.org

My web server is (include version): f5-bigip front ending NGINX

The operating system my web server runs on is (include version): RHEL9 or Ubuntu 24, depending on F5 Load Balance decision

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

I have full logging of traffic running. I see a series of ip addresses connecting to http://www.colonialwarstn.org/.well-known/acme-challenge/uhXVc8MvIgFghpkQAyAQL_3WawZq5vrKc8P7WNSlcPc ( or whatever the challenge key gets assigned ). I see the traffic flowing into my network and the response being sent:
Apr 2 12:44:47 i2800.f5sec.com info tmm[11660]: Rule /Common/rule_le_challenge <HTTP_REQUEST>: HTTP Request to colonialwarstn.org /.well-known/acme-challenge/uhXVc8MvIgFghpkQAyAQL_3WawZq5vrKc8P7WNSlcPc from: 66.133.109.36
Apr 2 12:44:47 i2800.f5sec.com info tmm[11660]: Rule /Common/rule_le_challenge <HTTP_REQUEST>: Key Found: Responding with uhXVc8MvIgFghpkQAyAQL_3WawZq5vrKc8P7WNSlcPc.PrbRwed0zwLCwpnCocBNBozEmANWPXhHmCbA59j1c8o

This repeats several times but never results in a certificate. This system worked in January and no changes have been made.

Is there a way to see the letsencrypt side of this transaction to determine what they are not receiving that they want?

Also, I did a clean install of the setup on a new server and I get the same results.

The problem is not that the HTTP challenge fails but that the CAA lookup after it succeeds is failing. Let's Encrypt must ensure any CAA record allows it to issue for that domain. CAA is explained here: Certificate Authority Authorization (CAA) - Let's Encrypt

There are several problems with your DNS configuration. I think these are best explained using the DNSViz tool here: www.colonialwarstn.org | DNSViz

Concentrate on the messages in the Errors section.

The problem is also reproduced using this tool but the errors are much harder to determine. I mention this mostly for benefit of other volunteers who may want to add comments. See: https://unboundtest.com/

4 Likes

Thank you. I literally just completed deployment of CAA records in the zones and it did work. I guess I was surprised that I had to create CAA records in order to do an HTTP validation. It is likely that I once had this set up at some point in the past but there was a glitch with a redhat server in my basement.

Thank you for the reply. It is working and your analysis was spot on.

1 Like

CAA records are not required. But, LE needs to check for them. If you don't have CAA records your DNS servers must still respond with a valid "not found" response in a reasonable time. They were not. This was more fully explained in that CAA link I provided.

Your DNS config has problems you should still resolve. I am surprised it works. The unboundtest site fails querying for CAA and DNSViz reports the same problems.

This google DNS query tool reports a SERVFAIL. There is more you should look at for a stable system:

4 Likes