acme-client: acme-client issue hangs after authorization
acme-client issue
seems to hang on issuing cert step at some point.
I’ve only had one or or maybe two certs successfully issued, so I don’t think I’m being rate limited?
(I confirmed this via https://crt.sh/?Identity=%25MYDOMAIN.com&iCAID=16418
, shows only 1 recently issued)
In any case, I get no error output, the client just seems to hang.
Originally, I was able to successfully get one cert for mydomain.com
and www.mydomain.com
.
However, since then I’ve been unable to get a new cert, for any new / different domain.
I’ve read some posts from other users having networking problems (routing, dns, firewall, etc). Their symptoms seem to be the same as mine, however their situation was different. So I suspect there is some network issue (see below for network output from environment). I notice I get no response via PING… (again, see below, networking) cURL request works fine most of the time, I did notice it hangs sometimes as well (maybe on trying to select correct enc type for connection?)
However, I’m unable to troubleshoot or diagnose any further, as I’m not sure where else to look. Any assistance / suggestions would be greatly appreciated!
Setup works fine:
$ acme-client setup --email MYEMAIL@MYCOMPANY.com
Using existing private key ...
Registering with acme-staging.api.letsencrypt.org/directory ...
Registration successful. Contacts: mailto:MYEMAIL@MYCOMPANY.com
Using $ acme-client auto
command results in no output (probably hangs in same spot)
Using issue
command directly:
$ acme-client issue -d MYDOMAIN.com:www.MYDOMAIN.com -p /home/USER/MYDOMAIN.com
Providing payload at http://MYDOMAIN.com/.well-known/acme-challenge/asdfasdfasdfCHALLENGECODE
MYDOMAIN.com is now authorized.
Using issue
command directly, with staging server:
$ acme-client issue -d MYDOMAIN.com:www.MYDOMAIN.com -p /home/USER/MYDOMAIN.com
Providing payload at http://MYDOMAIN.com/.well-known/acme-challenge/asdfasdfasdfCHALLENGECODE_SAME_AS_RETURNED_BY_NON_STAGING_SERVER
MYDOMAIN.com is now authorized.
Please note: in both cases the output hangs on newline after authorized output.
Environment cPanel (Shared Hosting),
$ uname -a
Linux hostname 2.6.32-773.26.1.lve1.4.46.el6.x86_64 #1 SMP Tue Dec 5 18:55:41 EST 2017 x86_64 x86_64 x86_64 GNU/Linux
PHP Versions available (tried with php56, php70, php71):
$ php -v
PHP 7.0.22 (cli) (built: Aug 30 2017 09:24:24) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
with the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured) v6.0.9, Copyright (c) 2002-2016, by ionCube Ltd.
$ /opt/php56/bin/php -v
PHP 5.6.31 (cli) (built: Jul 13 2017 12:42:45)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
with the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured) v5.1.1, Copyright (c) 2002-2016, by ionCube Ltd.
with Zend Guard Loader v3.3, Copyright (c) 1998-2014, by Zend Technologies
$ /opt/php71/bin/php -v
PHP 7.1.7 (cli) (built: Jul 17 2017 08:47:06) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
$ openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013
PHP with openssl support:
$ php -i | grep -i OPENSSL
Configure Command => './configure' ... '--with-openssl' ...
SSL Version => OpenSSL/1.0.1e
openssl
OpenSSL support => enabled
OpenSSL Library Version => OpenSSL 1.0.1e-fips 11 Feb 2013
OpenSSL Header Version => OpenSSL 1.0.1e-fips 11 Feb 2013
Openssl default config => /etc/pki/tls/openssl.cnf
openssl.cafile => no value => no value
openssl.capath => no value => no value
Native OpenSSL support => enabled
$ curl --version
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
Networking Results Maybe CDN issue? No clue, but I get no response…
$ ping !$
ping acme-staging.api.letsencrypt.org
PING e981.dscb.akamaiedge.net (23.196.212.53) 56(84) bytes of data.
$ ping 23.196.212.53
PING 23.196.212.53 (23.196.212.53) 56(84) bytes of data.
$ traceroute acme-staging.api.letsencrypt.org
traceroute to acme-staging.api.letsencrypt.org (23.196.212.53), 30 hops max, 60 byte packets
1 256.256.256.256 (256.256.256.256) 0.184 ms 0.172 ms 0.178 ms
2 * * *
3 lag-151.ear2.LosAngeles1.Level3.net (4.71.136.1) 0.484 ms * 0.711 ms
4 * * *
5 * * *
cURL seems to work just fine when contacting the host…
$ curl -v https://acme-v01.api.letsencrypt.org/directory
* About to connect() to acme-v01.api.letsencrypt.org port 443 (#0)
* Trying 23.196.212.53... connected
* Connected to acme-v01.api.letsencrypt.org (23.196.212.53) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: C=US,ST=California,L=Mountain View,O=INTERNET SECURITY RESEARCH GROUP,CN=*.api.letsencrypt.org
* start date: Jun 26 17:05:45 2015 GMT
* expire date: Jun 25 17:05:45 2018 GMT
* common name: *.api.letsencrypt.org
* issuer: CN=TrustID Server CA A52,OU=TrustID Server,O=IdenTrust,C=US
> GET /directory HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: acme-v01.api.letsencrypt.org
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx
< Content-Type: application/json
< Content-Length: 562
< Replay-Nonce: pmBWMasdfasdfasdfasdfafsdsadfk8
< X-Frame-Options: DENY
< Strict-Transport-Security: max-age=604800
< Expires: Mon, 18 Dec 2017 20:45:19 GMT
< Cache-Control: max-age=0, no-cache, no-store
< Pragma: no-cache
< Date: Mon, 18 Dec 2017 20:45:19 GMT
< Connection: keep-alive
<
{
"key-change": "https://acme-v01.api.letsencrypt.org/acme/key-change",
"ln0cfclsAeI": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417",
"meta": {
"terms-of-service": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf"
},
"new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz",
"new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert",
"new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg",
"revoke-cert": "https://acme-v01.api.letsencrypt.org/acme/revoke-cert"
* Connection #0 to host acme-v01.api.letsencrypt.org left intact
* Closing connection #0
When cURL hangs, it does so reight before the * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
line displayed in successful connections:
$ curl -v https://acme-v01.api.letsencrypt.org/directory
* About to connect() to acme-v01.api.letsencrypt.org port 443 (#0)
* Trying 23.196.212.53... connected
* Connected to acme-v01.api.letsencrypt.org (23.196.212.53) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 18 (2 by maintainers)
That’s a pretty clever observation. Sad to see it’s almost the end of 2017 and some shared hosts don’t support ipv6 yet.
You seem to be using acme.sh and not this client. This one isSorry.acme-client
, written with PHP.