Resolving the crash when sslv3 crashes when trying to use a client certificate

I am trying to connect to a service that requires a certificate for authorization. The process is that I send the CSR file to the service. The service signs the CSR and sends me the certificate that I use to connect.

  • I created the CSR using the following command line:

    openssl req -new -nodes -newkey rsa:2048 -keyout cert.key -out cert.csr 
  • I took the contents of cert.csr and sent it to them. They generate a client certificate, and I received a PEM file.

  • Now I'm trying to connect using my certificate file in SSLCERT for curl () and providing the private key from cert.key as CURLOPT_SSLKEY - (which I got in step 1).

  • Failure: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

What am I doing wrong in this process?

It works when I try to get the received test certificate, including the private key from the service (self-signed certificate). But when I use the certificate that they generate from my CSR and then use my private key as the key, it causes errors when the acknowledgment fails.

So, I know that this has nothing to do with the fact that openssl / curl does not support v3 / TLS, etc., that others, when researching the solution, found their problem.

Here is what I run:

  curl -i -v --request POST https://service.com/ --cert clientcert.pem --key private_key.pem --cert-type pem --tlsv1.1 --insecure * Connected to service.com (1xx.xxx.xxx.xx) port 443 (#0) * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs * SSLv3, TLS handshake, Client hello (1): * SSLv3, TLS handshake, Server hello (2): * SSLv3, TLS handshake, CERT (11): * SSLv3, TLS handshake, Server key exchange (12): * SSLv3, TLS handshake, Request CERT (13): * SSLv3, TLS handshake, Server finished (14): * SSLv3, TLS handshake, CERT (11): * SSLv3, TLS handshake, Client key exchange (16): * SSLv3, TLS handshake, CERT verify (15): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSLv3, TLS alert, Server hello (2): * error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure * Closing connection 0 

Running the following versions: curl 7.35.0 (x86_64-pc-linux-gnu) libcurl / 7.35.0 OpenSSL / 1.0.1f zlib / 1.2.8 libidn / 1.28 librtmp / 2.3

+5
source share
2 answers

Not a definite answer, but too big to fit in the comments:

I assume that they gave you a certificate that either has the wrong issuer (although their server can use a more specific warning code for it), or the wrong object. We know that cert matches your private key, because both curl and openssl client paired them without complaining about the mismatch; but we don’t really know that it matches their desired CA (s) - since your curl uses openssl and the openssl SSL client DOES NOT use the configured client certificate to match certreq.CAs.

Make openssl x509 <clientcert.pem -noout -subject -issuer and the same thing on the certificate from the P12 test that works. Make openssl s_client (or check the one you made) and look under Acceptable client certificate CA names ; the name there or one of them must correspond (exactly!) to the issuer (s) of your certificates. If not, then most likely your problem, and you need to check with them, you sent your CSR to the right place and right. Perhaps they have different modes in different regions or business areas, or they are testing vs prod, or actively against pending ones, etc.

If the issuer of your certificate meets the desired CAS, compare its subject with the working one (test-P12): are they in the same format? are there any components in the workspace that aren’t in yours? If they allow this, try creating and sending a new CSR with the subject name exactly the same as the test P12, or as close to it as possible, and see if it creates a certificate that works better. (You do not need to generate a new key to do this, but if you decide, keep track of which certificates correspond to these keys so that you do not mix them.) If this does not help to look at the extension certificate with openssl x509 <cert -noout -text for any differences (s) that can reasonably be associated with authorization of an object, for example, KeyUsage, ExtendedKeyUsage, perhaps policies, possibly restrictions, maybe even something non-standard.

If all else fails, ask the server operator (s) what their logs say about the problem, or if you have access to the logs themselves.

+3
source

What SSL private key should be sent along with the client certificate?

None of them:)

One of the attractive features of client certificates is that it does not do anything stupid, for example, it transfers a secret (for example, a password) in text form to the server (HTTP basic_auth ). The password is still used to unlock the key for the client certificate, it simply is not used directly during the exchange or tp authenticate the client.

Instead, the client selects a temporary random key for this session. Then the client signs a temporary random key with his certificate and sends it to the server (some refuse by hand). If a bad guy intercepts something, its random, so it cannot be used in the future. It cannot even be used to run the protocol with the server a second time because the server will also select a new random value.


Failure: with error: 14094410: SSL routines: SSL3_READ_BYTES: sslv3 notification failure failed

Use TLS 1.0 and higher; and use Specify Server Name .

You did not specify any code, so it is not clear to him how to tell you what to do. Instead, check the OpenSSL command line here:

 openssl s_client -connect www.example.com:443 -tls1 -servername www.example.com \ -cert mycert.pem -key mykey.pem -CAfile <certificate-authority-for-service>.pem 

You can also use -CAfile to avoid "error checking: num = 20". See, for example, "check error: num = 20" when connecting to gateway.sandbox.push.apple.com .

+2
source

Source: https://habr.com/ru/post/1246293/


All Articles