Server has not Provided an Order URL upon account creation

[puphubv]

WARN acmed::account] account "letse": endpoint "LetsEncryptStaging": account "letse": the server has not provided an order URL upon account creation

Most recent github version, compiled for release.

Whole log section:

[2024-12-16T19:07:27Z DEBUG reqwest::connect] starting new connection: https://acme-staging-v02.api.letsencrypt.org/
[2024-12-16T19:07:27Z TRACE acmed::http] HTTP response headers: {"server": "nginx", "date": "Mon, 16 Dec 2024 19:07:27 GMT", "content-type": "application/json", "content-length": "329", "connection": "keep-alive", "boulder-requester": "176XX224", "cache-control": "public, max-age=0, no-cache", "link": "https://acme-staging-v02.api.letsencrypt.org/directory;rel="index"", "link": "https://letsencrypt.org/documents/LE-SA-v1.4-April-3-2024.pdf;rel="terms-of-service"", "location": "https://acme-staging-v02.api.letsencrypt.org/acme/acct/176335224", "replay-nonce": "QOVu-bnaJaJ5aXXXX8Vo", "x-frame-options": "DENY", "strict-transport-security": "max-age=604800"}
[2024-12-16T19:07:27Z TRACE acmed::http] HTTP response body: {
"key": {
"use": "sig",
"kty": "EC",
"crv": "P-256",
"alg": "ES256",
"x": "iME9AoVeUXXXXuudUsdyjM",
"y": "nBMnaMwbXXXHBw"
},
"contact": [
"mailto:letse@XXX"
],
"createdAt": "2024-12-16T19:07:27.718365046Z",
"status": "valid"
}
[2024-12-16T19:07:27Z WARN acmed::account] account "letse": endpoint "LetsEncryptStaging": account "letse": the server has not provided an order URL upon account creation
[2024-12-16T19:07:27Z TRACE acmed::storage] account "letse": writing file "accounts/bGV0c2XXX5cHQ.account.bin"
[2024-12-16T19:07:27Z INFO acmed::account] account "letse": account created on endpoint "LetsEncryptStaging"
[2024-12-16T19:08:03Z TRACE acmed::http] POST request body: {"protected":"eyJXXXXyIn0","payload":"eyXXXX0","signature":"160UBXXXX3Q"}

[breard-r]

Yes, that's an issue on Boulder, and therefore it affects Let's Encrypt.
letsencrypt/boulder#3335

It brings me bad memories.
0db5e68

[puphubv]

Did you see this change that was implemented?

robur-coop/ocaml-letsencrypt@f9bccd6

Any suggestions besides trying ZeroSSL for example?

[breard-r]

Did you see this change that was implemented?

robur-coop/ocaml-letsencrypt@f9bccd6

As far as I understand it, this is just another ACME client doing the same workaround as I did.

Any suggestions besides trying ZeroSSL for example?

Yes: just ignore this warning. It's here only to remind that let's Encrypt uses a non-compliant implementation, but ACMEd (as well as most ACME clients) still works correctly.

[puphubv]

Thanks for your comment, as I had given up since I've been seeing the program hang not long after getting that warning.

ACMEd is getting stuck after calling the "auth-dns-01-hook" which sets up the TXT record and sleeps 900 seconds.

The config and auth.sh file is essentially the same as the Example-DNS-Config.md code in acmed-wiki.

It's just seems to endless hang, although I've only waited a maximum of 2 or so hours so far.

ACMEd is a straight release build from 2 days ago, but it seems like I got farther with a debug version that included updated dependencies.

Any ideas?

[puphubv]

Update... Indeed, the debug version with updated dependencies did not hang, but did generate an unexpected error even with a non-wildcard certificate:

[2024-12-17T19:43:40Z TRACE acmed::http] HTTP response body: {
"type": "urn:ietf:params:acme:error:badCSR",
"detail": "Error finalizing order :: invalid public key in CSR: unsupported key type ed25519.PublicKey",
"status": 400
}

[breard-r]

but did generate an unexpected error even with a non-wildcard certificate:

Yeah, don't use EdDSA (Ed25519 or Ed448) certificates. Although Ed25519 would be my personal top recommandation, there is almost no support of it anywhere when it comes to X.509 TLS certificates.

[puphubv]

A few questions:

I was recently surprised by the name, identifier and dns fields all having close to the same meaning at different times/places when using ACMEd

I'm wondering if it would make sense to redo the software so identifier, name and dns don't mean mean the same thing at times. (dnip or domnameip or subject)

Any chance we could get away from the name field in the certificate section of the toml file?

Here is the trace log where a file was not written to the specified directory:

[2024-12-18T05:29:32Z DEBUG acmed::certificate] certificate "dom_rsa2048": hook "cleanup-dns-01-hook": exited: code 0
[2024-12-18T05:30:08Z TRACE acmed::http] POST request body: {"protected":"eyJhbGciOiJFUzI1NiIsImtpZCI6Imh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL2FjY3QvMjExOTczMDYwNSIsIm5vbmNlIjoiV1ZXVER4bUp3OUw4SXBkMFBXU2h5NURBMWNlQ3ZReVVNNFJPaDNLNlBIY1NISy1EUzk4IiwidXJsIjoiaHR0cHM6Ly9hY21lLXYwMi5hcGkubGV0c2VuY3J5cHQub3JnL2FjbWUvYXV0aHovMjExOTczMDYwNS80NDY1ODY5OTE5MjUifQ","payload":"","signature":"GsjecP0KJNiyALJoLTl48xTmNtY7nmxe-ADBK0P8GqO_5CBMWSXxQcn0l6rrn-jNguOQZ5Sc8f0QuVHfctSbeg"}
[2024-12-18T05:30:08Z DEBUG reqwest::connect] starting new connection: https://acme-v02.api.letsencrypt.org/

Note, running in staging mode did create one file out of 6 or so requested certs, so I believe that my configuration was accurate.

I also ran into an issue since I have a lot of domains:

[2024-12-18T01:49:17Z TRACE acmed::http] HTTP response body: {
"type": "urn:ietf:params:acme:error:malformed",
"detail": "Order cannot contain more than 100 DNS names",

Is that something easy to work around? Multiple accounts / certificate sections perhaps?

Note, this error was produced repeatedly, and did not appear when I was in warn or debug mode, but only in trace mode.

Could this sort of situation explain why I've had issues where the software seems to hang?

Is it critical that you reproduce a new account when switching from staged to production?

[breard-r]

I was recently surprised by the name, identifier and dns fields all having close to the same meaning at different times/places when using ACMEd

I'm wondering if it would make sense to redo the software so identifier, name and dns don't mean mean the same thing at times. (dnip or domnameip or subject)

Absolutely not. These are the terms used in RFC 8555 (see sections 7.1.3 and 9.7.7), using anything else would be confusing and require knowledge specific for ACMEd instead of general and reusable knowledge about the ACME protocol.

Here is the trace log where a file was not written to the specified directory:

This log doesn't show anything unusual.

I also ran into an issue since I have a lot of domains:

[2024-12-18T01:49:17Z TRACE acmed::http] HTTP response body: { "type": "urn:ietf:params:acme:error:malformed", "detail": "Order cannot contain more than 100 DNS names",

Is that something easy to work around? Multiple accounts / certificate sections perhaps?

This is a server-side limitation from the CA. You should split your domain names between several certificates to go past this limit.

Note, this error was produced repeatedly, and did not appear when I was in warn or debug mode, but only in trace mode.

This is not an error, it's the raw response from the CA's server. However, it would have been displayed afterwards as either an error or a warning. If not, that would be a bug in ACMEd.

Could this sort of situation explain why I've had issues where the software seems to hang?

I don't have sufficient information about your issue to guess what is going on.

Is it critical that you reproduce a new account when switching from staged to production?

It doesn't seems related to the account itself, but anyway you should always use a different account on each endpoint.

[puphubv]

Thanks... Your answers are very helpful.

Is it true that the best time to rename the name-key_type.pem from name to identifier.0-key_type.pem is in the post operation script?

Since identifier is an array, it seems like you could sometimes have more than one cert to rename, but name is always only a single entity. Can I assume that I'll never have more than 1 new identifier to rename using namekey_type-pk/cert.ext in the post-operation?

One point of confusion for example: I can get a single cert created as name-type-pk/crt.pem... and if I leave it as that name the software seems happy and looks like it's ready to sleep for 70 days... but if I rename it in the post-operation, it restarts the cert request to regenerate the same cert again. I'm considering copying instead of renaming, but that seem like it will cause trouble when certs start to renew.

Any chance you have some hook or script examples of everything you need to do to rename certs for a lot of new domains.

Or is it just easier to only ever process new certs as single cert requests... and only later let ACMEd loose on the whole batch after they've been created when renaming won't be any trouble.

or would it be best to generate 1 cert at a time, changing the certificate name field to the single domain name for each creation run so the post-operation doesn't need to rename the cert?

Thanks in advance.

[breard-r]

Is it true that the best time to rename the name-key_type.pem from name to identifier.0-key_type.pem is in the post operation script?

No. The best way is to use the name config option in the certificate section of the configuration. By the way, the default name is the first identifier, so I don't understand what you are trying to achieve here.

if I leave it as that name the software seems happy and looks like it's ready to sleep for 70 days... but if I rename it in the post-operation, it restarts the cert request to regenerate the same cert again

Yes, if you delete (or move) a certificate, then ACMEd will ask for a new one. This is intentional behavior.

I'm considering copying instead of renaming, but that seem like it will cause trouble when certs start to renew.

You might want to create a symbolic link instead.