Ssl – Error during openssl s_client connection, SSL alert number 48

opensslsslssl-certificate

I am attempting to connect to a third party via CURL/PHP mainly, but since it doesn't work, am resorting to more verbose tools to diagnose the problem.

If I try the following, on Ubuntu 14.04 LTS:

openssl s_client -showcerts -connect secure.thirdpartyhost.com:443 -cert production_client.pem -key production_key.pem -CApath /etc/ssl/certs

It fails with this error:

CONNECTED(00000003)
depth=2 C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms, OU = "(c) 2009 Entrust, Inc. - for authorized use only", CN = Entrust Root Certification Authority - G2
verify return:1
depth=1 C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms, OU = "(c) 2012 Entrust, Inc. - for authorized use only", CN = Entrust Certification Authority - L1K
verify return:1
depth=0 C = CA, ST = New York, L = New York, O = ThirdParty, CN = *.thirdpartyhost.com
verify return:1
139647498331808:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:s3_pkt.c:1262:SSL alert number 48
139647498331808:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:

Is that their server signaling the error? That the error with the CA is occurring during their verification?

Thanks for your help. A mere developer, I appreciate the help of those wiser!

Best Answer

tlsv1 alert unknown ca

The server cannot verify the client certificate you've sent because it does not find any path to the CA's trusted by the server.

Related Solutions

Openssl client authentication error: tlsv1 alert unknown ca: … SSL alert number 48

ok, I finally found out what the issue was and would like to share it just in case anyone gets stuck with that error message too.

Apache's config file has the following lines when it talks about the CA:

    #   Set the CA certificate verification path where to find CA
    #   certificates for client authentication or alternatively one
    #   huge file containing all of them (file must be PEM encoded)
    #   Note: Inside SSLCACertificatePath you need hash symlinks
    #         to point to the certificate files. Use the provided
    #         Makefile to update the hash symlinks after changes.

This means that every certificate file in this directory pointed to by SSLCACertificatePath must use a symbolic link. AND, most importantly, the name of each symbolic link must be the subject hash value of each certificate. You can find the hash value of the CA certificate by running this command:

    openssl x509 -subject_hash -in *cacert.pem*

So, if the hash value was 0434423b, in the directory pointed to by SSLCACertificatePath, you should create two symbolic links to point to the certificate in the directory:

0434423b -> /etc/apache2/certs/mypos.pem
0434423b.0 -> /etc/apache2/certs/mypos.pem

This should solve the issue. Of course, if I had used the SSLCACertificateFile, I don't think I'd experienced so much problems.

I found the explanation of SSLCACertificatePath here:

openssl's verify command page

look under -CApath directory

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

Openssl client authentication error: tlsv1 alert unknown ca: … SSL alert number 48

SSL Error: self signed certificate in certificate chain

Related Topic