Ssl – How to manually authenticate a CA signed SSL certificate

authenticationcertificate-authoritysslssl-certificate

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?

Best Answer

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).

Related Solutions

SSL Error – Unable to Read Server Certificate from File

Is it possible that the lines are ^M-terminated? This is a potential issue when moving files from Windows to UNIX systems. One easy way to check is to use vi in "show me the binary" mode, with vi -b /etc/apache2/domain.ssl/domain.ssl.crt/domain.com.crt.

If each line ends with a control-M, like this

you've got a file in Windows line-terminated format, and apache doesn't love those.

Your options include moving the file over again, taking more care; or using the dos2unix command to strip those out; you can also remove them inside vi, if you're careful.

Edit: thanks to @dave_thompson_085, who points out that this answer no longer applies in 2019. That is, Apache/OpenSSL are now tolerant of ^M-terminated lines, so they don't cause problems. That said, other formatting errors, several different examples of which appear in the comments, can still cause problems; check carefully for these if the certificate has been moved across systems.

SSL Error: self signed certificate in certificate chain

You don't need the root certificate in the chain (though I don't believe having it hurts anything).

That error is more of a warning from openssl in this case I think. I believe what it means is just that openssl doesn't know that it should trust the root certificate of that chain. If you pull out just the root certificate from that bundle and point that openssl command at it with the -CAfile argument I expect that "error" should go away.

Inside the sf_bundle.crt file you should see two

-----BEGIN CERTIFICATE-----
....
-----END CERTIFICATE-----

blocks (possibly with plain text above each block showing what certificate the block contains). If you split each of those blocks into its own file so you end up with block1.crt and block2.crt you should be able to run openssl x509 -noout -subject -in <file.crt> on each of them to get their respective certificate subject lines.

Assuming that block2.crt has a subject line of /C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority you should then be able to run openssl s_client -CAfile block2.crt -connect imap.domain.ltd:465 and that should, hopefully, connect without giving you the self-signed certificate error.

Best Answer

Related Solutions

SSL Error – Unable to Read Server Certificate from File

SSL Error: self signed certificate in certificate chain

Related Topic