Wildcard sertificates dosn't issueed have timeout (acme.sh)

That makes sense. If you’re using GET semantics, a 200 OK with no Content-Length header means to wait for the response…

i compile fresh curl version

[root@serv3 ~]# /opt/curl766/bin/curl -V
curl 7.66.0 (x86_64-pc-linux-gnu) libcurl/7.66.0 OpenSSL/1.0.1e-fips zlib/1.2.3
Release-Date: 2019-09-11
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS HTTPS-proxy IPv6 Largefile libz NTLM NTLM_WB SSL UnixSockets
[root@serv3 ~]#
[root@serv3 ~]#
[root@serv3 ~]# /opt/curl766/bin/curl -L --include --dump-header /root/.acme.sh/http.header -g --user-agent “acme.sh/2.8.3 (https://github.com/Neilpang/acme.sh)” -X HEAD -H “Content-Type: application/jose+json” https://acme-v02.api.letsencrypt.org/acme/new-nonce
Warning: Setting custom HTTP method to HEAD with -X/–request may not work the
Warning: way you want. Consider using -I/–head instead.
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 24 Sep 2019 09:28:08 GMT
Connection: keep-alive
Cache-Control: public, max-age=0, no-cache
Link: https://acme-v02.api.letsencrypt.org/directory;rel=“index”
Replay-Nonce: 0002Wj75ACEflSW5BXSiUVR-7hG5EM35YPFNl4WLAkHMJ7Q
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800


waiting waiting waiting waiting waiting waiting waiting waiting waiting …
^C

[root@serv3 ~]# ping acme-v02.api.letsencrypt.org
PING ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com (172.65.32.248) 56(84) bytes of data.
64 bytes from 172.65.32.248: icmp_seq=1 ttl=60 time=11.4 ms
^C
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 553ms
rtt min/avg/max/mdev = 11.414/11.414/11.414/0.000 ms

Interesting. I wonder why it works in 7.19.7 but not the current version. (Edit: did you build with nghttp2? I think you need to build with it for the fix)

I think we probably? found the real issue. And it’s one that either Let’s Encrypt/Cloudflare or the author of acme.sh has to fix.

In the meantime, you can try this temporary fix:

echo '104.110.202.18 acme-v02.api.letsencrypt.org' >> /etc/hosts

but don’t rely on it.

[root@serv3 ~]# /opt/curl766/bin/curl -L --include --dump-header /root/.acme.sh/http.header -g --user-agent “acme.sh/2.8.3 (https://github.com/Neilpang/acme.sh)” --head -H “Content-Type: application/jose+json” https://acme-v02.api.letsencrypt.org/acme/new-nonce
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 24 Sep 2019 09:31:09 GMT
Connection: keep-alive
Cache-Control: public, max-age=0, no-cache
Link: https://acme-v02.api.letsencrypt.org/directory;rel=“index”
Replay-Nonce: 0001FgztXh2dk9XCtwKJtmauV2BqCDgDhrIs9aEUwAUhHgk
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

[root@serv3 ~]# curl -L --include --dump-header /root/.acme.sh/http.header -g --user-agent “acme.sh/2.8.3 (https://github.com/Neilpang/acme.sh)” --head -H “Content-Type: application/jose+json” https://acme-v02.api.letsencrypt.org/acme/new-nonce
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 24 Sep 2019 09:31:15 GMT
Connection: keep-alive
Cache-Control: public, max-age=0, no-cache
Link: https://acme-v02.api.letsencrypt.org/directory;rel=“index”
Replay-Nonce: 0002XmBsNTOtJuKJ1jEotLNX5aXuzCBW6B2_wpBgAVALHrE
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

[root@serv3 ~]#

with --head
work fine!

Seems to be a related acme.sh pull request open:

I have the same issue which started today:

Yesterday I issue few certificates without issue.

My curl version is 7.66.

do you really sure,
that we must to do it :slight_smile:

where you get this IP 104.110.202.18 ?
can we trust it?

yes i build fresh curl with nghttp2 support!

That’s just the old IP before the new CDN. If it was malicious, it wouldn’t have a valid certificate for the Let’s Encrypt API domain.

But an even better fix is probably to just patch your acme.sh with the tiny fix from the PR that @mnordhoff linked.

  •    if _post "" "$nonceurl" "" "HEAD" "$__request_conent_type"; then
    
  •    if _post "" "$nonceurl" "" "HEAD --head" "$__request_conent_type"; then
    

(from here https://github.com/Neilpang/acme.sh/pull/2499/commits/cba97c58d5a6b93fc2ec1d415efa602332e530d1 )
right now i will try …

yes it works!
thanks to everybody!

1 Like

Thanks all you guys.

I will fix it soon.

2 Likes

I add the patch and it works.

But it shows this error too:

“Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 2”

can you please show the log with --debug 2 ?

@Neilpang

https://pastebin.com/raw/ZLL79zJc

is that error produced by your from-source build of curl? Does your system curl have the same problem?

Ι use the freebsd port system to compile curl. So I didn’t manually compile it from source.

@CyberCr33p it succeed in the log , right ?

Yes I can issue/renew certificates but the curl command throughts this error:

“Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 2”

Maybe the syntax of the curl command is not 100% correct.

please upgrade to the latest code and try again.

acme.sh  --upgrade

The same message with latest version.