Error in validation on --force-renewal and --dry-run

[driggsss]

I am having trouble testing the renewal of certificate. I do not have any web server running so I am running this script to get my initial certificate.

certbot certonly --standalone --agree-tos -d testinv3.southeastasia.cloudapp.azure.com

Afaik, this will spin up a temporary web server for cert validation right?

However when I try to renew the cert (--dry-run or --force-renewal just to test)

sudo certbot certonly --standalone --force-renewal -n --agree-tos -d testinv3.southeastasia.cloudapp.azure.com

I am encountering this error:

http-01 challenge for testinv3.southeastasia.cloudapp.azure.com
Waiting for verification...
Challenge failed for domain testinv3.southeastasia.cloudapp.azure.com
http-01 challenge for testinv3.southeastasia.cloudapp.azure.com
Cleaning up challenges
Some challenges have failed.

Here is my letsencrypt.log

2023-05-04 02:03:10,701:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Date: Thu, 04 May 2023 02:03:10 GMT
Content-Type: application/json
Content-Length: 1162
Connection: keep-alive
Boulder-Requester: 1007053077
Cache-Control: public, max-age=0, no-cache
Link: https://acme-v02.api.letsencrypt.org/directory;rel="index"
Replay-Nonce: 853FJW7Ofg4WkiX9b5RD4eTULVMCfOEZ2qSZ4QxmkDqGLXg
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

{
"identifier": {
"type": "dns",
"value": "testinv3.southeastasia.cloudapp.azure.com"
},
"status": "invalid",
"expires": "2023-05-11T02:02:59Z",
"challenges": [
{
"type": "http-01",
"status": "invalid",
"error": {
"type": "urn:ietf:params:acme:error:connection",
"detail": "20.212.38.183: Fetching http://testinv3.southeastasia.cloudapp.azure.com/.well-known/acme-challenge/TIsJRNn-WyV5potB34-6Gy6wquKEITe5uglZTDksGZ4: Timeout during connect (likely firewall problem)",
"status": 400
},
"url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/224764802077/9ij_qg",
"token": "TIsJRNn-WyV5potB34-6Gy6wquKEITe5uglZTDksGZ4",
"validationRecord": [
{
"url": "http://testinv3.southeastasia.cloudapp.azure.com/.well-known/acme-challenge/TIsJRNn-WyV5potB34-6Gy6wquKEITe5uglZTDksGZ4",
"hostname": "testinv3.southeastasia.cloudapp.azure.com",
"port": "80",
"addressesResolved": [
"20.212.38.183"
],
"addressUsed": "20.212.38.183"
}
],
"validated": "2023-05-04T02:02:59Z"
}
]
}

Is having a different public IP of the VM from when I created the cert and to when I renew the cert okay? Since the current setup, the public IP is not set to static. So everytime I stop/start the VM different IP would be used.

[MikeMcQ]

@driggsss

So everytime I stop/start the VM different IP would be used.

That is not a problem as long as the DNS also points to the new IP. Does it?

And, to renew a cert you just use certbot renew and to test certbot renew --dry-run

The renew command reads all the config files in /etc/letsencrypt/renewal and renews them all using the same settings as when their certs were last successful. A cronjob or systemd timer was probably setup by Certbot to run a renew command regularly so these are done automatically.

[driggsss]

@MikeMcQ

That is not a problem as long as the DNS also points to the new IP. Does it?

Yes it still points to the new IP.

@MikeMcQ

And, to renew a cert you just use certbot renew and to test certbot renew --dry-run

I tried this certbot renew --dry-run but still challenge failed error.

[MikeMcQ]

Could there be a different firewall or network settings on this IP than the other one?

--standalone is harder to debug since it needs to be running to try to connect to it.

You can do

certbot certonly --standalone -debug-challenges -v -d testinv3.southeastasia.cloudapp.azure.com

Then, it will pause and show you the URL it is expected to see. Leave it paused and open another window or a device outside that network and try that URL

If you do it quick and post the URL here I may have time to check it from my network

A timeout error means the Let's Encrypt server cannot reach that domain name using HTTP to prove you control that domain. Usually a firewall but other things can cause that.

[driggsss]

@MikeMcQ

Then, it will pause and show you the URL it is expected to see. Leave it paused and open another window or a device outside that network and try that URL

Sorry, what URL am I looking for in this?

[MikeMcQ]

Choose Cancel. I wasn't expecting that.

Please first show what certs you already have with output of this. Can you please copy/paste results into this forum? Very hard to read or work with images

sudo certbot certificates

[driggsss]

I tried opening port 80, 443 to all IP. Then i retry certbot renew --dry-run it worked! However for production purposes, how can I whitelist the needed IP/DNS for the validation in the renewal?

Here is my certificates

[MikeMcQ]

Sorry, my mistake. It should have been --debug-challenges with two dashes not one. With just one dash it thought you were adding a second domain name of ebug-challenges. Was hard to read your pasted image but my fault for not testing the sample command.

But, glad you found the error.

Let's Encrypt does not publish a list of IP addresses. See the FAQ item about this and also what they recommend about port 80

FAQ - Let's Encrypt

Best Practice - Keep Port 80 Open - Let's Encrypt

[driggsss]

@MikeMcQ

Sorry, my mistake. It should have been --debug-challenges with two dashes not one. With just one dash it thought you were adding a second domain name of ebug-challenges. Was hard to read your pasted image but my fault for not testing the sample command.

Oops. Sorry I did not double check also the script lol. Idk about keeping port 80/443 open most of the time (Maybe I will just do this manually when cert is already up for renewal). However, since i do not have any webserver in this VM maybe it is okay? Spinning up a temp web server is usually just done on the renewal/creating cert right.

[rg305]

@driggsss

Idk about keeping port 80/443 open

Only 80 needs to be kept open.
And since you are using --standalone, there shouldn't be anything listening on that port [when certbot is not running].