You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I suspect the error is an issue on the Let's Encrypt API side;
+ Requesting new certificate order from CA...
ERROR: Problem connecting to server (post for https://acme-v02.api.letsencrypt.org/acme/order/60114411/163661034166; curl returned with 35)
EXPECTED value GOT EOF
but dehydrated then leaves us with a PEM file that contains nothing except some script output;
# INFO: Using main config file config-http-01
This happens when using dehydrated with --signcsr, --alias, and --out to write the file to a specific directory that also contains the CSR and the private key.
The retry logic mentioned in #792 works well while handling authorizations, but fails here? Hoping this will clear up once the Let's Encrypt API resolves whatever is causing this, but it's probably a good idea to not write a PEM file in this situation?
The text was updated successfully, but these errors were encountered:
Same problem, but with retry during authorization handling;
ERROR: Problem connecting to server (head for https://acme-v02.api.letsencrypt.org/acme/new-nonce; curl returned with 35)
! Request failed (badNonce), retrying request...
Update: It looks like the retry logic works for the new-nonce action, but not for some of the other API calls. Here's another error;
ERROR: Problem connecting to server (post for https://acme-v02.api.letsencrypt.org/acme/authz-v3/201906708426; curl returned with 35)
EXPECTED value GOT EOF
Same result, invalid PEM file. Curl version output;
I suspect the error is an issue on the Let's Encrypt API side;
but dehydrated then leaves us with a PEM file that contains nothing except some script output;
This happens when using dehydrated with
--signcsr
,--alias
, and--out
to write the file to a specific directory that also contains the CSR and the private key.The retry logic mentioned in #792 works well while handling authorizations, but fails here? Hoping this will clear up once the Let's Encrypt API resolves whatever is causing this, but it's probably a good idea to not write a PEM file in this situation?
The text was updated successfully, but these errors were encountered: