Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

OpenSSL: unable to verify the first certificate for Experian URL

I am trying to verify an SSL connection to Experian in Ubuntu 10.10 with OpenSSL client.

openssl s_client -CApath /etc/ssl/certs/ -connect dm1.experian.com:443 

The problem is that the connection closes with a Verify return code: 21 (unable to verify the first certificate).

I've checked the certificate list, and the Certificate used to sign Experian (VeriSign Class 3 Secure Server CA - G3) is included in the list.

/etc/ssl/certs/ca-certificates.crt  

Yet I don't know why it is not able to verify the first certificate. Thanks in advance.

The entire response could be seen here: https://gist.github.com/1248790

like image 235
pdjota Avatar asked Sep 28 '11 18:09

pdjota


People also ask

What does Unable to verify the first certificate mean?

unable to verify the first certificate. The certificate chain is incomplete. It means that the webserver you are connecting to is misconfigured and did not include the intermediate certificate in the certificate chain it sent to you.

What is Openssl verification error?

Summary. The Ruby OpenSSL error certificate verify failed means your code can't verify that the SSL certificate of the website or API you're connecting to is the real one. It's important to solve this issue correctly to keep your communication secure.

What is SSL certificate for website?

An SSL certificate is a bit of code on your web server that provides security for online communications. When a web browser contacts your secured website, the SSL certificate enables an encrypted connection. It's kind of like sealing a letter in an envelope before sending it through the mail.


1 Answers

The first error message is telling you more about the problem:

verify error:num=20:unable to get local issuer certificate

The issuing certificate authority of the end entity server certificate is

VeriSign Class 3 Secure Server CA - G3

Look closely in your CA file - you will not find this certificate since it is an intermediary CA - what you found was a similar-named G3 Public Primary CA of VeriSign.

But why does the other connection succeed, but this one doesn't? The problem is a misconfiguration of the servers (see for yourself using the -debug option). The "good" server sends the entire certificate chain during the handshake, therefore providing you with the necessary intermediate certificates.

But the server that is failing sends you only the end entity certificate, and OpenSSL is not capable of downloading the missing intermediate certificate "on the fly" (which would be possible by interpreting the Authority Information Access extension). Therefore your attempt fails using s_client but it would succeed nevertheless if you browse to the same URL using e.g. FireFox (which does support the "certificate discovery" feature).

Your options to solve the problem are either fixing this on the server side by making the server send the entire chain, too, or by passing the missing intermediate certificate to OpenSSL as a client-side parameter.

like image 170
emboss Avatar answered Sep 28 '22 04:09

emboss