Lets Encrypt fails with the error: "API request error"

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:
fiftest.safe-frankfurt.de

I ran this command:
bacme -v -e valid-email-address -w /srv/www/vhosts/fiftest/htdocs fiftest.safe-frankfurt.de

It produced this output:

#### Creating domain subdirectory ...
#### Done. fiftest.safe-frankfurt.de/ created.
#### Getting URL of current subscriber agreement ...
#### OK 
#### Generating account key ...
#### Private key: fiftest.safe-frankfurt.de/account.key
Generating RSA private key, 4096 bit long modulus
.............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................++
..................................................................................................++
e is 65537 (0x10001)
#### Public key: fiftest.safe-frankfurt.de/account.pub
writing RSA key
#### OK
jwk_thumbprint = wJaIaiRgjvZKUuqYOP3vyx4g5p1mYNIXnt4NPTewSFE
#### Registering account ...
Getting nonce ...
nonce = 
Request URL: https://acme-v02.api.letsencrypt.org/acme/new-acct
JWS Header: { "alg": "RS256", "jwk": { "e": "AQAB", "kty": "RSA", "n": "s2XO5IXFoM8IVRXkVkrqm0vcNqDbDaS1f1bnGTcTSwuJsoFA0T9JgjGNCDL2JY9jiKXxxiiKdAxOcj0YqaDSuSh-PYPnf1l2HA1NBO0-_OEXhcYwMDaQ087wVKiMyjGyZK4dgQaSM_XfWry0gFCaqPlrtyntlxVw3HtPi_VIEXNhNwOWMeiAgy_T8FgwCW0M0eYv5ArSXlvC3gLZ8l-SXMJdBGvGbU_KLSJFK91X2a-eKq_Fz5favUmDbmFcW_7UDP7xszkPTK7k_NdBYj76aCjannNLc2mkkk7IBj_QFXxnTDyycLU6b5f3pLU0M_id3_rN4dI1R5n_ZsAjiOyr6wTq-wE1ecu5Q-nrTRvuS-5Lpb3-UuYBSGI4UMxx2453cPn8fOce2VxwepBEX1Refy2pphzeNX9dLWdN4CTUluLDA5Q7RR4zo4B1K-Fo9uWZqJFEI0W02I17xdAsf5zX5tmEhk2s3GrGunyAavAcvvwx8yTYVNPhWFP2dsTNkxH171eyku95AZrq1ep97U-L7q8n3qIcLBKAU9orJvok3WUIDBEhYIGsny7DLTTlbVDkgm27kgusQHA8dOsWo_unNNsySy8KyPrvlZ6e0Kuhj6pb4tAdxDT4sFH91oSYHPdr7b3TceZAHMp0RXjLZ0B96Pz3jDIFq91pyUk-ZPegdG8" }, "nonce": "", "url": "https://acme-v02.api.letsencrypt.org/acme/new-acct" }
JWS Body: { "termsOfServiceAgreed": true, "contact": [ "mailto:valid-email-address" ] }
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html

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.
ERROR: API request error
ERROR: Request URL: https://acme-v02.api.letsencrypt.org/acme/new-acct
ERROR: HTTP status: 000
ERROR: 
EXIT 1

My web server is (include version):
Server version: Apache/2.4.23 (Linux/SUSE)
Server built: 2017-07-17 14:47:51.000000000 +0000

The operating system my web server runs on is (include version):
Welcome to SUSE Linux Enterprise Server 12 SP2 (x86_64) - Kernel \r (\l).

My hosting provider, if applicable, is:
n/a

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 (using command line)

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
bacme (latest version - [1.1.0] 2020-02-02)
NOTE: we have been using bacme for months without any problems. Three days ago we started getting the error listed above (API request error).

2

Hi @paulwwarner welcome to the LE community forum :slight_smile:

This is likely an O/S related issue.
Please show the version of OpenSSL.
And review this doc: Old Let’s Encrypt Root Certificate Expiration and OpenSSL 1.0.2 - OpenSSL Blog

3

Thanks very much for the information! Yes, you are correct, that is the version of OpenSSL on our oldish machine, sigh.

OpenSSL 1.0.2j-fips 26 Sep 2016

I will try one of the work-arounds in your posted article/link.

I just found another possible way this is affecting us. We are getting the browser error:

NET::ERR_CERT_DATE_INVALID

on another site, www.amad.org, that has a certificate I updated with lets-encrypt in September.

Once again, thanks.

1 Like
4

That site is not serving any chain at all:

openssl s_client -connect www.amad.org:443 -servername www.amad.org
CONNECTED(00000005)
depth=0 CN = www.amad.org
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = www.amad.org
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:CN = www.amad.org
   i:C = US, O = Let's Encrypt, CN = R3
---
5

Now the same is happening on another Lets Encrypt site of ours: opr.amad.org. It shows the same error in the browser, and the same error from the openssl check you used:

openssl s_client -connect opr.amad.org:443 -servername opr.amad.org

What does this mean?

6

@paulwwarner
It means that your web server has not been configured to serve the fullchain.

7

We have not changed our Apache config. We have run these sites with Lets Encrypt for many months without any problems. We run websites with other certificates and those websites are working.

1 Like
8

You wouldn't have had to change your Apache config for things to break. The breakage is related to some certificate expirations that happened late last week and have impacted servers that were previously misconfigured because clients can no longer validate the certificates.

2 Likes
9

..that you know of!

Not sending the correct (including sending none) chain cán work (due to browsers caching intermediates or downloading them), but that's no guarantee at all.

1 Like
10

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