Re: Some questions about ACME challenge dns-01

Fri, 21 Nov 2025 01:46:11 -0800 

Hi William.

On 2025-11-21 (Fr.) 10:18, William Lallemand wrote:

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.


Okay.


     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.


I assumed that, thanks for confirmation.


     map virt@acme


the map is not needed for dns-01.


I assumed that, thanks for confirmation.


```

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.


I have this CPU.

```shell
alex@alex-tuxedoinfinitybooks1517gen7 on 21/11/2025 at 10:38:18_CET /datadisk/git-repos/haproxy $ 
# lscpu
Architecture:                x86_64
  CPU op-mode(s):            32-bit, 64-bit
  Address sizes:             39 bits physical, 48 bits virtual
  Byte Order:                Little Endian
CPU(s):                      16
  On-line CPU(s) list:       0-15
Vendor ID:                   GenuineIntel
  Model name:                12th Gen Intel(R) Core(TM) i7-1260P
    CPU family:              6
    Model:                   154
    Thread(s) per core:      2
    Core(s) per socket:      12
    Socket(s):               1
    Stepping:                3
    CPU(s) scaling MHz:      13%
    CPU max MHz:             4700,0000
    CPU min MHz:             400,0000
    BogoMIPS:                4992,00
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm co nstant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx es t tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid _fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx s map clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect user_shstk avx_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act _window hwp_epp hwp_pkg_req hfi vnmi umip pku ospke waitpkg gfni vaes vpclmulqdq rdpid movdiri movdir64b fsrm md_clear serialize arch_lbr ibt flush_l1d 
                              arch_capabilities
Virtualization features:
  Virtualization:            VT-x
Caches (sum of all):
  L1d:                       448 KiB (12 instances)
  L1i:                       640 KiB (12 instances)
  L2:                        9 MiB (6 instances)
  L3:                        18 MiB (1 instance)
NUMA:
  NUMA node(s):              1
  NUMA node0 CPU(s):         0-15
Vulnerabilities:
  Gather data sampling:      Not affected
  Ghostwrite:                Not affected
  Indirect target selection: Not affected
  Itlb multihit:             Not affected
  L1tf:                      Not affected
  Mds:                       Not affected
  Meltdown:                  Not affected
  Mmio stale data:           Not affected
  Reg file data sampling:    Mitigation; Clear Register File
  Retbleed:                  Not affected
  Spec rstack overflow:      Not affected
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization Spectre v2: Mitigation; Enhanced / Automatic IBRS; IBPB conditional; PBRSB-eIBRS SW sequence; BHI BHI_DIS_S 
  Srbds:                     Not affected
  Tsa:                       Not affected
  Tsx async abort:           Not affected
  Vmscape:                   Mitigation; IBPB before exit to userspace
```


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.


Thank you.
Maybe some `trace acme ...???` can help here?
I will wait for your patches to test the ACME DNS setup to make it production reday :-) 

Should I create an Issue for that or do you want to keept the work on the ML?


Regards,


Regards
Aleks

Reply via email to