0

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

Timothy Fisher
  • 115
  • 2
  • 7
  • The command `$ curl https://.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. – Binky Jun 03 '22 at 02:17
  • 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. – Binky Jun 03 '22 at 02:33
  • 1
    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. – dave_thompson_085 Jun 03 '22 at 02:46
  • @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. – Timothy Fisher Jun 03 '22 at 05:02
  • What version of CentOS are you using? Are installed packages up to date? – Gerald Schneider Jun 03 '22 at 05:04
  • 1
    @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` – Timothy Fisher Jun 03 '22 at 05:04
  • @GeraldSchneider CentOS Linux release 7.9.2009 (Core). I did make sure that the ca-certificates package was up to date. – Timothy Fisher Jun 03 '22 at 05:10
  • On a stock CentOS 7.9 I can connect to `https://dev.partsvu.com` with curl without problems. – Gerald Schneider Jun 03 '22 at 05:23
  • @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. – Timothy Fisher Jun 03 '22 at 05:25
  • Have you tried just running `yum reinstall ca-certificates`? – Gerald Schneider Jun 03 '22 at 05:27
  • 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 – Timothy Fisher Jun 03 '22 at 05:29
  • 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. – Gerald Schneider Jun 03 '22 at 05:31
  • @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". – Binky Jun 03 '22 at 17:57

0 Answers0