I'm trying to add TLS to a node application connecting to RethinkDB database. I've setup the RethinkDB to use --driver-tls* parameter.
The strange thing to me is that on the client side I need to provide the CA certificate use to sign the certificates used by the server.
Is that root CA certificate can be self-signed or does it have to be signed with a trusted root CA itself?
Related
I have a certificate chain comprised of the root certificate, intermediate certificate, and server certificate. The root certificate is installed on my local machine. The intermediate certificate and server certificate are installed on my tomcat server.
I am unable to find instructions anywhere on how to create an intermediate certificate such that it is standards compliant. This is the error that I am receiving:
Here are the details of the "inter" certificate, according to KeyStore Explorer:
I am using OpenSSL program to generate my SSL self-signed certificate, created a CA certificate and a webserver certificate. The webserver certificate, I have signed it with the CA certificate. I created a keystore with Java's keytool to import webserver's certificate.
On the client side, I have imported the CA certificate inside client's Certificate Manager, under the "Trusted Root Certification Authorities".
In theory, is this way considered as a One way TLS or a Two way TLS communication?
Thank you so much for the help!
In TLS protocol by default the client validates servers authenticity, the server sends its certificate during the handshake and the client validates it with the CA certificate in its trust store. It is one way setup
For two way, during the handshake, the server also asks for certificate from client,it validates the certificate sent by the client with the CA certificate in its trust store. So if you want to use two way setup, you need to generate client CA certificate and client certificate(it will be signed by the client CA certificate), the same CA certificate you need to configure at server so that it(server) will be able to validate the client certificate it received during the handshake.
You can also decide to keep same CA certificate for both client and server certificates, making sure client and server certificates are signed by the same CA
When a TLS handshake takes place, the server sends in his ServerHello message, his digital certificate. This digital certificate is digitally signed by a intermediate CA named A and CA A also has a certificate which is signed by CA named root whose certificate is self signed, thus forming a certificate chain. The client then has to establish a trust, validating the server certificate. To perform that validation the client has to validate the entire chain correct?
Must the client have in a truststore all the certificates (A and Root) or the client will download them?
The client usually has only the root CA in the local trust store. The leaf certificate and the intermediate certificate leading to the root CA need to be provided by the server. The intermediate certificates are usually send in addition to the leaf certificate within the TLS handshake.
But it is a typical misconfiguration to only have the leaf certificate send by the server. In this case the certificate validation will fail unless the client has already knowledge of the intermediate certificates or can obtain these somehow. Since often the same intermediate certificates are used, some browsers like Firefox will cache the intermediate certificates they'll got when communicating with server A and fill these in when a broken server B is not sending the required intermediate certificates. Other browsers (like Google Chrome) will try to download the missing intermediate certificates from the internet. Most simpler clients (i.e. apps written in Python, Java ... or curl) will instead just fail with a certificate validation error.
I've to enable both server and client certificates. My plan is to use Let's encrypt for server and OpenSSL for the client certificate. The reason is that Let's encrypt only provide server certificates. I know that some commercial providers like DigiCert or GlobalSign provide both server and client certificates but that is not the option.
I haven't tried yet but I guess CA doesn't necessarily have to be the same for both certificates. Can anyone suggest a better idea?
If you use OpenSSL you will either have to establish a trusted internal CA or else use self-signed certificates, and ensure that whichever you use is trusted by the server(s). In the end it's cheaper to pay an external CA, then you don't have to overcome any trust issues.
I wouldn't say that Let's Encrypt only issues server certificates. There is no difference between a server certificate and a client certificate. However their authentication method requires a web server.
I'm creating a Certificate Authority with openssl, and signing my server & client certificate with it (they both are the same).
Installing CA as a Trusted Root CA and Intermediate CA, server certificate - as a Personal one.
Adding server certificate in IIS6, adding bindings - and getting the right https connection via browser on server side.
But on the client side -
Installing CA as a Trusted Root CA and Intermediate CA, client certificate as Personal, server certificate as External.
Checking all the certificates - they are in a working state, CA is connected to client, everything looks normal.
Trying to get via Chrome - I'm getting the connection, but it is unsecured (can't connect to https). (But I still can connect Chrome, and use all the requests in Google Rest Client.)
In IE I'm getting ERR_TUNNEL_CONNECTION_FAILED.
What am I doing wrong here?
SOLVED. Had the same serial_number for both client and server certificates
SOLVED. Had the same serial_number for both client and server certificates