Hello Aleks,
On Fri, Nov 21, 2025 at 04:42:49AM +0100, Aleksandar Lazic wrote:
> Subject: Some questions about ACME challenge dns-01
> Hi.
>
> I try to use the ACME dns-01 feature and I'm not sure what I'm doing wrong.
>
> Let me explain what I do and where I'm got stuck.
>
> My Steps.
>
> * git pull from git.haproxy.org
> * make TARGET=linux-glibc USE_OPENSSL=1 USE_PCRE2=1 USE_ZLIB=1
> DEBUG=-DDEBUG_FULL USE_PCRE2_JIT=1
I'll presume you are using the master branch from yestarday. There wasn't any
big fixes for now.
> * ./haproxy -W -d -f ../haproxy_acme.cfg #terminal 1
> * add dns entry as shown in term 1
> ```
> acme: none.at.pem: dns-01 requires to set the "_acme-challenge.none.at" TXT
> record to "jr7eGbpPeNcVHlbpwRM0MeqNZvXYhH351mrUw1EMCuk" and use the "acme
> challenge_ready none.at.pem domain none.at" command over the CLI
> ```
>
> * Wait until the dns server shows the `_acme-challenge.none.at`
> ```
> dig @ns1.desec.io +short _acme-challenge.none.at txt
> "jr7eGbpPeNcVHlbpwRM0MeqNZvXYhH351mrUw1EMCuk"
> ```
> * Run the ready line
> ```
> alex@alex-tuxedoinfinitybooks1517gen7 on 21/11/2025 at 04:31:07_CET
> /datadisk/git-repos/haproxy $
> # echo "acme challenge_ready none.at.pem domain none.at" | socat -
> /tmp/hap-stats
> Challenge Ready!
> ```
>
> * check the status
> ```
> alex@alex-tuxedoinfinitybooks1517gen7 on 21/11/2025 at 04:37:47_CET
> /datadisk/git-repos/haproxy $
> # echo "acme status" | socat - /tmp/hap-stats
> # certificate section state expiration date (UTC) expires in
> scheduled date
> (UTC) scheduled in
> none.at.pem DNS1 Running 2025-11-20T03:29:02Z 0d 0h00m00s -
> -
> ```
>
> and that's it.
> The `Running` state isn't changed.
>
> What's my mistake?
>
>
> ```
> # File: haproxy_acme.cfg
>
> #---------------------------------------------------------------------
> # Global settings
> #---------------------------------------------------------------------
> global
> expose-experimental-directives
> log stdout format raw daemon debug
> stats socket /tmp/hap-stats mode 660 level admin expose-fd listeners
>
> defaults
> mode http
> balance leastconn
> log global
> option httplog
> option dontlognull
> option log-health-checks
> option forwardfor except 10.196.106.108/32
> option redispatch
> retries 3
> timeout http-request 10s
> timeout queue 1m
> timeout connect 10s
> timeout client 1m
> timeout server 1m
> timeout http-keep-alive 10s
> timeout check 10s
>
> crt-store
> load crt "none.at.pem" acme DNS1 domains "*.none.at,none.at"
>
> frontend in
> bind *:8080
> bind *:8443 ssl
> http-request return status 200 content-type text/plain lf-string
> "%[path,field(-1,/)].%[path,field(-1,/),map(virt@acme)]\n" if { path_beg
> '/.well-known/acme-challenge/' }
> ssl-f-use crt "none.at.pem"
You don't need that part for dns-01.
> listen stats
> bind *:1936
> monitor-uri /healthz
> #http-request use-service prometheus-exporter if { path /metrics }
> stats enable
> stats uri /
>
> acme DNS1
> directory https://acme-staging-v02.api.letsencrypt.org/directory
> #directory https://acme-v02.api.letsencrypt.org/directory
> #account-key /etc/haproxy/letsencrypt.account.key
> contact [email protected]
> challenge dns-01
> keytype RSA
> bits 2048
> map virt@acme
the map is not needed for dns-01.
> ```
>
> Here the HAP output on stdout.
>
> ```
> alex@alex-tuxedoinfinitybooks1517gen7 on 21/11/2025 at 04:28:02_CET
> /datadisk/git-repos/haproxy $
> # ./haproxy -W -d -f ../haproxy_acme.cfg
> [NOTICE] (80919) : Initializing new worker (80921)
> [NOTICE] (80921) : config : No certificate available for 'none.at.pem',
> generating a temporary key pair before getting the ACME certificate
> Using epoll() as the polling mechanism.
> [NOTICE] (80921) : config : acme: generate account key 'DNS1.account.key'
> for acme section 'DNS1'.
> Sharing caphdr with caphdr
> Sharing caphdr with caphdr
> Sharing ptrcap with ptrcap
> Sharing ptrcap with ptrcap
> [NOTICE] (80921) : Automatically setting global.maxconn to 524263.
> Available polling systems :
> epoll : pref=300, test result OK
> poll : pref=200, test result OK
> select : pref=150, test result FAILED
> Total: 3 (2 usable), will use epoll.
>
> Available filters :
> [BWLIM] bwlim-in
> [BWLIM] bwlim-out
> [CACHE] cache
> [COMP] compression
> [FCGI] fcgi-app
> [SPOE] spoe
> [TRACE] trace
> Using epoll() as the polling mechanism.
> Sharing stk_ctr with caphdr
> 00000000:MASTER.accept(0004)=0007 from [unix:1] ALPN=<none>
> [NOTICE] (80919) : Loading success.
> 00000000:MASTER.srvcls[0007:ffff]
> 00000001:MASTER.clicls[0007:ffff]
> 00000001:MASTER.closed[0007:ffff]
>
> WARNING! thread 1 has stopped processing traffic for 201 milliseconds
> with 0 streams currently blocked, prevented from making any progress.
> While this may occasionally happen with inefficient configurations
> involving excess of regular expressions, map_reg, or heavy Lua processing,
> this must remain exceptional because the system's stability is now at
> risk.
> Timers in logs may be reported incorrectly, spurious timeouts may happen,
> some incoming connections may silently be dropped, health checks may
> randomly fail, and accesses to the CLI may block the whole process. The
> blocking delay before emitting this warning may be adjusted via the global
> 'warn-blocked-traffic-after' directive. Please check the trace below for
> any clues about configuration elements that need to be corrected:
>
> * Thread 1 : id=0x73b3ccf42d00 act=1 glob=0 wq=0 rq=0 tl=1 tlsz=1 rqsz=1
> 1/1 loops=0 ctxsw=7 stuck=0 prof=0 harmless=0 isolated=0 locks=1
> cpu_ns: poll=600395551 now=802318248 diff=201922697
> curr_task=0x6464dfa397c0 (task) calls=1 last=0
> fct=0x6464a1fc6fa0(ssl_async_fd_handler+0x3ecb0)
> ctx=0x73b3cc803b20
> lock_hist: S:PROTO U:PROTO W:PATEXP U:PATEXP S:PROTO U:PROTO
> S:CKCH locked: CKCH(S)
> call trace(28):
> | 0x6464a2117834 <00 00 00 e8 cc 08 e6 ff]:
> ha_dump_backtrace+0x84/0x40d > main-0x8b0
> | 0x6464a211abf6 <48 89 df e8 2a f4 ff ff]:
> ha_stuck_warning+0xf6/0x160 > ha_thread_dump_one
> | 0x6464a2237594 <00 00 00 e8 6c 35 ee ff]:
> wdt_handler+0x1e4/0x297 > ha_stuck_warning
> | 0x73b3cc645330 <00 00 00 00 0f 1f 40 00]: libc:+0x45330
> | 0x73b3ccb1aa24 <f6 e8 f3 4d 0f 38 f6 f7]: libcrypto:+0x11aa24
> | 0x73b3ccb1a187 <09 00 00 e8 59 00 00 00]: libcrypto:+0x11a187
> > libcrypto:+0x11a1e0
> | 0x73b3ccafdef0 <48 89 fe e8 10 ae 01 00]: libcrypto:+0xfdef0
> > libcrypto:+0x118d00
> | 0x73b3ccafcd15 <83 ec 08 e8 3b 08 00 00]:
> libcrypto:BN_mod_exp_mont_consttime+0x15/0x3a > libcrypto:+0xfd550
> | 0x73b3ccb08cda <4c 89 ef e8 66 40 ff ff]: libcrypto:+0x108cda
> > libcrypto:BN_mod_exp_mont
> | 0x73b3ccb08fca <ff ff ff e8 56 fa ff ff]: libcrypto:+0x108fca
> > libcrypto:+0x108a20
> | 0x73b3ccb0b3d2 <4c 89 ef e8 be e7 ff ff]: libcrypto:+0x10b3d2
> > libcrypto:BN_check_prime
> | 0x73b3ccb0b697 <89 5d a0 e8 e9 f9 ff ff]: libcrypto:+0x10b697
> > libcrypto:+0x10b080
> | 0x73b3ccd204cd <54 6a 00 e8 d3 af de ff]: libcrypto:+0x3204cd
> > libcrypto:+0x10b4a0
> | 0x73b3ccd20c1c <4c 89 ff e8 84 f7 ff ff]: libcrypto:+0x320c1c
> > libcrypto:+0x3203a0
> | 0x73b3ccdcdcbd <8b 73 18 e8 b3 63 f4 ff]: libcrypto:+0x3cdcbd
> > libcrypto:RSA_generate_multi_prime_key
> | 0x73b3ccc03e28 <83 ec 08 e8 f8 0b 00 00]: libcrypto:+0x203e28
> > libcrypto:+0x204a20
> | 0x73b3ccc0f5fa <fd ff ff e8 06 48 ff ff]:
> libcrypto:EVP_PKEY_generate+0x12a/0x2cf > libcrypto:+0x203e00
> | 0x6464a1fbdf72 <48 89 df e8 ce 9c fb ff]:
> ssl_async_fd_handler+0x35c82 > main-0xd70
> | 0x6464a1fc6dfa <8b 4d c8 e8 06 71 ff ff]:
> ssl_async_fd_handler+0x3eb0a > ssl_async_fd_handler+0x35c10
> | 0x6464a1fc722d <48 89 df e8 43 f6 ff ff]:
> ssl_async_fd_handler+0x3ef3d > ssl_async_fd_handler+0x3e580
> => Trying to gracefully recover now (pid 80921).
>
> WARNING! thread 1 has stopped processing traffic for 304 milliseconds
> with 0 streams currently blocked, prevented from making any progress.
> While this may occasionally happen with inefficient configurations
> involving excess of regular expressions, map_reg, or heavy Lua processing,
> this must remain exceptional because the system's stability is now at
> risk.
> Timers in logs may be reported incorrectly, spurious timeouts may happen,
> some incoming connections may silently be dropped, health checks may
> randomly fail, and accesses to the CLI may block the whole process. The
> blocking delay before emitting this warning may be adjusted via the global
> 'warn-blocked-traffic-after' directive. Please check the trace below for
> any clues about configuration elements that need to be corrected:
>
> * Thread 1 : id=0x73b3ccf42d00 act=1 glob=0 wq=0 rq=0 tl=1 tlsz=1 rqsz=1
> 1/1 loops=0 ctxsw=7 stuck=0 prof=0 harmless=0 isolated=0 locks=1
> cpu_ns: poll=600395551 now=905301127 diff=304905576
> curr_task=0x6464dfa397c0 (task) calls=1 last=0
> fct=0x6464a1fc6fa0(ssl_async_fd_handler+0x3ecb0)
> ctx=0x73b3cc803b20
> lock_hist: S:PROTO U:PROTO W:PATEXP U:PATEXP S:PROTO U:PROTO
> S:CKCH locked: CKCH(S)
> call trace(24):
> | 0x6464a2117834 <00 00 00 e8 cc 08 e6 ff]:
> ha_dump_backtrace+0x84/0x40d > main-0x8b0
> | 0x6464a211abf6 <48 89 df e8 2a f4 ff ff]:
> ha_stuck_warning+0xf6/0x160 > ha_thread_dump_one
> | 0x6464a2237594 <00 00 00 e8 6c 35 ee ff]:
> wdt_handler+0x1e4/0x297 > ha_stuck_warning
> | 0x73b3cc645330 <00 00 00 00 0f 1f 40 00]: libc:+0x45330
> | 0x73b3ccb0ba08 <4c 89 ef e8 28 82 ff ff]:
> libcrypto:BN_rshift1+0xf8/0xfa > libcrypto:BN_zero_ex
> | 0x73b3ccb00c3b <4c 89 cf e8 d5 ac 00 00]:
> libcrypto:BN_gcd+0x24b/0x30d > libcrypto:BN_rshift1
> | 0x73b3ccb0b3ab <4c 89 ff e8 45 56 ff ff]: libcrypto:+0x10b3ab
> > libcrypto:BN_gcd
> | 0x73b3ccb0b697 <89 5d a0 e8 e9 f9 ff ff]: libcrypto:+0x10b697
> > libcrypto:+0x10b080
> | 0x73b3ccd204cd <54 6a 00 e8 d3 af de ff]: libcrypto:+0x3204cd
> > libcrypto:+0x10b4a0
> | 0x73b3ccd20c1c <4c 89 ff e8 84 f7 ff ff]: libcrypto:+0x320c1c
> > libcrypto:+0x3203a0
> | 0x73b3ccdcdcbd <8b 73 18 e8 b3 63 f4 ff]: libcrypto:+0x3cdcbd
> > libcrypto:RSA_generate_multi_prime_key
> | 0x73b3ccc03e28 <83 ec 08 e8 f8 0b 00 00]: libcrypto:+0x203e28
> > libcrypto:+0x204a20
> | 0x73b3ccc0f5fa <fd ff ff e8 06 48 ff ff]:
> libcrypto:EVP_PKEY_generate+0x12a/0x2cf > libcrypto:+0x203e00
> | 0x6464a1fbdf72 <48 89 df e8 ce 9c fb ff]:
> ssl_async_fd_handler+0x35c82 > main-0xd70
> | 0x6464a1fc6dfa <8b 4d c8 e8 06 71 ff ff]:
> ssl_async_fd_handler+0x3eb0a > ssl_async_fd_handler+0x35c10
> | 0x6464a1fc722d <48 89 df e8 43 f6 ff ff]:
> ssl_async_fd_handler+0x3ef3d > ssl_async_fd_handler+0x3e580
> => Trying to gracefully recover now (pid 80921).
>
> WARNING! thread 1 has stopped processing traffic for 407 milliseconds
> with 0 streams currently blocked, prevented from making any progress.
> While this may occasionally happen with inefficient configurations
> involving excess of regular expressions, map_reg, or heavy Lua processing,
> this must remain exceptional because the system's stability is now at
> risk.
> Timers in logs may be reported incorrectly, spurious timeouts may happen,
> some incoming connections may silently be dropped, health checks may
> randomly fail, and accesses to the CLI may block the whole process. The
> blocking delay before emitting this warning may be adjusted via the global
> 'warn-blocked-traffic-after' directive. Please check the trace below for
> any clues about configuration elements that need to be corrected:
>
> * Thread 1 : id=0x73b3ccf42d00 act=1 glob=0 wq=0 rq=0 tl=1 tlsz=1 rqsz=1
> 1/1 loops=0 ctxsw=7 stuck=0 prof=0 harmless=0 isolated=0 locks=1
> cpu_ns: poll=600395551 now=1008297270 diff=407901719
> curr_task=0x6464dfa397c0 (task) calls=1 last=0
> fct=0x6464a1fc6fa0(ssl_async_fd_handler+0x3ecb0)
> ctx=0x73b3cc803b20
> lock_hist: S:PROTO U:PROTO W:PATEXP U:PATEXP S:PROTO U:PROTO
> S:CKCH locked: CKCH(S)
> call trace(24):
> | 0x6464a2117834 <00 00 00 e8 cc 08 e6 ff]:
> ha_dump_backtrace+0x84/0x40d > main-0x8b0
> | 0x6464a211abf6 <48 89 df e8 2a f4 ff ff]:
> ha_stuck_warning+0xf6/0x160 > ha_thread_dump_one
> | 0x6464a2237594 <00 00 00 e8 6c 35 ee ff]:
> wdt_handler+0x1e4/0x297 > ha_stuck_warning
> | 0x73b3cc645330 <00 00 00 00 0f 1f 40 00]: libc:+0x45330
> | 0x73b3ccb03b36 <fe 41 31 f0 44 89 40 10]:
> libcrypto:BN_consttime_swap+0x56/0xb9
> | 0x73b3ccb00c99 <4c 89 ca e8 47 2e 00 00]:
> libcrypto:BN_gcd+0x2a9/0x30d > libcrypto:BN_consttime_swap
> | 0x73b3ccb0b3ab <4c 89 ff e8 45 56 ff ff]: libcrypto:+0x10b3ab
> > libcrypto:BN_gcd
> | 0x73b3ccb0b697 <89 5d a0 e8 e9 f9 ff ff]: libcrypto:+0x10b697
> > libcrypto:+0x10b080
> | 0x73b3ccd204cd <54 6a 00 e8 d3 af de ff]: libcrypto:+0x3204cd
> > libcrypto:+0x10b4a0
> | 0x73b3ccd20c1c <4c 89 ff e8 84 f7 ff ff]: libcrypto:+0x320c1c
> > libcrypto:+0x3203a0
> | 0x73b3ccdcdcbd <8b 73 18 e8 b3 63 f4 ff]: libcrypto:+0x3cdcbd
> > libcrypto:RSA_generate_multi_prime_key
> | 0x73b3ccc03e28 <83 ec 08 e8 f8 0b 00 00]: libcrypto:+0x203e28
> > libcrypto:+0x204a20
> | 0x73b3ccc0f5fa <fd ff ff e8 06 48 ff ff]:
> libcrypto:EVP_PKEY_generate+0x12a/0x2cf > libcrypto:+0x203e00
> | 0x6464a1fbdf72 <48 89 df e8 ce 9c fb ff]:
> ssl_async_fd_handler+0x35c82 > main-0xd70
> | 0x6464a1fc6dfa <8b 4d c8 e8 06 71 ff ff]:
> ssl_async_fd_handler+0x3eb0a > ssl_async_fd_handler+0x35c10
> | 0x6464a1fc722d <48 89 df e8 43 f6 ff ff]:
> ssl_async_fd_handler+0x3ef3d > ssl_async_fd_handler+0x3e580
> => Trying to gracefully recover now (pid 80921).
>
> WARNING! thread 1 has stopped processing traffic for 510 milliseconds
> with 0 streams currently blocked, prevented from making any progress.
> While this may occasionally happen with inefficient configurations
> involving excess of regular expressions, map_reg, or heavy Lua processing,
> this must remain exceptional because the system's stability is now at
> risk.
> Timers in logs may be reported incorrectly, spurious timeouts may happen,
> some incoming connections may silently be dropped, health checks may
> randomly fail, and accesses to the CLI may block the whole process. The
> blocking delay before emitting this warning may be adjusted via the global
> 'warn-blocked-traffic-after' directive. Please check the trace below for
> any clues about configuration elements that need to be corrected:
>
> * Thread 1 : id=0x73b3ccf42d00 act=1 glob=0 wq=0 rq=0 tl=1 tlsz=1 rqsz=1
> 1/1 loops=0 ctxsw=7 stuck=0 prof=0 harmless=0 isolated=0 locks=1
> cpu_ns: poll=600395551 now=1111291887 diff=510896336
> curr_task=0x6464dfa397c0 (task) calls=1 last=0
> fct=0x6464a1fc6fa0(ssl_async_fd_handler+0x3ecb0)
> ctx=0x73b3cc803b20
> lock_hist: S:PROTO U:PROTO W:PATEXP U:PATEXP S:PROTO U:PROTO
> S:CKCH locked: CKCH(S)
> call trace(24):
> | 0x6464a2117834 <00 00 00 e8 cc 08 e6 ff]:
> ha_dump_backtrace+0x84/0x40d > main-0x8b0
> | 0x6464a211abf6 <48 89 df e8 2a f4 ff ff]:
> ha_stuck_warning+0xf6/0x160 > ha_thread_dump_one
> | 0x6464a2237594 <00 00 00 e8 6c 35 ee ff]:
> wdt_handler+0x1e4/0x297 > ha_stuck_warning
> | 0x73b3cc645330 <00 00 00 00 0f 1f 40 00]: libc:+0x45330
> | 0x73b3ccb03b1c <fe 41 31 f0 44 89 40 08]:
> libcrypto:BN_consttime_swap+0x3c/0xb9
> | 0x73b3ccb00c2c <83 e7 01 e8 b4 2e 00 00]:
> libcrypto:BN_gcd+0x23c/0x30d > libcrypto:BN_consttime_swap
> | 0x73b3ccb0b3ab <4c 89 ff e8 45 56 ff ff]: libcrypto:+0x10b3ab
> > libcrypto:BN_gcd
> | 0x73b3ccb0b697 <89 5d a0 e8 e9 f9 ff ff]: libcrypto:+0x10b697
> > libcrypto:+0x10b080
> | 0x73b3ccd204cd <54 6a 00 e8 d3 af de ff]: libcrypto:+0x3204cd
> > libcrypto:+0x10b4a0
> | 0x73b3ccd20c1c <4c 89 ff e8 84 f7 ff ff]: libcrypto:+0x320c1c
> > libcrypto:+0x3203a0
> | 0x73b3ccdcdcbd <8b 73 18 e8 b3 63 f4 ff]: libcrypto:+0x3cdcbd
> > libcrypto:RSA_generate_multi_prime_key
> | 0x73b3ccc03e28 <83 ec 08 e8 f8 0b 00 00]: libcrypto:+0x203e28
> > libcrypto:+0x204a20
> | 0x73b3ccc0f5fa <fd ff ff e8 06 48 ff ff]:
> libcrypto:EVP_PKEY_generate+0x12a/0x2cf > libcrypto:+0x203e00
> | 0x6464a1fbdf72 <48 89 df e8 ce 9c fb ff]:
> ssl_async_fd_handler+0x35c82 > main-0xd70
> | 0x6464a1fc6dfa <8b 4d c8 e8 06 71 ff ff]:
> ssl_async_fd_handler+0x3eb0a > ssl_async_fd_handler+0x35c10
> | 0x6464a1fc722d <48 89 df e8 43 f6 ff ff]:
> ssl_async_fd_handler+0x3ef3d > ssl_async_fd_handler+0x3e580
> => Trying to gracefully recover now (pid 80921).
I'm surprised you are stuck this much in generating a private key, what CPU are
you using ? This is super slow for a 2048 key. For now the key generation is
not separated from the traffic thread, but we'll have to change that in the
future. If your CPU is too slow for that, you can try to migrate to ECDSA
P-384, it would cost less.
> acme: none.at.pem: Starting update of the certificate.
[...]
> acme: none.at.pem: dns-01 requires to set the "_acme-challenge.none.at" TXT
> record to "9MMRzvJDo0zBFT72sBY0R_qprSj2DDpgGp_BtU8IqfY" and use the "acme
[...]
> acme: none.at.pem: dns-01 requires to set the "_acme-challenge.none.at" TXT
> record to "jr7eGbpPeNcVHlbpwRM0MeqNZvXYhH351mrUw1EMCuk" and use the "acme
> challenge_ready none.at.pem domain none.at" command over the CLI
[...]
> -:- [21/Nov/2025:04:31:12.901] <ACME> -/- 5/0/0/485/488 200 1010 - - ----
> 0/0/0/0/0 0/0 {2606:4700:60:0:f41b:d4fe:4325:6026} "POST
> https://acme-staging-v02.api.letsencrypt.org/acme/chall/244744183/20346316043/1_f3SQ
Seems like a bug to me, since there are 2 domains it generated 2 challenges to
set but your wildcard has the same base as the 2nd domain so there's a
problem. I'll take a look.
The task seems stuck waiting for every challenge_ready. I think I'll add more
states in the `acme status` command so we can debug this more easily.
Regards,
--
William Lallemand
