Renew of certificates fails randomly in the last month

Hi all,

renew of certificates (with UACME) fails apparently random.
it ask for DNS challenge while i use HTTP (uacme) challenge.

My domain is: it happens with a number of domains (.it .net .com) it seems random

I ran this command:

uacme issue www.jaimeaymerichhollywood.com --c c:/uacme -h hook_jaimeaymerich-hollywood_com.cmd

It produced this output:

uacme: challenge https://acme-v02.api.letsencrypt.org/acme/chall-v3/413012423747/r9vJZw failed with status invalid
uacme: the server reported the following error:
{
"type": "urn:ietf:params:acme:error:dns",
"detail": "DNS problem: NXDOMAIN looking up TXT for _acme-challenge.www.jaimeaymerichhollywood.com - check that a DNS record exists for this domain",
"status": 400
}
uacme: failed to authorize order at https://acme-v02.api.letsencrypt.org/acme/order/68817448/311513789397

My web server is (include version): Apache/2.4.57 (OS/2) OpenSSL/1.1.1q
and Apache/2.4.61 (OS/2) OpenSSL/1.1.1l
It happens on both VMs
I also tried to turn off the firewall, but nothing changes, the situation is the same

The operating system my web server runs on is (include version): AOS 5.x

My hosting provider, if applicable, is: me

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:
variuous uacme 1.0.19 and 1.2.4 (the issue happens with both versions)

The domains have the CAA entry in the bind (9.11.37) zone, eg:

jaimeaymerichhollywood.com. CAA 0 issue "letsencrypt.org"

Please help
thanks
regards

massimo

1 Like

Please show this file, as it looks like it does like, everything important.

it's the same since years (it's a rexx script), i never changed any path or code
and as you can see there is also the new token in the challenge dir, anyway:

/* comando di hook per client uacme */

parse arg var1 var2 var3 var4 var5
myfile = 'x:\apache\htdocs\jaime-hw.well-known\acme-challenge'||var4
call SysFileDelete 'x:\apache\htdocs\jaime-hw.well-known\acme-challenge'||var4
rc= LINEOUT(myfile,var5)

challenge directory content:

7/10/24 12:39 124 ---- .
29/09/20 12:20 124 ---- ..
26/03/21 12:00 89 0 a--- 1uGwiFxH8PNpne6ZZIqpJKH6xoOsJVTwTym-ZBSPOhc
5/08/21 21:01 89 0 a--- 5rpa3R7H58WhCJG6tk0fU7ZyONhdGwg4hkgWtmJjo4k
5/02/23 21:01 89 0 a--- 6TIve_omKWKaOGMeFfMcmgVmcuOIrbOqzeV48SKn7do
6/10/24 20:26 45 0 a--- 9Uxcj517OhPWplTvEKlLW0aFOc72NtgD-RU5p149N1Y
5/06/22 21:01 89 0 a--- 9VRO5EuSt2J_qhzz-h4B2lpc9zZF-_loCIyzI8TqACo
5/12/22 21:01 89 0 a--- ahb_VerI4TTN2zzF40CTt6FqSnkHXy0QH3mnD3WZpNI
5/04/24 21:01 89 0 a--- Bdk-kDfaVOyOQt5h8BDchnQ6EhSX7oBZxv8WzN235kk
5/06/24 21:01 89 0 a--- bjCdnTYptBUGxbQWAfze6j_Pe685kZPnjEnUKmbEoMQ
5/04/22 21:01 89 0 a--- BtHMECpLkwTcg_gxXrxg4hZSMv0ikxioP3AGurWn024
6/10/24 20:51 45 0 a--- dtXTBnim3hH67WRvm6iAn-R-Lfe9RAGx3m--tfzHzjA
5/04/23 21:01 89 0 a--- eFq_r99zsdMY0ulUbbG43UhWDPwg5vor3XQ4iLubWzc
5/10/21 21:01 89 0 a--- gF5A1vEzZyquMnZdwrQk-256xKFvAR-xs_LiKtiI1UA
5/02/22 21:01 89 0 a--- hUJn3Fs4kCMpHDU1m7dA8nLAOTP207EFSpxATkjgDQk
5/10/22 21:01 89 0 a--- IL0vSUtgc5eoSdY-gzq4cBg1wzrTuGwfo3VcKqlwfr4
5/12/23 21:01 89 0 a--- iWwCcSNFaJ58cz6pOsPh4PL2NDr3J4SGcl-k8MJDDUM
7/10/24 11:21 45 0 a--- k04HchnSgmmBnQMdQqZ66fza_XB3nphD98BTO27w-n0
5/08/23 21:01 89 0 a--- L05LaQ7sEVmFIyEX1Fmn6kob_lTCiE58ZZ0lYD09k9U
5/06/23 21:01 89 0 a--- L_Uy4fFzEb2QsO0pnpg1GiJtyjrN9sT14RPpLI8Mxck
5/12/21 21:01 89 0 a--- rIqxWZgoCFrmQXJLxbsGAcXKPgvZzbuOCO-GRW0PRPI
6/10/24 20:46 89 0 a--- RSrSSb7WRWwKfNfeSnn-XTViicP5GmlnkyZ1kYf1V8I
6/10/24 21:09 45 0 a--- rT9rm8g7AsWFZX6P2vrchP53Xp6tXnaIaDsFsrOSKj4
2/06/21 21:58 89 0 a--- SDzMHmXE7XvDRL3eyZAJGJ-WZdZRQB_qifTT-0hYW5U
5/02/24 21:01 89 0 a--- soKjtwUABzg4nnaUeUz2cu98v5tGLl8ZVp61Ixk9sxU
5/08/24 21:01 89 0 a--- ttj1oY1r_HpAiGBUArk5Sdy1F69vvZvrB95vd0fP7WQ
5/08/22 21:01 89 0 a--- VTLj0nqNvs0aAaay-riC0TlWO36-yxDhQsqJzUZU4lo
5/10/23 21:01 89 0 a--- XjBWkB8cEpOhYKxqOxOD-NzwBK7CmEI3jzebADDE7NA
4/08/21 21:11 89 0 a--- xPtZ6XViqd63DlJclt_UMBu3LrkgEvQoCPsn3cJh-nI
6/10/24 20:42 45 0 a--- _b_JqDjGvQIM5x97h6anwjqiTV8JphGnmmbxwDw0GSs
31 file(s) 2.958 bytes used

hm, but how does uacme know it must use the http-01 challenge? If I read the README correctly, uacme can also do the dns-01 challenge.

So something should tell uacme it must use the http-01 challenge.

Their own example checks the challenge type in the second argument (see uacme/uacme.sh at e9cfa6f052644864a28c7d9d04756900abfc653f · ndilieto/uacme · GitHub) and skips everything if the type is not http-01. Maybe you should update your script.

I believe this might be caused due to the fact that Let's Encrypt earlier put the challengs in a specific order with http-01 always being the first, but they've changed that recently in that the order is randomised.

You should update your script so it only does stuff for the http-01 challenge and skips the dns-01 and tls-alpn-01 challenge. See the example I've posted above.

For more details on how to do that, please refer to the uacme support channels, as I don't think there's much experience with that ACME client here.

1 Like

ok, thank you
but that it's a sh script that i can't use, since i'm not on a *nix OS.

i don't see any option to force http-01, or maybe it's the -a option
i've seen the readme, but it's not clear
i also opened a ticket on github/uacme

usage: uacme.exe [-a|--acme-url URL] [-b|--bits BITS] [-c|--confdir DIR]
[-d|--days DAYS] [-f|--force] [-h|--hook PROGRAM] [-m|--must-staple]
[-n|--never-create] [-o|--no-ocsp] [-s|--staging] [-t|--type RSA | EC]
[-v|--verbose ...] [-V|--version] [-y|--yes] [-?|--help]
new [EMAIL] | update [EMAIL] | deactivate | newkey |
issue IDENTIFIER [ALTNAME ...]] | revoke CERTFILE

massimo

1 Like

Yes, but you can analyse the script to see how they make sure only the http-01 challenge is being used.

They somehow skip every challenge which is NOT the http-01 challenge.

But that's about all I can read from the script.

1 Like

You could also switch ACME clients.
I've used CertifyTheWeb without a problem.

3 Likes

i use apache, but also my OS in the VM is not Windows
uacme is recompiled with GCC for AOS/eCS
that are recent (and supported) distros of OS/2 Warp

1 Like

My mind just time traveled back to the '80s!
image

5 Likes

now that i've put the -v (verbose option) in UACME i can see this:
http-01
www.jaimeaymerichhollywood.com
VfD7yNIXE4R3KaS8CsBD8thkrZo3W9a3YDyWQHcOxVo
VfD7yNIXE4R3KaS8CsBD8thkrZo3W9a3YDyWQHcOxVo.zyhanFlpd0tloojCJrdfZjZwx4LbkQHuYa75ndsa-Qs
x:\apache\htdocs\jaime-hw.well-known\acme-challenge\VfD7yNIXE4R3KaS8CsBD8thkrZo3W9a3YDyWQHcOxVo
done
http-01
www.jaimeaymerichhollywood.com
VfD7yNIXE4R3KaS8CsBD8thkrZo3W9a3YDyWQHcOxVo
VfD7yNIXE4R3KaS8CsBD8thkrZo3W9a3YDyWQHcOxVo.zyhanFlpd0tloojCJrdfZjZwx4LbkQHuYa75ndsa-Qs

this time i've been lucky and http-01 challenge has worked

but the other times i saw also the tls-alpn-01 or dns-01 challenges
this will give me a bad headache

massimo

ehm.. you are wrong
but we are going off topic, so this is my last reply to the OS stuff

What am I wrong about?
You mentioned it:

I only commented on it...

But, yes, it may not very relevant to the solution.
But it is not off topic - you opened it up for discussion.

3 Likes

Yes, as I said, somewhere in the recent past Let's Encrypt randomises the order of the challenges in the autz. So you've got ⅓ chance of getting http-01 as the first one.

Your script needs to check which challenge is being processed by it and only respond if it's the http-01 challenge, just like how the sh script does it. I know you can't use it directly, but you should use the sh script as an example how the workflow needs to be.

1 Like

Is your uacme related to the one described below? Because they had identical problem as you experience and the poster was the author of the script. If yours is the same or derived from that one perhaps they can help.

4 Likes

thank you
the issue is the same
but there is not a solution
even if an answer has been flagged as solution

1 Like

There was for them. The problem is essentiallt the same: Let's Encrypt randomises the challenges contained in an authorization nowadays, whereas earlier the order was fixed, starting with the http-01 challenge. (As I've said twice already.) Only their own wrapper script wasn't capable of handeling this. In your case it's your Rexx script not capable of handeling this randomised order of the challenges.

The SOLUTION to your problem is to MODIFY your script to behave like the uacme.sh script I linked to earlier.

As it seems like you're struggling to grasp that script for some reason, let me explain it in more detail:

Your script needs to return a non-zero return value if it detects a challenge it does NOT want to use (e.g., the dns-01 and/or tls-alpn-01 challenge). See the exit 1 in the example uacme.sh script.
If your script detects the right challenge (e.g, http-01) as the second argument (see TYPE=$2 in the uacme.sh example script), then it needs to do its thing (if run with the begin method as the first argument, see METHOD=$1 in the uacme.sh example script) and return zero (i.e. "success" in *nix terms; the uacme.sh script used exit $? to pass through the result of the last operation, which was the challenge handeling stuff) if it has set up everything for the challenge (or if it has removed everything when used for the done or failed method.

I'm afraid I don't think I can explain it any simpler than the above.

3 Likes

yes, ok
i can of course modify my hook rexx script :slight_smile:
i will try

thank you

3 Likes

hey, do you have changed something server side?

4 reissues in a few minutes all successfull

uacme: version 1.2.4 starting on Mon, 07 Oct 2024 18:19:16

uacme: generating certificate request
etc. etc. etc.

I'm just a volunteer here, like most of us on this Community. You can recognise Let's Encrypt employees by their "Let's Encrypt staff" title.

Could be either luck or, most likely, re-use of a previously validated authorizations. Valid authorizations are cached for 30 days and if you try to reissue a certificate forcibly, it can be reused.

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.