Requirements for Successful SSL Communication - c++

I'm using thrift to write a C++ client which will call securely to the server (which is not written by me) written in java (code generated for both server and client using same thrift files). I'm a newbie in SSL communication. For the java server side, I imported the public key certificate of client to the server truststore (server-truststore.jks) to verify the client authenticity. I exported the public certificate from the server side keystore (server.jks) and used it in the client side to authenticate the server key certificate during the SSL handshake. If I list down what I did for the SSL communication:
Server Side (java):
exported the client's public key certificate to the server's truststore
Cleint Side (C++):
Loaded the server's public certificate which was exported from the server's keystore
separately loaded the client's public key and private key (This is because I can't directly use a java key store since the client is written in c++)
All the certificates used are self signed.
So far I have been unsuccessful and got the following error continuously:
SSL_connect: certificate verify failed
I have two questions:
Is the approach I used for SSL communication correct? If not, what is the correct one?
Any possible reasons for this error?
Thank you.

Check if you can verify the key invoking directly: openssl s_client -connect serverIP:Port .
If you can is problem of your code, and for that we will need more details about it.
If not... your are not using the cert. the server is sending you, or something is wrong with the certificate.

Related

Use SignalR-Client-Cpp with client certificate from windows cert store

I am trying to communicate via SignalR with a server which requires client authentication with a certificate. Hence, i receive the following error when trying to start the connection:
"connection could not be started due to: WinHttpSendRequest: 12044: A certificate is required to complete client authentication".
My program is in cpp, so i use the SignalR-Client-Cpp which is integrate to my project via vcpkg.
My implementation is similar to the example in readme.md, you can use it as a base for a sample code.
My client-certificate is stored in Windows certificate store. How can I establish the connection with this certificate?

Grpc c++ client to connect in secure mode using server side tls

I have grpc server in Java and client in C++, I want to connect grpc client to server in tls mode without using certificates on client side. I am using the default methods and trying to connect but getting grpc code as 12.
creds = grpc::SslCredentials(grpc::SslCredentialsOptions());
Note:- No issue with proto files as it works fine in insecure mode
Which cert is your server using? If it's self-signed or not signed by a standard CA (whose root cert should be present in the standard trust store) then you need to make sure you are using a custom root cert on the client

MITM proxy, TLS 1.2 Certificate verification failed

Trying to create my own simple MITM-proxy for the specific app which using TLS 1.2 protocol and connecting to several IP addresses, however got in stuck with the error in the app log "Certificate verify failed". How to solve this problem?
The app using about the following code to check the cert:
X509* cert = SSL_get_peer_certificate( ssl );
X509_STORE_CTX * xCtx = X509_STORE_CTX_new();
X509_STORE_CTX_init( xCtx, (X509_STORE*)Store, cert, NULL );
int res = X509_verify_cert( xCtx );
if( !res ) { /*Certificate verify failed*/ };
I did the following steps to achieve the result:
Created CA root key and self-signed certificate according to this manual. It is a bit outdated, so i have made some changes like md5 to sha256, also I didn't use pass phrase, used different key size and other minor changes.
Created proxy key and certificate using the above Root CA to sign it.
Both certificates have been added to the Local Computer Certificates in Personal and Trusted Root Certification Authorities (not sure if this was necessary). Btw, I'm using Windows 10.
Wrote a simple proxy server using sample code from here. Cert.pem and Key.pem took from the second step.
Changed all IP addresses in the app to 127.0.0.1:443 to see if TLS connection established successfully and we can receive first message with an Application Data.
I believe that connection established properly, because WireShark shows common sequence for establishing a TLS connection: Client/Server hello, Certificate, Client key exchange, two encrypted handshake messages. Moreover, using OpenSSL for testing connection:
openssl s_client -connect localhost:443
allow me to write some message and later successfully receive it using SSL_Read() in proxy server. However, there are some errors:
verify error:num=20:unable to get local issuer certificate
verify return:1
verify error:num=21:unable to verify the first certificate
verify return:1
Verify return code: 21 (unable to verify the first certificate)
Using OpenSSL client to directly connect to the original IP addresses give the same errors, but application works great.
Also the output:
openssl verify -CAfile "signing-ca-1.crt" "cert.crt"
WARNING: can't open config file: /usr/local/ssl/openssl.cnf
e:\MyProg\SSL_serv\Debug\cert.crt: OK
It seems that I missed something important. Could you please tell me how to solve this problem with cert?
One of the very purposes of having certificates, along with certificate authorities, is to prevent MITM. The app you are trying trick does the proper thing and checks the certificate. And it doesn't like your's. Its really that simple.
Is it possible to circumvent it and run MITM on an app anyway? Absolutely! Is it going to be easy? Probably not. What you need to do is to patch the app and remove this certificate check.

Make OpenSSL server only accept connections from clients that already have the server's public certificate

I'm still learning to program in C++ using OpenSSL, and trying to build and application where the client initiates the connections to the server. I have
Generated a certificate/key pair using OpenSSL (as .pem)
Called the SSL_use_certificate_file/PrivateKey_file in the server's initialization
Store the server's certificate with the clien and verify the certificate on client side when trying to connect to server
I noticed that even when I passed an incorrect certificate to the client and (correctly) failed 3., the connection still goes through, and the client and server continue doing whatever they were originally supposed to do.
What I would like to ask is,
Is there something wrong with how I'm using the certificate?
How can I make it such that the connection will fail if the client does not have the server's certificate?
You seem to have a design flaw.
The point of a server certificate is to protect the client. If you control the client, you should use the (detected) failure to abort the connection from the client side.
If you don't control the client, but need to trust it, you need to use client certificates. These are much less common, but definitely allowed in the SSL/TLS protocol underlying HTTPS. The effect of a client certificate is reversed: when the server detects a failure with a client certificate, the server can disconnect.

Asio certificate verify failed

I downloaded Asio Standalone and would like to run the ssl example (client and server) provided with the Asio source code on my local computer. I managed to get the library running. The code compiles without errors. But I think the client has a problem reading the server certificate from the certificate store on my debian system in /etc/ssl/certs. Because I get the following error:
Handshake failed: certificate verify failed
What I did so far:
I created the server certificate and key as descripted in my last post and added the crt file to /etc/ssl/certs
I set the verify_path on client side as following:
asio::ssl::context ctx(asio::ssl::context::tlsv11);
ctx.set_default_verify_paths();
I start the server on port 8877 on my local computer
I start the client with host IP 127.0.0.1 and port 8877
then I get the error as mentioned above.
Am I right that asio finds my certificate? (because otherwise I would expect an error 'file_not_found' or something like that) Why is the certificate not valid? Because I self-signed it or because I don't use 127.0.0.1 as a 'Common Name' in the certificate ? But I guess the client should accept a self-signed certificate in it's local certificate store...