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

[mike.walls]

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]

Hi @mike.walls

@mike.walls

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

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]

@JuergenAuer

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

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]

@mike.walls

curl 7.47.1

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]

@JuergenAuer

So your curl doesn't know the ISRG root

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

[petercooperjr]

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]

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]

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

[JuergenAuer]

@Osiris

and not the ISRG root?

Yes, my FireFox shows the ISRG root.

[Osiris]

@JuergenAuer

Yes, my FireFox shows the ISRG root.

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]

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]

@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]

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]

@mike.walls

Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH

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]

@mike.walls

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

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

[mike.walls]

Dehydrated version: 0.6.5

[mike.walls]

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