ssl handshake failure unable to get local issuer certificate

Question

I have an issue with new integration that I am working on it. I should consume a web service provided by external company and this service is over https, so in order to integrate with them, they have shared Three certificates:

1. Root.cer
2. Sahred.cer and the issuer is Root.cer
3. user.cer and the issuer is Shared.cer

I have installed all of them and I run below commands with no lock.

openssl connect command to the web service with showcerts option

openssl s_client -showcerts -connect https://example.com:8443

output:

CONNECTED(00000003)
depth=1 C = UK, O = EXA, OU = EXA eTrust Center, CN = EXA Shared CA
verify error:num=20:unable to get local issuer certificate
140539532310416:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1493:SSL alert number 40
140539532310416:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
---
Certificate chain
 0 s:/C=SA/O=EXA/OU=EXA eTrust Center/CN=example.com
   i:/C=SA/O=EXA/OU=EXA eTrust Center/CN=EXA Shared CA
-----BEGIN CERTIFICATE-----
-----------
-----END CERTIFICATE-----
 1 s:/C=SA/O=EXA/OU=EXA eTrust Center/CN=EXA Shared CA
   i:/C=SA/O=EXA/OU=EXA eTrust Center/CN=EXA Root CA
-----BEGIN CERTIFICATE-----
------
-----END CERTIFICATE-----
---
Server certificate
subject=/C=SA/O=EXA/OU=EXA eTrust Center/CN=example.com
issuer=/C=SA/O=EXA/OU=EXA eTrust Center/CN=EXA Shared CA
---
No client certificate CA names sent

curl command with handshake debugging:

curl -X POST https://example.com:8443 -iv

output:

 * TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
 * TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
 * TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [87 bytes data]
 * TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [3593 bytes data]
 * TLSv1.2 (OUT), TLS alert, Server hello (2):
} [2 bytes data]
 * SSL certificate problem: unable to get local issuer certificate
 * stopped the pause stream!

curl command with handshake debugging and skip verification:

curl -X POST https://example.com:8443 -iv -k

output:

 * TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
 * TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
 * TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [87 bytes data]
 * TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [3593 bytes data]
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
 * TLSv1.2 (IN), TLS handshake, Request CERT (13):
{ [36 bytes data]
 * TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
 * TLSv1.2 (OUT), TLS handshake, Certificate (11):
} [7 bytes data]
 * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
 * TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
 * TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
 * TLSv1.2 (IN), TLS alert, Server hello (2):
{ [2 bytes data]
 * error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

My Questions:

• What are the benefits from creating three certificates with issuer like that ?
• why the ssl handshake has failed ? Did I miss any thing in my commands ?
• Do you any idea how can I deal with these certificates or at lease how this communication works ?
• I really don't get it how this communication works. How can I submit these certificates without any private key. Based on my understanding when we want to create ssl based authentication I should create a public key and private key and I should share this public key with the external company, so they can decrypt the message when I encrypted by my private key. is this right ?

also I have posted a question with java in stackoverflow with no lock, you can take a look for more info https://stackoverflow.com/questions/53420158/ssl-handshake-failure-client-certifcate-not-being-sent

Answer 1

Some basic reading on TLS / SSL

"SSL" is the old name, I'll call it "TLS" in this post.

You should do some reading to get a basic understanding of how TLS works. Googling "How does the TLS handshake work?" should get you some good articles. We also have an overall primer post (thought it may be longer and more detailed than you want): How does SSL/TLS work?

Here is a curl-specific article about how TLS works: https://curl.haxx.se/docs/sslcerts.html

---

Why a CA chain?

It's normal for HTTPS certificates to have that structure with a root CA, and issuing CA, and the website cert, for example take a look at the cert for this page:

To answer your 4th question: The point of these certs is so that the server can prove to you that it is who it says it is, therefore the website keeps the private key, and you (the client) can use its public key (aka "certificate") to verify that is the authentic server. Nowhere in there is the client proving its identity to the server (that's usually accomplished by including an API key in the request).

---

Fixing your error

Remember that TLS is about establishing trust; validation of a server's certificate involves these steps:

• Is the End-User cert valid? Who issued it and do I trust them?
• Is the Intermediate CA cert valid? Who issued it and do I trust them?
• Is the Root CA cert valid? Do I trust it?

So when validating, you "chain" up to the root, and then check your "trust store" (a file on your computer of root CA certs that are "trusted") to see if that root cert is in there. OSes, browsers, etc will all ship with a list of root CA certs that it trusts. in the case of curl, that's a file on disk called curl-ca-bundle.crt.

My guess is that the root CA you're dealing with is not in curl's default list, so you need to add it manually. In the curl article I linked to above, they explain how to do this in Step 4.

Good luck, and welcome to the world of TLS and certificates!