How do I manually authenticate a CA signed SSL certificate

Question

A service I am using is refreshing their SSL certificate and now my connections to their service fail. They were working before the change (as in, 1 hour before the change).

Their old and new server certificates were supposed to be signed by Verisign. How can I manually verify the certificate?

Does running it through the openssl x509 tool do it automatically?

Using openssl s_client to connect to their server, I can see the certificate they are sending during SSL handshake. Running it through the x509 tool with the -text option, I get the following issuer line:

Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign Class 3 International Server CA - G3

and the Subject: CN= value matches the hostname I am connecting to.

The complaints I am getting while connecting with s_client are (I've omitted the subject lines so as to not name the service):

verify error:num=20:unable to get local issuer certificate
verify return:1
verify error:num=27:certificate not trusted
verify return:1
verify error:num=21:unable to verify the first certificate
verify return:1

Can anyone advise me on how to find out why my tools do not trust this certificate?

Solution 1

I tend to like a quick pass with curl -Iv https://www.example.com. curl will dump out the relevant SSL bits (and will use the list of CAs it has on hand).

If you need to do more by hand, you can run openssl verify with the right options, specifically the -CApath option:

$ openssl verify --help
usage: verify [-verbose] [-CApath path] [-CAfile file] [-purpose purpose] [-crl_check] [-engine e] cert1 cert2 ...

My guess at your problem is that the server isn't publishing the intermediate certificate bundle. Look at https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR657 (or, more specifically, the email instructions from Verisign on how to install the certificate).

Solution 2

This is because you're not using either -CApath or -CAfile on your command-line. These parameters tell openssl where to look for the trusted CA files in either a directory or a specific file.

With it:

openssl s_client -CAfile /etc/ssl/ca-bundle.pem -connect www.bofa.com:443
CONNECTED(00000003)
depth=3 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary Certification Authority
verify return:1
depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5
verify return:1
depth=1 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = Terms of use at https://www.verisign.com/rpa (c)06, CN = VeriSign Class 3 Extended Validation SSL CA
verify return:1
depth=0 1.3.6.1.4.1.311.60.2.1.3 = US, 1.3.6.1.4.1.311.60.2.1.2 = Delaware, businessCategory = Private Organization, serialNumber = 2927442, C = US, postalCode = 60603, ST = Illinois, L = Chicago, street = 135 S La Salle St, O = Bank of America Corporation, OU = Network Infrastructure, CN = www.bankofamerica.com
verify return:1

Without it:

openssl s_client -connect www.bofa.com:443CONNECTED(00000003)
depth=3 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary Certification Authority
verify error:num=19:self signed certificate in certificate chain
verify return:0

Makes a key difference.

Comments

[Paddy O'Loughlin]

I have been using -CApath (set to /etc/ssl/certs/).

[Paddy O'Loughlin]

I originally used curl -v too. It has been a very handy tool. I never thought out using -I. openssl verify sounds very like what I'm looking for. I'll not be able to try it out until Wednesday, but I'll let you know how it goes. Thanks! :)

[Paddy O'Loughlin]

This seems to have done the trick. After much trial-and-error, I've got the verification to work by downloading the Secure Site Pro Intermediate CA Bundle from the link you provided then specifying it as the CAfile argument AND my server's root certificates directory as the CApath argument. This indicates that the problem is with the intermediate certificate bundle. Can you tell me what the standard practice is for this kind of situation? Should the intermediate certificate be installed on my client machine or on the service provider's server? Or what did you mean by "publishing"?

[cjc]

@PaddyO'Loughlin it needs to be installed on the web server, so that it can serve the intermediate bundle as it serves the site certificate. How to do that depends on the web server's software (Apache will have a directive to specify the bundle, nginx will have you concatenate the bundle to the site certificate, etc.)