I am working on a project where both the server and client side send certificates for mutual authentication. For the revocation part server can always use ocsp stapling and the client can verify that, but I couldn't find any way to add an ocsp stapling response for the client. Is that even possible in the OpenSSL library?
Related
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
In a server application, once a connection has been established I can grab the client certificate from the SSL * I have. Is there a way to find out which CA I used to validate that certificate?
You can use the SSL_get0_verified_chain() function for this purpose. See the documentation here:
https://www.openssl.org/docs/man1.1.1/man3/SSL_get0_verified_chain.html
Note that this function was first introduced in OpenSSL 1.1.0, so this won't work in OpenSSL 1.0.2.
This post seems on point:
Find client certificate information from server in OpenSSL
Since SSL_get_peer_certificate returns an X509 cert, I would expect that the cert chain would be included (you couldn't handle a CRL properly without it, I'd think)?
I am using GNU libmicrohttpd to establish HTTPS server. My requirement is that the server and the client both authenticate during the TLS handshake however what I observe is that even if the client sends empty certificate the connection is accepted.
in wireshark I see that the server requests certificate and the client sends certificate with len 0. How to make the microhttpd to not accept that case - the certificate must always be verified with the provided CA pem?
if(!(server_handle = MHD_start_daemon(flags, port, NULL, NULL,
&mhttpd_layer::access_handler_callback, callback_data,
// now, continue with the options
MHD_OPTION_NOTIFY_COMPLETED, &mhttpd_layer::request_completed_callback, l_callback_data,
MHD_OPTION_SOCK_ADDR, (sockaddr*) &(it->addr),
MHD_OPTION_CONNECTION_TIMEOUT, it->conn_timeout,
MHD_OPTION_CONNECTION_LIMIT, it->conn_limit,
MHD_OPTION_PER_IP_CONNECTION_LIMIT, it->per_ip_conn_limit,
// HTTPS certificate options
MHD_OPTION_HTTPS_MEM_KEY, it->https_key_buff.data(),
MHD_OPTION_HTTPS_MEM_CERT, it->https_cert_buff.data(),
MHD_OPTION_HTTPS_MEM_TRUST, it->https_turst_ca_buff.data(),
MHD_OPTION_END)))
Maybe I should manually on the access callback retrieve the certificate as described by their tutorial (https://www.gnu.org/software/libmicrohttpd/tutorial.html#Adding-a-layer-of-security) ? In this case why do I provide the CA - this doesn't seem the proper way to me?
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.
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.