Hi, I had the same issue las week, maybe the solution/workaround apply to you as well, my site is behind cloudflare, took me a full day to realise that the problem was caused by SSL/TLS config in CF...in my case originally was "Full (Strict)", I had to change it to "Auto"...No more problems since then.
HTH -- Ronny Machado C. IT Consultant HP-UX Certified Systems Administrator Oracle Linux Certified Implementation Specialist Oracle MySQL Enterprise Certified Implementation Specialist https://sysops.cl Sent with Proton Mail secure email. On Thursday, September 3rd, 2026 at 12:35 PM, [email protected] <[email protected]> wrote: > Just recently, I started seeing problems where one Let's Encrypt certificate > was not being renewed by acme-client. > > Digging around the issue after waiting a few days to see if the issue as > temporal, I found that the temporary file set by acme-client in > /var/www/acme/ is not available when Let's Encrypt checks for it; instead, > httpd is generating a 404. > > I'm running 7.9 > > $ uname -a > OpenBSD www 7.9 GENERIC#8 amd64 > > Relevant portions of /etc/acme-client.conf > ------------------------------------------ > > authority letsencrypt-staging { > api url "https://acme-staging-v02.api.letsencrypt.org/directory"; > account key "/etc/acme/letsencrypt-staging-privkey.pem" } > > domain www.example.com { > domain key "/etc/ssl/private/www.example.com.key.pem" > domain full chain certificate "/etc/ssl/certs/www.example.com.chain.pem" > sign with letsencrypt-staging > } > > > Relevant parts of httpd.conf > ---------------------------- > > server "www.example.com" { > alias "www2.example.com" > listen on 203.0.113.1 port 80 > listen on 3fff:a:b::2 port 80 > location "/.well-known/acme-challenge/*" { > root "/acme" > request strip 2 > pass > } > block return 301 "https://$HTTP_HOST$REQUEST_URI"; > } > > > Here is a breakdown of the transaction; running acme-client shows the error: > > # acme-client -v www.example.com > acme-client: https://acme-staging-v02.api.letsencrypt.org/directory: > directories > acme-client: acme-staging-v02.api.letsencrypt.org: DNS: 172.65.46.172 > acme-client: acme-staging-v02.api.letsencrypt.org: DNS: > 2606:4700:60:0:f41b:d4fe:4325:6026 > acme-client: account key: > https://acme-staging-v02.api.letsencrypt.org/acme/acct/999999999 > acme-client: dochngreq: > https://acme-staging-v02.api.letsencrypt.org/acme/authz/999999999/4323610543 > acme-client: challenge, token: 0qew5-cCl8MYLRX1I58Ald50lxppE4yM0RZy-aeJRUQ, > uri: > https://acme-staging-v02.api.letsencrypt.org/acme/chall/999999999/4323610543/MtUOoQ, > status: 0 > acme-client: /var/www/acme/0qew5-cCl8MYLRX1I58Ald50lxppE4yM0RZy-aeJRUQ: > created > acme-client: > https://acme-staging-v02.api.letsencrypt.org/acme/chall/999999999/4323610543/MtUOoQ: > challenge > acme-client: order.status 0 > acme-client: dochngreq: > https://acme-staging-v02.api.letsencrypt.org/acme/authz/999999999/4323610543 > acme-client: challenge, token: 0qew5-cCl8MYLRX1I58Ald50lxppE4yM0RZy-aeJRUQ, > uri: > https://acme-staging-v02.api.letsencrypt.org/acme/chall/999999999/4323610543/MtUOoQ, > status: 0 > acme-client: /var/www/acme/0qew5-cCl8MYLRX1I58Ald50lxppE4yM0RZy-aeJRUQ: > created > acme-client: > https://acme-staging-v02.api.letsencrypt.org/acme/chall/999999999/4323610543/MtUOoQ: > challenge > acme-client: > https://acme-staging-v02.api.letsencrypt.org/acme/chall/999999999/4323610543/MtUOoQ: > bad HTTP: 409 > acme-client: transfer buffer: [{ > "type": "urn:ietf:params:acme:error:conflict", > "detail": "Unable to update challenge :: failed to mark authz as > processing: Authorization is already being validated. This may indicate your > client attempted the same challenge multiple times, possibly due to a client > bug.", > "status": 409 > }] (296 bytes) > acme-client: bad exit: netproc(58779): 1 > > > Looking at the output that LE provides at the following URL shows an HTTP > 404 when trying to fetch the challenge file. > <https://acme-staging-v02.api.letsencrypt.org/acme/authz/999999999/4322736873> > > { > "identifier": { > "type": "dns", > "value": "www.example.com" > }, > "status": "invalid", > "expires": "2026-09-10T14:03:56Z", > "challenges": [ > { > "type": "http-01", > "url": > "https://acme-staging-v02.api.letsencrypt.org/acme/chall/999999999/4323610543/MtUOoQ";, > "status": "invalid", > "validated": "2026-09-03T14:03:57Z", > "error": { > "type": "urn:ietf:params:acme:error:unauthorized", > "detail": "203.0.113.1: Invalid response from > http://www.example.com/.well-known/acme-challenge/0qew5-cCl8MYLRX1I58Ald50lxppE4yM0RZy-aeJRUQ: > 404", > "status": 403 > }, > "token": "0qew5-cCl8MYLRX1I58Ald50lxppE4yM0RZy-aeJRUQ", > "validationRecord": [ > { > "url": > "http://www.example.com/.well-known/acme-challenge/0qew5-cCl8MYLRX1I58Ald50lxppE4yM0RZy-aeJRUQ";, > "hostname": "www.example.com", > "port": "80", > "addressesResolved": [ > "3fff:a:b::2", > "203.0.113.1" > ], > "addressUsed": "3fff:a:b::2" > }, > { > "url": > "http://www.example.com/.well-known/acme-challenge/0qew5-cCl8MYLRX1I58Ald50lxppE4yM0RZy-aeJRUQ";, > "hostname": "www.example.com", > "port": "80", > "addressesResolved": [ > "3fff:a:b::2", > "203.0.113.1" > ], > "addressUsed": "203.0.113.1" > } > ] > } > ] > } > > So there is definitely a 404 occuring, but the file DOES exist in > /var/www/acme/ (as shown during the time of the transaction) > > # find /var/www/acme -ls > 155520 4 drwxr-xr-x 2 root daemon 512 Sep 3 09:03 > /var/www/acme > 155521 4 -r--r--r-- 1 root daemon 87 Sep 3 09:04 > /var/www/acme/0qew5-cCl8MYLRX1I58Ald50lxppE4yM0RZy-aeJRUQ > > > /var/www/logs/access.log shows the HTTP 404 being served. > > www.example.com 66.133.109.36 - - [03/Sep/2026:09:04:07 -0500] "GET > /.well-known/acme-challenge/0qew5-cCl8MYLRX1I58Ald50lxppE4yM0RZy-aeJRUQ > HTTP/1.1" 404 0 > > > Is anyone else experiencing this issue? What have you done to work around it? > > Thanks in advance. > >
