There appears to be a problem with the way in which dehydrated builds and uses ACCOUNT_URL within init_system()
The current behaviour seems to assume Let's Encrypt specific behaviour, and does not appear to match RFC8555 behaviour description.
Regardless, dehydrated should have a way to force the URL to what an alternate ACME API may expect, given variations between RFC interpretation and actual behaviour in different ACMEv2 API implementations.
Note, correct ACCOUNT_URL seems to found/used on the very first order when the new account API endpoint was used, and it's only on subsequent requests that problems occur.
The DigiCert ACME API responds with this error,
{"detail":"No Key ID in JWS header","status":400,"type":"malformed"}
However the problem is that the account URL included in the order request is simply an empty string.
There appears to be a problem with the way in which dehydrated builds and uses ACCOUNT_URL within init_system()
The current behaviour seems to assume Let's Encrypt specific behaviour, and does not appear to match RFC8555 behaviour description.
Regardless, dehydrated should have a way to force the URL to what an alternate ACME API may expect, given variations between RFC interpretation and actual behaviour in different ACMEv2 API implementations.
Note, correct ACCOUNT_URL seems to found/used on the very first order when the new account API endpoint was used, and it's only on subsequent requests that problems occur.
The DigiCert ACME API responds with this error,
{"detail":"No Key ID in JWS header","status":400,"type":"malformed"}
However the problem is that the account URL included in the order request is simply an empty string.