Multi-domain generation and the two-step process

[Alexander-ARTV]

Hello and thank you for this handy script!

When running Crypt-LE to create a cert for both a wildcard and a naked domain as per the documentation:

le.pl ... --domains "*.some.domain, some.domain" --handle-as dns

The two step process with the --delayed flag does not work, the second run tries to create a new set of challenges instead of asking to verify the ones created in the first run.

Also, a flag to skip "When you see a text record returned, press " for automated setups would be greatly appreciated.

Best regards
Alexander

[Alexander-ARTV]

Did some more investigation and realized that it's the naked domain that seems to fail. See the

*.mydomain.com with --delay:
2025/01/23 10:16:07 [DEBUG] Requesting challenge. 2025/01/23 10:16:07 [DEBUG] Connecting to https://acme-staging-v02.api.letsencrypt.org/acme/authz/181478724/15806452724 2025/01/23 10:16:07 [DEBUG] Received challenges for *.mydomain.com.

*.mydomain.com finalizing stage:
2025/01/23 10:16:12 [DEBUG] Requesting challenge. 2025/01/23 10:16:12 [DEBUG] Connecting to https://acme-staging-v02.api.letsencrypt.org/acme/authz/181478724/15806452724 2025/01/23 10:16:13 [DEBUG] Received challenges for *.mydomain.com.

mydomain.com with --delay:
2025/01/23 10:15:00 [DEBUG] Requesting challenge. 2025/01/23 10:15:00 [DEBUG] Connecting to https://acme-staging-v02.api.letsencrypt.org/acme/authz/181478534/15806444494 2025/01/23 10:15:00 [DEBUG] Received challenges for mydomain.com.

mydomain.com finalizing stage:
2025/01/23 10:15:08 [DEBUG] Requesting challenge. 2025/01/23 10:15:08 [DEBUG] Connecting to https://acme-staging-v02.api.letsencrypt.org/acme/authz/181478534/15806445824 2025/01/23 10:15:08 [DEBUG] Received challenges for mydomain.com.

Will investigate some more if I can find the time, I haven't worked with Perl before so there's quite a bit to wrap my head around!

BR/A

[do-know]

I'll have to try and reproduce this. If I remember correctly, the original behaviour of Let's Encrypt at the time was that requesting a new challenge for the FQDN that just has been verified effectively put the requested challenge in the verified state immediately, without any need to actually complete the challenge. If that changed, I might have to re-visit the logic or provide a way to re-use the initial ID.

[Alexander-ARTV]

Hello, thanks for replying!

I wonder if that is the problem. If I run Crypt-LE interactively as a "one pass", everything works. It is only when I run the script twice, first with the --delayed flag and then without it that I get different authz codes the second run.

This makes me wonder, is there any warranty from the ACME protocol that it should return the same authz when requesting the challenge multiple times using the same CSR?
Or is it so that for the --delayed functionality to be robust, it would be necessary to have a corresponding --resume flag for the second pass that would tell Crypt-LE to skip requesting the challenge a second time, and go straight to the verification phase? This would perhaps need to include creating a temp-file to store relevant information between the passes.

I'm ploughing through the RFC8555 right now to try to get a better understanding of this, but I haven't gotten through it yet.

I assume this is also basically what a complete-with plugin would take care of. I'm just not skilled enough to make such a module yet, so I'm trying to make this happen by using the --delayed-functionality and handling everything else externally with Powershell, including distributing the resulting cert to our broad number of devices that need it.

BR
Alexander

[Alexander-ARTV]

Hello again!

Ok, so now I get it. I managed to add the raw request return value to the debug output of C-LE, and combined with what I learnt from the RFC, I managed to google my way to this thread:

letsencrypt/boulder#3335

The orders key for the account object is not implemented, and because of this, the --delayed option would need the client to save the authz information itself for a subsequent run to be meaningful.

I'll see if I can bodge something together :)

Best regards
Alexander

[He-Man321]

Hi, did you get anywhere with this?

As it stands, it seems impossible to use this to create a wildcard certificate with the root domain in an automated manner for two reasons:

1. When you run the first (--Delayed) step it generates the first two keys, but when you then re-run it for the second step it generates two different keys, meaning the first two you have added to the DNS by that stage are now wrong!
2. When you run the second step, it prompts you to "press " to continue, which makes it impossible to automate it! This second issue may be as a consequence of the first issue, so fixing that may solve this issue, but in a tool designed for automation, who thought an unavoidable user prompt was ever going to be a good idea?

Just as a general observation; is it just me, or is the promise of simple, automated certificate renewals a bit of a joke? The two of us can't be the first people to try and use this for automated wildcard certificates with the root domain (a pretty typical requirement for any web site) in the two year since 0.39 was released can we? Or are we the only ones who have managed to battle with lines and lines of complex PowerShell (why on earth are the required keys not output from the first step in a useable format!) to try and make this work, only to fall at this insurmountable issue?

[Alexander-ARTV]

Hi, did you get anywhere with this?

As it stands, it seems impossible to use this to create a wildcard certificate with the root domain in an automated manner for two reasons:

1. When you run the first (--Delayed) step it generates the first two keys, but when you then re-run it for the second step it generates two different keys, meaning the first two you have added to the DNS by that stage are now wrong!

2. When you run the second step, it prompts you to "press " to continue, which makes it impossible to automate it! This second issue may be as a consequence of the first issue, so fixing that may solve this issue, but in a tool designed for automation, who thought an unavoidable user prompt was ever going to be a good idea?

Just as a general observation; is it just me, or is the promise of simple, automated certificate renewals a bit of a joke? The two of us can't be the first people to try and use this for automated wildcard certificates with the root domain (a pretty typical requirement for any web site) in the two year since 0.39 was released can we? Or are we the only ones who have managed to battle with lines and lines of complex PowerShell (why on earth are the required keys not output from the first step in a useable format!) to try and make this work, only to fall at this insurmountable issue?

Hello He-Man321, I finally got around to investigate this further. Together with nurturing a strong aversion for Perl, I did manage to solve the issue.

For Crypt-LE, this means being able to add a -resume flag when you want to run the second pass to verify, as well as providing the challenge tokens conveniently in files.

I have done a pull request for the feature, but I do suggest you taking a look at the wrapper script I created along with a few necessary bits and bobs here https://github.com/Alexander-ARTV/Crypt-LE-helper as it provides a complete solution for unattended certificate creation and distribution.

BR
Alexander

[He-Man321]

Good job Alexander, but I am afraid after this I gave up with Crypt-LE, as despite coming up with extensive PS scripts to do the DNS stuff with GoDaddy, it felt very much like we were forging an unexplored path, and I need something suitable for production use. There were other issues, like it using RC2-40-CBC for the certificates, which then causes issues with OpenSSL (which I did solve with more script, but more hacky stuff I didn't like). I am currently using Posh-ACME, which seems somewhat simpler as much of the script (LE, GoDaddy and IIS) is already done for you and it outputs the certificates in both Windows and Linux friendly formats removing the need for OpenSSL. Good luck though, more simpler (and working) options are certainly needed...

[Alexander-ARTV]

I totally understand, at some point during dissecting Crypt-LE I realised that it might just have been simpler to write my own implementation from scratch, but it was a mostly fun exercise gaining knowledge about a language that I haven't had to deal with in decades. Vague memories of early web dev and Perl scripts in cgi-bin emerge.
And now that I've gotten a better grip of the process I think that I could just have used Certbot from the beginning and be done with it. When I started looking for alternatives it looked too focused on automating for a single server, but now I understand what to look for in the CL syntax. I do like these small customisable projects though, will check out Posh-ACME as well.