Join Log in
Score:0
Timothy Fisher avatar Server

Curl "peer's certificate issuer is not recognized" error when attempting to communicate between two servers

ca flag
Timothy Fisher

I have two servers A and B that host websites that work fine in a browser with https. The lock icon in the browsers show active and trusted SSL certificates.

I'm trying to run curl so that server A can talk to server B, but am running into an error.

- Server A -
$ curl https://dev.partsvu.com
CAfile: /etc/pki/tls/certs/ca-bundle.crt
curl: (60) Peer's Certificate issuer is not recognized.

I've done some research around the Stack Overflow sites and have run into many questions, however, their solutions haven't worked for me.

I first tried downloading the certificates files for server B from an SSL Labs report and manually added the list of certificates to the /etc/pki/tls/certs/ca-bundle.crt file on server A but I'm still getting the same error.

I've also ensured that the server B certificate is valid with the following:

- Server B -
openssl x509 -dates -noout < /etc/pki/tls/certs/cloudflare.pem
notBefore=May  6 21:25:00 2022 GMT
notAfter=May  2 21:25:00 2037 GMT

I've also tried copying the contents of /etc/pki/tls/certs/cloudflare.pem on server B directly to the /etc/pki/tls/certs/ca-bundle.crt on server A but same error.

Lastly, I tried visiting server B in Chrome and downloaded the crt file it shows at https://cacerts.digicert.com/CloudflareIncECCCA-3.crt, converted it to pem with:

openssl x509 -inform DES -in CloudflareIncECCCA-3.crt -out outcert.pem

and added that to the same ca-bundle.crt file on server A.

Same error when trying to run curl.

Here is the cert chain from Chrome:

enter image description here

26
0 + 0
ssl
Binky avatar
de flag
Binky
The command `$ curl https://<server B address>.com` is problematic. Is "server B address" an IP address, or the DNS label(s) under ".com"? Please post the actual command and error. If that's an IP addresses, the command fails because the server needs info about which cert to send, based on the portion of the URL that is present after the scheme ("https://") and before the beginning of the path ("/"). Cert identities are normally DNS names, not IP addresses. Please post the cert of server B in PEM form, with a screenshot of the cert chain displayed by a browser when browsing server B.
0
Reply
Binky avatar
de flag
Binky
Also, when you say "I've also ensured that the server B certificate is valid.." the validity dates show that this is not the server certificate, unless you issued the cert from a private PKI rather than using a public certificate authority. Server certificates from a public CA cannot be valid for more than just over a year. So you either have 1) the wrong cert in that file, or 2) multiple certificates, and the notBefore/After dates likely belong to a root certificate.
0
Reply
dave_thompson_085 avatar
jp flag
dave_thompson_085
Do `curl -V` (uppercase) to find out which middleware your curl is using; you'll probably find it is NSS (NOT OpenSSL) which means it IS NOT using /etc/pki/tls/certs/ca-bundle.crt (_or_ ca-bundle.trust.crt). That's why RH/CentOS/etc has `update-ca-trust` to _correctly_ update the multiple truststores rather than have ignorant users try to do it by hand. Also note browser working is not proof your server is okay because browser can usually work around missing chain certs while `curl` usually cannot, but if you had that problem SSLLabs would have said so.
1
Reply
Timothy Fisher avatar
ca flag
Timothy Fisher
@Binky I've updated with the command with the actual domain name and also the cert chain screenshot. And yes you're right that certificate for the expiration dates is a root certificate, not the one that shows in the browser. We're using Cloudflare. There's an edge certificate in Cloudflare, and then another that is used by HAProxy to bind on port 443.
0
Reply
in flag
Gerald Schneider
What version of CentOS are you using? Are installed packages up to date?
0
Reply
Timothy Fisher avatar
ca flag
Timothy Fisher
@dave_thompson_085 I think you're right on NSS. when I run it with `-V` I get `curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.53.1 zlib/1.2.7 libidn/1.28 libssh2/1.8.0`, and running `-v` shows `* Initializing NSS with certpath: sql:/etc/pki/nssdb`
1
Reply
Timothy Fisher avatar
ca flag
Timothy Fisher
@GeraldSchneider CentOS Linux release 7.9.2009 (Core). I did make sure that the ca-certificates package was up to date.
0
Reply
in flag
Gerald Schneider
On a stock CentOS 7.9 I can connect to `https://dev.partsvu.com` with curl without problems.
0
Reply
Timothy Fisher avatar
ca flag
Timothy Fisher
@GeraldSchneider I was able to as well when I use curl on my local machine. But, when I try from a specific server, I'm getting the not recognized error. Wondering where I can begin troubleshooting this.
0
Reply
in flag
Gerald Schneider
Have you tried just running `yum reinstall ca-certificates`?
0
Reply
Timothy Fisher avatar
ca flag
Timothy Fisher
Yes I ran that as well as followed this to try to bring things back to a default state: https://access.redhat.com/solutions/1549003
0
Reply
in flag
Gerald Schneider
Well, this is pretty fruitless. Without having any way of knowing what you actually did and what state your system is there is not really a way to help you. If my server were in this state I'd just reinstall it.
0
Reply
Binky avatar
de flag
Binky
@TimothyFisher Can you post the output of the commands: 1) sudo ls -l /etc/pki/nssdb and 2) sudo certutil -L -d sql:/etc/pki/nssdb ? The latter may have a lot of output; if so, pipe the output to grep and search for "Baltimore CyberTrust Root".
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.