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:
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:
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.
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
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.
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.
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.
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.