Originally created by @sindarina on GitHub (Feb 8, 2023).
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?
Originally created by @sindarina on GitHub (Feb 8, 2023).
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?
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;
@sindarina commented on GitHub (Feb 8, 2023):
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;
```
$ curl -V
curl 7.87.0 (x86_64-apple-darwin22.1.0) libcurl/7.87.0 OpenSSL/3.0.8 zlib/1.2.13 brotli/1.0.9 zstd/1.5.2 libidn2/2.3.4 libpsl/0.21.2 (+libidn2/2.3.4) nghttp2/1.51.0
Release-Date: 2022-12-21
Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTPS-proxy IDN IPv6 Largefile libz NTLM NTLM_WB PSL SSL threadsafe TLS-SRP UnixSockets zstd
```
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @sindarina on GitHub (Feb 8, 2023).
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--outto 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?
@sindarina commented on GitHub (Feb 8, 2023):
Same problem, but with retry during authorization handling;
Update: It looks like the retry logic works for the
new-nonceaction, but not for some of the other API calls. Here's another error;Same result, invalid PEM file. Curl version output;