ERROR: Problem connecting to server (get for https://acme-v02.api.letsencrypt.org/directory; curl returned with 60)

mike.walls · April 7, 2021, 5:23pm

My domain is:

I ran this command: /shared/scripts/dehydrated --register --accept-terms

It produced this output:

INFO: Using main config file /etc/dehydrated/config

ERROR: Problem connecting to server (get for https://acme-v02.api.letsencrypt.org/directory; curl returned with 60)

My web server is (include version):

The operating system my web server runs on is (include version): BIG-IP 14.1.4 Build 0.0.11

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

JuergenAuer · April 7, 2021, 5:32pm

Hi @mike.walls

looks like the installed curl is too old.

What says

curl -V
curl -v https://acme-v02.api.letsencrypt.org/directory

Version and verbose

mike.walls · April 7, 2021, 5:44pm

curl -V

curl 7.47.1 (x86_64-redhat-linux-gnu) libcurl/7.47.1 OpenSSL/1.0.2s zlib/1.2.7 libidn/1.28 libssh2/1.4.3 nghttp2/1.31.1
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz HTTP2 UnixSockets

curl -v https://acme-v02.api.letsencrypt.org/directory

Trying 2606:4700:60:0:f53d:5624:85c7:3a2c...
Connected to acme-v02.api.letsencrypt.org (2606:4700:60:0:f53d:5624:85c7:3a2c) port 443 (#0)
ALPN, offering h2
ALPN, offering http/1.1
Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
successfully set certificate verify locations:
CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
TLSv1.2 (OUT), TLS header, Certificate Status (22):
TLSv1.2 (OUT), TLS handshake, Client hello (1):
TLSv1.2 (IN), TLS handshake, Server hello (2):
TLSv1.2 (IN), TLS handshake, Certificate (11):
TLSv1.2 (OUT), TLS alert, Server hello (2):
SSL certificate problem: unable to get local issuer certificate
Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: curl - SSL CA Certificates

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.

With the "-k" option:

curl -vk https://acme-v02.api.letsencrypt.org/directory

Trying 2606:4700:60:0:f53d:5624:85c7:3a2c...
Connected to acme-v02.api.letsencrypt.org (2606:4700:60:0:f53d:5624:85c7:3a2c) port 443 (#0)
ALPN, offering h2
ALPN, offering http/1.1
Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
successfully set certificate verify locations:
CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
TLSv1.2 (OUT), TLS header, Certificate Status (22):
TLSv1.2 (OUT), TLS handshake, Client hello (1):
TLSv1.2 (IN), TLS handshake, Server hello (2):
TLSv1.2 (IN), TLS handshake, Certificate (11):
TLSv1.2 (IN), TLS handshake, Server key exchange (12):
TLSv1.2 (IN), TLS handshake, Server finished (14):
TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
TLSv1.2 (OUT), TLS change cipher, Client hello (1):
TLSv1.2 (OUT), TLS handshake, Finished (20):
TLSv1.2 (IN), TLS change cipher, Client hello (1):
TLSv1.2 (IN), TLS handshake, Finished (20):
SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
ALPN, server accepted to use h2
Server certificate:

   subject: CN=acme-v01.api.letsencrypt.org

   start date: Apr  6 22:20:42 2021 GMT

   expire date: Jul  5 22:20:42 2021 GMT

   issuer: C=US; O=Let's Encrypt; CN=R3

   SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.

Using HTTP2, server supports multi-use
Connection state changed (HTTP/2 confirmed)
TCP_NODELAY set
Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
Using Stream ID: 1 (easy handle 0x12a7190)

GET /directory HTTP/1.1
Host: acme-v02.api.letsencrypt.org
User-Agent: curl/7.47.1
Accept: /

Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2.0 200
< server:nginx
< date:Wed, 07 Apr 2021 17:43:31 GMT
< content-type:application/json
< content-length:658
< cache-control:public, max-age=0, no-cache
< x-frame-options:DENY
< strict-transport-security:max-age=604800
<
{
"dxSLpZC9X6c": "Adding random entries to the directory",
"keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change",
"meta": {
"caaIdentities": [
"letsencrypt.org"
],
"termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf",
"website": "https://letsencrypt.org"
},
"newAccount": "https://acme-v02.api.letsencrypt.org/acme/new-acct",
"newNonce": "https://acme-v02.api.letsencrypt.org/acme/new-nonce",
"newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order",
"revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert"
Connection #0 to host acme-v02.api.letsencrypt.org left intact

JuergenAuer · April 7, 2021, 5:54pm

That's very old:

https://curl.se/docs/vuln-7.47.1.html

curl version 7.47.1 was released on February 8 2016

So your curl doesn't know the ISRG root - Chain of Trust - Let's Encrypt

Check, if you can add that certificate local. Or if you can install a newer version.

Osiris · April 7, 2021, 5:55pm

acme-v02.api.letsencrypt.org chains up to DST Root CA X3 and not the ISRG root?

petercooperjr · April 7, 2021, 5:59pm

In addition, it looks like it's just using some system cert store /etc/pki/tls/certs/ca-bundle.crt which I would assume has the DST Root in it. But it does seem that maybe it doesn't?

Osiris · April 7, 2021, 6:01pm

Most likely the certificate store mentioned in your post @petercooperjr requires updating.

However, I've never heard of the operating system called "BIG-IP". So no idea how.

mike.walls · April 7, 2021, 6:12pm

F5 BIG-IP Local Traffic Manager (LTM) is a load balancer.

JuergenAuer · April 7, 2021, 6:14pm

Yes, my FireFox shows the ISRG root.

Osiris · April 7, 2021, 6:16pm

You can't trust browsers showing you the chain provided of the webserver. acme-v02.api.letsencrypt.org serves the cross-signed R3 certificate as intermediate, so any root certificate store containing DST Root CA X3 will do just fine. The fact a browser can cache the R3 signed by ISRG Root X1 is a whole different story.

petercooperjr · April 7, 2021, 6:21pm

openssl s_client -connect acme-v02.api.letsencrypt.org:443 shows the server is sending the intermediate-signed-by-DST-Root.

Certificate chain
 0 s:CN = acme-v01.api.letsencrypt.org
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3

I think it might be worthwhile to see if the curl also complains when trying other CAs.

curl -v https://www.identrustssl.com/
curl -v https://valid-isrgrootx1.letsencrypt.org/
curl -v https://comodorsacertificationauthority-ev.comodoca.com/

[Side note, I was trying to find the official test site for the DST Root X3 cert, which I think is the www.identrustssl.com URL based on CCADB and IdenTrust, but when testing with OpenSSL it doesn't look like it actually chains up to that? So I may be misunderstanding something about how these test sites are supposed to work.]

But regardless, the question is whether /etc/pki/tls/certs/ca-bundle.crt on your system has something reasonable in it. Can you see the date and size of that file? I don't know if there's an easy command to check if a specific cert is in it, but an ls of it might tell us… something.

ls -l /etc/pki/tls/certs/ca-bundle.crt

schoen · April 7, 2021, 7:46pm

@petercooperjr maybe something like

cat /etc/pki/tls/certs/ca-bundle.crt | while true; do while read a; do echo $a; if echo $a | fgrep -q "END CERTIFICATE"; then break; fi; done | openssl x509 -text -noout || break; done | grep Subject:

petercooperjr · April 7, 2021, 7:53pm

Yeah, something like that looks like it'd work. I could probably figure it out, but I couldn't rattle it off from the top of my head.

mike.walls · April 7, 2021, 8:36pm

So I updated the ca-bundle.crt and resolved the "curl: (60) SSL certificate problem: unable to get local issuer certificate" issue. Now I'm left with:

INFO: Using main config file /etc/dehydrated/config

Generating account key...
Registering account key with ACME server...
- ERROR: An error occurred while sending post-request to https://acme-v02.api.letsencrypt.org/acme/new-acct (Status 400)

Details:
HTTP/2.0 400
server:nginx
date:Wed, 07 Apr 2021 20:32:13 GMT
content-type:application/problem+json
content-length:112
cache-control:public, max-age=0, no-cache
link:https://acme-v02.api.letsencrypt.org/directory;rel="index"
replay-nonce:0003uwh8_YnKxCJhZwIWDCS37VRkvK69WhncoAQjeg1iGUU

{
"type": "urn:ietf:params:acme:error:badNonce",
"detail": "JWS has no anti-replay nonce",
"status": 400
}

Error registering account key. See message above for more information.

JuergenAuer · April 7, 2021, 8:57pm

That shouldn't happen. Same question: How old is your dehydrated?

mike.walls · April 7, 2021, 9:42pm

Dehydrated version: 0.6.5

mike.walls · April 7, 2021, 9:43pm

I made the following update to dehydrated, CURL_OPTS="--http1.1", which seems to have resolved the issue.

system · May 7, 2021, 9:44pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.