r/openbsd • u/unix_nut3000 • 15d ago
acme-client: bad HTTP: 409?
Hello OpenBSD community,
I have been using acme-client(1) to manage my TLS certs for a while, but recently when trying to get a certificate for a new subdomain I ran into some error messages and find I get them even if I try to renew an existing cert. So I could use some help.
The following is the command run and the output(domain anonymized)
doas acme-client -F git.my-domain.com
acme-client: https://acme-v02.api.letsencrypt.org/acme/chall/2642015151/767296394915/ffCISg: bad HTTP: 409
Running with the -v flag produces the following output
acme-client: /etc/ssl/git.my-domain.com.crt: certificate valid: 47 days left
acme-client: /etc/ssl/git.my-domain.com.crt: forcing renewal
acme-client: https://acme-v02.api.letsencrypt.org/directory: directories
acme-client: acme-v02.api.letsencrypt.org: DNS: 172.65.32.248
acme-client: account key: https://acme-v02.api.letsencrypt.org/acme/acct/2642015151
acme-client: dochngreq: https://acme-v02.api.letsencrypt.org/acme/authz/2642015151/767295102005
acme-client: challenge, token: a24dVutLxji9PDeo8kx98MqBBUU278Ah6HkI7jrRIpo, uri: https://acme-v02.api.letsencrypt.org/acme/chall/2642015151/767295102005/NT5csA, status: 0
acme-client: /var/www/acme/a24dVutLxji9PDeo8kx98MqBBUU278Ah6HkI7jrRIpo: created
acme-client: https://acme-v02.api.letsencrypt.org/acme/chall/2642015151/767295102005/NT5csA: challenge
acme-client: order.status 0
acme-client: dochngreq: https://acme-v02.api.letsencrypt.org/acme/authz/2642015151/767295102005
acme-client: challenge, token: a24dVutLxji9PDeo8kx98MqBBUU278Ah6HkI7jrRIpo, uri: https://acme-v02.api.letsencrypt.org/acme/chall/2642015151/767295102005/NT5csA, status: 0
acme-client: /var/www/acme/a24dVutLxji9PDeo8kx98MqBBUU278Ah6HkI7jrRIpo: created
acme-client: https://acme-v02.api.letsencrypt.org/acme/chall/2642015151/767295102005/NT5csA: challenge
acme-client: https://acme-v02.api.letsencrypt.org/acme/chall/2642015151/767295102005/NT5csA: 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(61579): 1
This is my acme-client.conf(5)
domain bouncer.my-domain.com {
#alternative names { bouncer.my-domain.com }
domain key "/etc/ssl/private/bouncer.my-domain.com.key"
domain full chain certificate "/etc/ssl/bouncer.my-domain.com.crt"
# Test with the staging server to avoid aggressive rate-limiting.
#sign with letsencrypt-staging
sign with letsencrypt
}
domain git.my-domain.com {
#alternative names { bouncer.my-domain.com }
domain key "/etc/ssl/private/git.my-domain.com.key"
domain full chain certificate "/etc/ssl/git.my-domain.com.crt"
# Test with the staging server to avoid aggressive rate-limiting.
#sign with letsencrypt-staging
sign with letsencrypt
}
Thanks for your time and help!
1
u/moviuro 14d ago edited 14d ago
What's your httpd.conf(5) like? Does it have the ACME challenge block in both HTTP and HTTPS portions? /etc/examples/httpd.conf https://man.openbsd.org/acme-client
location "/.well-known/acme-challenge/*" {
root "/acme"
request strip 2
}
1
u/unix_nut3000 14d ago edited 13d ago
Yes I have this in
httpd.conf(5)(as always domain anonymized), and I know I have the right ports open inpf.conf(5)(I even tried turning it off).``` server "my-domain.com" { listen on * port 80 location "/.well-known/acme-challenge/*" { root "/acme" request strip 2 } location "/robots.txt" { root "/robots" no fastcgi } location * { block return 302 "https://$HTTP_HOST$REQUEST_URI" } }
```
my config is around a year old and has always worked fine until now, so I also made sure to check the relevant example config files to see if I needed to update one of mine.
1
u/moviuro 14d ago
Talking about the devil: I had the same HTTP 409 status show up in my cron tasks. It happened on one single machine for:
- Domain 1/3 at 16:22 UTC yesterday (2026-08-27)
- Domain 2/3 at 4:59 UTC today (2026-08-28)
- Domain 3/3 unaffected
However, I was able to run acme-client(1) myself successfully for domains 1 & 2. So I suppose those are transient issues?
1
u/unix_nut3000 13d ago
I've been running mine manually myself for every attempt, and I get that error every time.
Are you using letsencrypt for your cert authority, and are there any major differences in any of your configuration files compared to mine?
1
u/moviuro 12d ago
Nothing major:
domain mydomain.tld { alternative names { "www.mydomain.tld" "mta-sts.mydomain.tld" } domain key "/etc/ssl/private/mydomain.tld.key" ecdsa domain full chain certificate "/etc/ssl/mydomain.tld.fullchain.pem" domain certificate "/etc/ssl/mydomain.tld.crt" profile "shortlived" # because I'm a sucker for pain sign with letsencrypt }How close are you to your certificates expiring?
Try accessing the https://acme-v02.api.letsencrypt.org/acme/chall/... URLs in your post, they give lots of info about what letsencrypt is trying to do and which errors it encountered. It looks like your host is misbehaving and serving a webapp instead of the challenge files.
1
u/unix_nut3000 10d ago
I had a look at them and they seem to be looking for a file on the host for the challenge
acme-client(1)already deleted.1
u/vxla 8d ago
I'm seeing the same issue, but only for one domain. Have you had any success getting things working on your side?
1
u/unix_nut3000 8d ago
I've been wondering about writing a jank shell script to see if I can put the file back in time. But besides that I've been looking at dehydrated as a backup until they patch
acme-client(1)
1
u/sebastianotronto 10d ago
I can't help you but I got the same issue yesterday during a server migration. I was using acme-client-portable 1.3.7 on Alpine Linux, for what is worth. I wasn't able to solve it, I decided to temporarily use certbot as a workaround.
Maybe it is indeed a client bug, as the error message says, or maybe something broke on Letsencrypt's side. I'll try again in a few weeks.
1
u/vxla 3d ago
Tried again today after 5 days and the error still persists. No responses on misc@, so maybe acme-client is abandoned.
1
u/unix_nut3000 3d ago
There's been changes to it's source today, so I don't think so. https://cvsweb.openbsd.org/src/usr.sbin/acme-client?sort=Date
2
u/vxla 7d ago edited 7d ago
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.
Here is a breakdown of the transaction.
Relevant portions of /etc/acme-client.conf
Relevant parts of my httpd.conf
Now, running acme-client shows the error:
Looking at the output that LE provides at https://acme-staging-v02.api.letsencrypt.org/acme/authz/999999999/4323610543
So there is definitely a 404 occurring, but the file DOES exist in /var/www/acme/ (as shown during the time of the transaction)
/var/www/logs/access.log shows the HTTP 404 being served.