Error getting validation data

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. crt.sh | 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:
wx.schamschula.com
I ran this command:
/usr/local/bin/certbot renew --reuse-key -v
It produced this output:
Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Domain: wx.schamschula.com
Type: connection
Detail: 173.25.40.112: Fetching http://wx.schamschula.com/.well-known/acme-challenge/ZJr7wv9uWUDYPKKGeyUjXsPC824pfEVKwNTMmmRtycc: Error getting validation data

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.

Cleaning up challenges
Failed to renew certificate wx.schamschula.com with error: Some challenges have failed.

All renewals failed. The following certificates could not be renewed:
/usr/local/etc/letsencrypt/live/wx.schamschula.com/fullchain.pem (failure)

1 renew failure(s), 0 parse failure(s)

My web server is (include version):
nginx version: nginx/1.28.0
The operating system my web server runs on is (include version):
FreeBSD 15.0-RELEASE releng/15.0-n280995-7aedc8de6446 GENERIC amd64
My hosting provider, if applicable, is:
N/A
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):
py311-certbot-4.2.0,1
Name : py311-certbot
Version : 4.2.0,1

py311-certbot-nginx-4.2.0_1
Name : py311-certbot-nginx
Version : 4.2.0_1

This used to work correctly using a cron job (w/o the -v). I have made no changes to the web server file structure. I placed a trivial html file (foo.html) in /.well-known/acme-challenge/ and can request it locally and remotely from the internet. I temporarily disable ipfw when running the certbot update. I also disabled the IP block list to make sure I wasn't inadvertently blocking the certbot host. As the update was running, I never saw the certbot created file in the acme-challenge directory.

Is it possible that certbot-nginx is not saving the file in the correct location?

The other possibility is that the recent update to FreeBSD 15.0-RELEASE broke something. I have not updated my public server (wx.aamu.edu) from FreeBSD 14.3-RELEASE. It seems to be correctly updating its certificates using the same version of certbot[-nginx].

2

P.S. Checking / will either redirect you to www.schamschula,com (a different hosted server) or give you a 403 error. This is intentional. This is a private server. If you want to test please use the wx.schamschula.com/.well-known/acme-challenge/foo.html. When I ssh into the above server, I can request the file using curl and http. https fails as the certificate has expired. I have noticed that there have been request attempts for foo.html that also returned a 403 error. I'm looking into that: it looks like I had accidentally reenabled the IP block list.

3

The --nginx authenticator you are using does not create a challenge file. Instead, it makes a temp change to your nginx config and places a "return" statement there with the correct response. You cannot test that by using your own test file in the /.well-known/... directory.

You can see these temp changes in Certbot's log in /var/log/letsencrypt

Certbot puts these temp changes in an nginx server block with the same domain name as in the cert request. And, it updates both port 80 and port 443 server blocks. If nginx is running on different ports you can override these and you'd know if you did that. That is only needed if you are doing some kind of port forwarding in front of nginx.

If you post the Certbot log we can take a look. Otherwise carefully review your nginx config to ensure there were no other changes to the server blocks - especially the listen statements and server_name

Something else that can happen is if your nginx takes a long time to reload (more than 1 second). After Certbot makes the temp change it reloads nginx and waits 1 second (by default). That is because the reload is asynchronous. But, if you need longer than 1s the error is usually a "404" and not the one you are seeing.

2 Likes
4

No changes until I started looking for the broken path. I have reverted them. I'd rather not share nginx.conf. But here is the tail of the letsencrypt log

2026-01-07 16:24:23,102:DEBUG:acme.client:JWS payload:
b'{}'
2026-01-07 16:24:23,108:DEBUG:acme.client:Sending POST request to https://acme-v02.api.letsencrypt.org/acme/chall/473966670/639428230646/a_2gZA:
{
  "protected": "eyJhbGciOiAiUlMyNTYiLCAia2lkIjogImh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL2FjY3QvNDczOTY2NjcwIiwgIm5vbmNlIjogIklpanphZGxTb3lLTXNPZnF4NVE1bHVKNERfSzk2dWF4a1B5NXZCamdwSlhKVU40bE1HSSIsICJ1cmwiOiAiaHR0cHM6Ly9hY21lLXYwMi5hcGkubGV0c2VuY3J5cHQub3JnL2FjbWUvY2hhbGwvNDczOTY2NjcwLzYzOTQyODIzMDY0Ni9hXzJnWkEifQ",
  "signature": "c5a2nZBsj6gyvb64hznNU9MKKHxk8xRIlbo-PheGcaeO6F3gVnoEUB2JRWRKP78iIU9o7P7qdSBG1yOIojOrO8bk2CuoTKdiq3Vi7fzBE2F_bXYDUjFMqkB4siFPriSr1MCh-7u1A5-PbAj-hA2rSG_zNIkENU0r8WFxW0KCzI6RiJA4p8vkO7FqBpQD_amBBmD2PVLKhVv34srfmfLnwOPAr-Tn1v_n5t-Hgy1me7a_v7nDpuXX08G4tvimTnIQ-SO6N4zKAkHB5xs3wEzHUjAgKcmEJ-TQG_qkELMFpHGpH2ZjBSyv1xRK_aPPev7QSPv1tQ4OopFjPJEwmpPuLQ",
  "payload": "e30"
}
2026-01-07 16:24:23,166:DEBUG:urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 "POST /acme/chall/473966670/639428230646/a_2gZA HTTP/1.1" 200 194
2026-01-07 16:24:23,167:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Date: Wed, 07 Jan 2026 22:24:23 GMT
Content-Type: application/json
Content-Length: 194
Connection: keep-alive
Boulder-Requester: 473966670
Cache-Control: public, max-age=0, no-cache
Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index", <https://acme-v02.api.letsencrypt.org/acme/authz/473966670/639428230646>;rel="up"
Location: https://acme-v02.api.letsencrypt.org/acme/chall/473966670/639428230646/a_2gZA
Replay-Nonce: IijzadlSiMz6O0fEHALjXA6tTNnjcM2ZxyDzTyNIiKDkP62zOGY
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

{
  "type": "http-01",
  "url": "https://acme-v02.api.letsencrypt.org/acme/chall/473966670/639428230646/a_2gZA",
  "status": "pending",
  "token": "PDvWAv_GQNdjYA8gifhYSVYzE1tX7eR0tHsmwObgMpo"
}
2026-01-07 16:24:23,168:DEBUG:acme.client:Storing nonce: IijzadlSiMz6O0fEHALjXA6tTNnjcM2ZxyDzTyNIiKDkP62zOGY
2026-01-07 16:24:23,169:INFO:certbot._internal.auth_handler:Waiting for verification...
2026-01-07 16:24:24,169:DEBUG:acme.client:JWS payload:
b''
2026-01-07 16:24:24,173:DEBUG:acme.client:Sending POST request to https://acme-v02.api.letsencrypt.org/acme/authz/473966670/639428230646:
{
  "protected": "eyJhbGciOiAiUlMyNTYiLCAia2lkIjogImh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL2FjY3QvNDczOTY2NjcwIiwgIm5vbmNlIjogIklpanphZGxTaU16Nk8wZkVIQUxqWEE2dFRObmpjTTJaeHlEelR5TklpS0RrUDYyek9HWSIsICJ1cmwiOiAiaHR0cHM6Ly9hY21lLXYwMi5hcGkubGV0c2VuY3J5cHQub3JnL2FjbWUvYXV0aHovNDczOTY2NjcwLzYzOTQyODIzMDY0NiJ9",
  "signature": "arACGymgiuRfrqIzSC_ABiPhTx7En-3jlrBa272qS8dEUfpxfStdnXUdMzi2bBYCe_4_EoPzYIs4sGh5pr9zds0PE72X5prKSjVRIsMbfas7Fug0MPPhz3DOjPg54I1bFIZLnVGQMIbGvG9p7lKOOtCpxMCkflHKc6R5PuIiyGoMSdw-8PmwLG2U23hgwMi58wGOOYq4YCrZWHC0scF4PsfO58GEv8Sfcs7fH0Z_-cmIosV8-rBPy0LMFvPOV-ldm3uh45sxzY3FdxSuUgDu8vljweoPfiVaOtmLX37viFRG16COLP_6gDNpfDf15R1V7FG2588Lq95MIfU3KZ2Bxw",
  "payload": ""
}
2026-01-07 16:24:24,229:DEBUG:urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 "POST /acme/authz/473966670/639428230646 HTTP/1.1" 200 1058
2026-01-07 16:24:24,230:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Date: Wed, 07 Jan 2026 22:24:24 GMT
Content-Type: application/json
Content-Length: 1058
Connection: keep-alive
Boulder-Requester: 473966670
Cache-Control: public, max-age=0, no-cache
Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
Replay-Nonce: IijzadlSVJVBrOUQEbgItMclQjOqbdwo-4T95ZJVwrHOSvaWaRc
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

{
  "identifier": {
    "type": "dns",
    "value": "wx.schamschula.com"
  },
  "status": "invalid",
  "expires": "2026-01-14T22:24:21Z",
  "challenges": [
    {
      "type": "http-01",
      "url": "https://acme-v02.api.letsencrypt.org/acme/chall/473966670/639428230646/a_2gZA",
      "status": "invalid",
      "validated": "2026-01-07T22:24:23Z",
      "error": {
        "type": "urn:ietf:params:acme:error:connection",
        "detail": "173.25.40.112: Fetching http://wx.schamschula.com/.well-known/acme-challenge/PDvWAv_GQNdjYA8gifhYSVYzE1tX7eR0tHsmwObgMpo: Error getting validation data",
        "status": 400
      },
      "token": "PDvWAv_GQNdjYA8gifhYSVYzE1tX7eR0tHsmwObgMpo",
      "validationRecord": [
        {
          "url": "http://wx.schamschula.com/.well-known/acme-challenge/PDvWAv_GQNdjYA8gifhYSVYzE1tX7eR0tHsmwObgMpo",
          "hostname": "wx.schamschula.com",
          "port": "80",
          "addressesResolved": [
            "173.25.40.112"
          ],
          "addressUsed": "173.25.40.112"
        }
      ]
    }
  ]
}
2026-01-07 16:24:24,230:DEBUG:acme.client:Storing nonce: IijzadlSVJVBrOUQEbgItMclQjOqbdwo-4T95ZJVwrHOSvaWaRc
2026-01-07 16:24:24,231:INFO:certbot._internal.auth_handler:Challenge failed for domain wx.schamschula.com
2026-01-07 16:24:24,232:INFO:certbot._internal.auth_handler:http-01 challenge for wx.schamschula.com
2026-01-07 16:24:24,232:DEBUG:certbot._internal.display.obj:Notifying user: 
Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
  Domain: wx.schamschula.com
  Type:   connection
  Detail: 173.25.40.112: Fetching http://wx.schamschula.com/.well-known/acme-challenge/PDvWAv_GQNdjYA8gifhYSVYzE1tX7eR0tHsmwObgMpo: Error getting validation data

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.

2026-01-07 16:24:24,235:DEBUG:certbot._internal.error_handler:Encountered exception:
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/certbot/_internal/auth_handler.py", line 108, in handle_authorizations
    self._poll_authorizations(authzrs, max_retries, max_time_mins, best_effort)
  File "/usr/local/lib/python3.11/site-packages/certbot/_internal/auth_handler.py", line 212, in _poll_authorizations
    raise errors.AuthorizationError('Some challenges have failed.')
certbot.errors.AuthorizationError: Some challenges have failed.

2026-01-07 16:24:24,235:DEBUG:certbot._internal.error_handler:Calling registered functions
2026-01-07 16:24:24,235:INFO:certbot._internal.auth_handler:Cleaning up challenges
2026-01-07 16:24:26,314:ERROR:certbot._internal.renewal:Failed to renew certificate wx.schamschula.com with error: Some challenges have failed.
2026-01-07 16:24:26,321:DEBUG:certbot._internal.renewal:Traceback was:
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/certbot/_internal/renewal.py", line 667, in handle_renewal_request
    main.renew_cert(lineage_config, plugins, renewal_candidate)
  File "/usr/local/lib/python3.11/site-packages/certbot/_internal/main.py", line 1535, in renew_cert
    renewed_lineage = _get_and_save_cert(le_client, config, lineage=lineage)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/certbot/_internal/main.py", line 131, in _get_and_save_cert
    renewal.renew_cert(config, domains, le_client, lineage)
  File "/usr/local/lib/python3.11/site-packages/certbot/_internal/renewal.py", line 520, in renew_cert
    new_cert, new_chain, new_key, _ = le_client.obtain_certificate(domains, new_key)
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/certbot/_internal/client.py", line 430, in obtain_certificate
    orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/certbot/_internal/client.py", line 508, in _get_order_and_authorizations
    authzr = self.auth_handler.handle_authorizations(orderr, self.config, best_effort)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/certbot/_internal/auth_handler.py", line 108, in handle_authorizations
    self._poll_authorizations(authzrs, max_retries, max_time_mins, best_effort)
  File "/usr/local/lib/python3.11/site-packages/certbot/_internal/auth_handler.py", line 212, in _poll_authorizations
    raise errors.AuthorizationError('Some challenges have failed.')
certbot.errors.AuthorizationError: Some challenges have failed.

2026-01-07 16:24:26,323:DEBUG:certbot._internal.display.obj:Notifying user: 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2026-01-07 16:24:26,323:ERROR:certbot._internal.renewal:All renewals failed. The following certificates could not be renewed:
2026-01-07 16:24:26,323:ERROR:certbot._internal.renewal:  /usr/local/etc/letsencrypt/live/wx.schamschula.com/fullchain.pem (failure)
2026-01-07 16:24:26,324:DEBUG:certbot._internal.display.obj:Notifying user: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2026-01-07 16:24:26,324:DEBUG:certbot._internal.log:Exiting abnormally:
Traceback (most recent call last):
  File "/usr/local/bin/certbot", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/usr/local/lib/python3.11/site-packages/certbot/main.py", line 19, in main
    return internal_main.main(cli_args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/certbot/_internal/main.py", line 1877, in main
    return config.func(config, plugins)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/certbot/_internal/main.py", line 1623, in renew
    renewal.handle_renewal_request(config)
  File "/usr/local/lib/python3.11/site-packages/certbot/_internal/renewal.py", line 697, in handle_renewal_request
    raise errors.Error(
certbot.errors.Error: 1 renew failure(s), 0 parse failure(s)
2026-01-07 16:24:26,327:ERROR:certbot._internal.log:1 renew failure(s), 0 parse failure(s)
5

That doesn't show anything new. The useful part of that log is to see the changes to your nginx server block(s). If you don't want to show it you'll have to look at that log yourself and make sure the changes are as you expect.

Another option is to run this

sudo certbot certonly --dry-run --nginx -d wx.schamschula.com -v --debug-challenges

It will not affect any existing production certs

It will pause after making the temporary changes to your nginx. You can then try the URL shown from outside your local network.

While paused you can also inspect your nginx config to ensure the right server blocks got updated. The changes look something like this:

server {rewrite ^(/.well-known/acme-challenge/.*) $1 break; # managed by Certbot

    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    root /var/www/html;

location = /.well-known/acme-challenge/MxkxRxkxzxkxgxHxvxkxOxpxkxVxkx8xkx4xFxExuxg {default_type text/plain;return 200 MxkxRxkxzxkxgxHxvxkxOxpxkxVxkx8xkx4xFxExuxg.AwQwgwgwzwgwJwgw4wew3wrwxwiw-wpwvwqwxwBwswT;} # managed by Certbot
}
1 Like
6

Yes, the log shows the modified server blocks for 80 and 443:

server {rewrite ^(/.well-known/acme-challenge/.*) $1 break; # managed by Certbot

and

location = /.well-known/acme-challenge/PDvWAv_GQNdjYA8gifhYSVYzE1tX7eR0tHsmwObgMpo{default_type text/plain;return 200 PDvWAv_GQNdjYA8gifhYSVYzE1tX7eR0tHsmwObgMpo.jJnspvwEMxhAe1H2-XWGG7vPoN-RnowE0MSZmpB1akw;} # managed by Certbot

Unfortunately, the dry-run with debug-challenges yielded nothing new, but I did attempt to fetch it

curl -v http://wx.schamschula.com/.well-known/acme-challenge/UxjhSziJBv2_WMEOhqdyJq52LjezeY1EhveAcF60yZg
*   Trying 173.25.40.112:80...
* Connected to wx.schamschula.com (173.25.40.112) port 80 (#0)
> GET /.well-known/acme-challenge/UxjhSziJBv2_WMEOhqdyJq52LjezeY1EhveAcF60yZg HTTP/1.1
> Host: wx.schamschula.com
> User-Agent: curl/7.81.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx/1.28.0
< Date: Wed, 07 Jan 2026 22:49:56 GMT
< Content-Type: text/plain
< Content-Length: 87
< Connection: keep-alive
< ‘Access-Control-Allow-Origin‘: ‘*‘
< 
* Connection #0 to host wx.schamschula.com left intact
7

What does that mean? Did you try the URL shown from outside your network? What tool did you use and what did it show?

Oh, you modified your prior post while I was posting this.

Well, that rules out Certbot as the cause.

Must be firewall or network related then. Which is usually what that error means.

What has changed in those components since you last got a good cert on Oct 26?

2 Likes
8

Yes, remotely from Dreamhost. It fails from inside my home network (both Safari and curl hang, probably due to DNS). I get a local response using the internal address.

Here's the output:

# /usr/local/bin/certbot certonly --dry-run --nginx -d wx.schamschula.com -v --debug-challenges
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
An RSA certificate named wx.schamschula.com already exists. Do you want to
update its key type to ECDSA?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(U)pdate key type/(K)eep existing key type: K
Certificate not due for renewal, but simulating renewal for dry run
Simulating renewal of an existing certificate for wx.schamschula.com
Performing the following challenges:
http-01 challenge for wx.schamschula.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Challenges loaded. Press continue to submit to CA.

The following URLs should be accessible from the internet and return the value
mentioned:

URL:
http://wx.schamschula.com/.well-known/acme-challenge/4jQugIfE_O3EQypk_vRWDt-mAD3CGPo4ejQupjeuyBQ
Expected value:
4jQugIfE_O3EQypk_vRWDt-mAD3CGPo4ejQupjeuyBQ.OwBrWYdTmeqrgcLqjGVnNZMIEPEMLGPHGLe68VNpSH8
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Waiting for verification...
Challenge failed for domain wx.schamschula.com
http-01 challenge for wx.schamschula.com

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
  Domain: wx.schamschula.com
  Type:   connection
  Detail: 173.25.40.112: Fetching http://wx.schamschula.com/.well-known/acme-challenge/4jQugIfE_O3EQypk_vRWDt-mAD3CGPo4ejQupjeuyBQ: Error getting validation data

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.

Cleaning up challenges
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.
9

We keep cross-posting :slight_smile: Please review my prior post

2 Likes
10

Indeed! The as I mentioned, the ipfw firewall has always been temporarily disabled when updating. So the firewall should not matter. Here's the cron script:

#!/bin/sh

##
#       certbot_renew
#       1.3.2
#       2024-10-24
##

service ipfw stop

tar czf /usr/local/etc/letsencrypt/bu/$(date "+%Y-%m-%d").tar.gz  /usr/local/etc/letsencrypt/archive/*

/usr/local/bin/certbot renew --reuse-key

service ipfw start

There have not been any changes to the network since the last successful update. The only thing that changed in that time period is the certbot version via FreeBSD ports and more recently the FreeBSD OS version.

11

I am stepping away for a bit. But, as an aside requests to your domain get a faulty cert chain. You only send the leaf and not the leaf with the intermediate.

The --nginx authenticator is usually used also as "installer" which sets up the right file to use. So, something is amiss. Could some other component be using that cert (like a firewall?)

Otherwise make sure your nginx server block for HTTPS is using fullchain.pem (not cert.pem)

echo|openssl s_client -connect wx.schamschula.com:443 | head -20
depth=0 CN = wx.schamschula.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = wx.schamschula.com
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = wx.schamschula.com
verify return:1
DONE
CONNECTED(00000003)
---
Certificate chain
 0 s:CN = wx.schamschula.com
   i:C = US, O = Let's Encrypt, CN = R12
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Oct 26 04:04:28 2025 GMT; NotAfter: Jan 24 04:04:27 2026 GMT
---
Server certificate
2 Likes
12

That may be it:

		ssl_certificate		/usr/local/etc/letsencrypt/live/wx.schamschula.com/cert.pem;
		ssl_certificate_key /usr/local/etc/letsencrypt/live/wx.schamschula.com/privkey.pem;
		include				/usr/local/etc/letsencrypt/options-ssl-nginx.conf;
		ssl_dhparam			/usr/local/etc/letsencrypt/ssl-dhparams.pem;
13

Definitely use fullchain.pem rather than cert.pem

But, that isn't affecting the renewal failure. That is happening on port 80 (HTTP) anyway and even if you redirected Let's Encrypt does not validate certs for a cert request.

2 Likes
14

I've updated to use fullchain.pem, but as you mentioned that doesn't make a difference in terms of port 80.

15

Further testing using the certbot --dry-run and --debug-challenges allowed me to fetch the file from Dreamhost and verify the contents.

However, the dry run itself still errors out.

16

I just noticed that the version of certbot provided by FreeBSD ports is rather old: 4.2.0. MacPorts is at version 5.2.2.

17

Connectivity seems to be flaky from several places around the world.

If it's not a firewall close to your system, maybe it's something that the Internet provider is blocking.

3 Likes
18

Still no luck.

I can remotely grab the challenge data from both campus and Dreamhost, but

The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot.

The log file gives me

2026-01-12 14:18:09,895:DEBUG:certbot._internal.error_handler:Encountered exception:
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/certbot/_internal/auth_handler.py", line 108, in handle_authorizations
    self._poll_authorizations(authzrs, max_retries, max_time_mins, best_effort)
  File "/usr/local/lib/python3.11/site-packages/certbot/_internal/auth_handler.py", line 212, in _poll_authorizations
    raise errors.AuthorizationError('Some challenges have failed.')
certbot.errors.AuthorizationError: Some challenges have failed.

2026-01-12 14:18:09,896:DEBUG:certbot._internal.error_handler:Calling registered functions
2026-01-12 14:18:09,896:INFO:certbot._internal.auth_handler:Cleaning up challenges
2026-01-12 14:18:11,990:DEBUG:certbot._internal.log:Exiting abnormally:
Traceback (most recent call last):
  File "/usr/local/bin/certbot", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/usr/local/lib/python3.11/site-packages/certbot/main.py", line 19, in main
    return internal_main.main(cli_args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/certbot/_internal/main.py", line 1877, in main
    return config.func(config, plugins)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/certbot/_internal/main.py", line 1585, in certonly
    lineage = _get_and_save_cert(le_client, config, domains, certname, lineage)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/certbot/_internal/main.py", line 131, in _get_and_save_cert
    renewal.renew_cert(config, domains, le_client, lineage)
  File "/usr/local/lib/python3.11/site-packages/certbot/_internal/renewal.py", line 520, in renew_cert
    new_cert, new_chain, new_key, _ = le_client.obtain_certificate(domains, new_key)
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/certbot/_internal/client.py", line 430, in obtain_certificate
    orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/certbot/_internal/client.py", line 508, in _get_order_and_authorizations
    authzr = self.auth_handler.handle_authorizations(orderr, self.config, best_effort)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/certbot/_internal/auth_handler.py", line 108, in handle_authorizations
    self._poll_authorizations(authzrs, max_retries, max_time_mins, best_effort)
  File "/usr/local/lib/python3.11/site-packages/certbot/_internal/auth_handler.py", line 212, in _poll_authorizations
    raise errors.AuthorizationError('Some challenges have failed.')
certbot.errors.AuthorizationError: Some challenges have failed
2026-01-12 14:18:11,997:ERROR:certbot._internal.log:Some challenges have failed.
19

You omitted the "reason" part of the error message. And, the tail of the log also omits it. We need to see the command you tried and all the output from that command. The specific details matter.

That said, earlier you said this should work:
http://wx.schamschula.com/.well-known/acme-challenge/foo.html

But, requests from many places around the world to that fail. That looks very much like a firewall blocking certain IP and/or repeated or too-frequent requests. See: Check website performance and response : Check host - online website monitoring

2 Likes
20

I agree with Mike.
I believe there is to much geo blocking see here Check Website Availability

image
image1146×864 63.8 KB

Please see Multi-Perspective Validation & Geoblocking FAQ

1 Like