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
Related
According to TLS connection definition, for example, as the client-side, I use keystore to store my private key and certificate, and use truststore to store some kinds of certs. On the server-side, that call it Youtube, it has a root certificate called Youtube.pem which is signed by Google.crt CA.
I know the truststore is to verify the 3rd party certificate during handshake
My question is what should my truststore actually store during handshake?
Youtube.pem (the CA signed certificate sent from 3rd part)
Google.crt (the CA certificate)
According to TLS connection definition, for example, as the client-side, I use keystore to store my private key and certificate, and use truststore to store some kinds of certs.
Yes, but you only need a keystore if you want to use client side authentication. Note that "keystore" and "truststore" indicate how the store is used, they can be of the same type (e.g. PKCS#12) and even the same file.
On the server-side, that call it Youtube, it has a root certificate called Youtube.pem which is signed by Google.crt CA.
No, YouTube is a service, it has a leaf or end-entity certificate. The root certificate is that of a third party CA. The end-entity certificate is usually signed by an intermediate CA certificate, and that is in turn signed by a self signed root certificate.
I know the truststore is to verify the 3rd party certificate during handshake
It is used to validate and verify the trust path from leaf certificate to a trust anchor in your truststore. The trust anchor is usually one of the root certificates stored in your truststore. The leaf certificate is indicated by the end entity / server, the intermediate certificates are usually sent by the server as well, but they could also be retrieved from a cache.
In the case of YouTube, the Google root CA is used, possibly using the GlobalSign root through a linked certificate if the Google root is not present in the trust store.
So your truststore should either contain the Google root certificate or the GlobalSign root for the connection to work in this example.
Recently I was debugging a mutual TLS issue between a MQTT client and a broker.
For the TLS setup, a self-signed CA was used to sign both server certificates and client certificates.
Both server and client trust stores had the CA certificate present.
During the handshake I observed, both brokers (RabbitMQ and Mosquitto) sent the CA certificate along with the server certificate.
But on clients, except for JAVA(PAHO), the Python and the nodejs clients both were also sending the CA certificate they had with their response to the server.
If the CA certificates were already installed in the trust stores of both the server and client, why should they exchange the CA at all during the handshake?
PS: Also JAVA client was never sending the CA certificate in its response. In which case, if the server did not send the certificate the handshake failed, but for other clients even if the server did not send the CA in the handshake, the clients were sending the CA in their response and the handshakes were successful.
In general the root CA certificate don't need to be sent inside the TLS handshake, no matter if for client or server certificate. Trust anchors (i.e. the root certificate as the base of the trust chain) need to be already trusted by the peer and thus cannot be taken from a still untrusted network connection. If root CA is sent anyway it will be simply ignored.
I have to create an SSL connection between a client and a server. I've created a keypair and signed my public key with my private key. The server won't trust this so I need to get it signed by a CA. I presume that the server will trust a certificate which has been signed by the same CA as was used to sign its own certificate. How do I do the business of creating the signed certificate with keytool? Sorry if this is duplicated information on the Oracle website, but for some reason their pages keep breaking my internet browser.
knowledge so far is based on answer here
I presume that the server will trust a certificate which has been signed by the same CA as was used to sign its own certificate.
Correcting your assumption here: A system trusts various major Certificate Authorities (CA) by default (eg: GeoTrust, Entrust, OpenTrust, Verisign, etc...). When you get your CSR signed by any of these known CA's, the server will trust by default, not just by the CA that signed the server's certificate.
What you could do to test your SSL connection between the client and the server is to work with self-signed certificates.
I've created a keypair and signed my public key with my private key
You shouldn't be doing this as a client. The server is supposed to do this. If the server is working with self-signed certificates, they need to provide the client with that certificate, so that the clients can trust them to make the SSL connection.
As a server, you could use the keytool to create a self-signed certificate. When you are generating a keypair using keytool, it will ask you few attributes like commonName, organizationName, etc... using these attributes, the keytool will create a self-signed certificate and associate it with the private key. All you have to do is export this certificate using the keytool -exportcert command. Once you have done this part, you would use this certificate to secure the server.
Once the server is secured, the server should give or the client this certificate, because it is self-signed and the client's system will not trust it until you explicitly trust it. If the server has secured using a certificate signed by a CA, it need not provide the client with any certificate, because, if it is a known CA, it will already be trusted by the client system.
If I understand SSL/TLS correctly in server only authentication, After the handshake, the server sends the client it's public key and a digitally signed certificate signed by a CA. If the client has this CA's public key, it can decrypt the certificate and establish trust with the server. If it does not trust the CA, then the communication stops. In 2 way SSL where the client needs to authenticate back to the server, after the client receives the public key and the digitally signed cert then the client will send the server over it's public key and a digitally signed cert. The server will check to see if it has a public key for the client's cert and if it does it can establish trust with the client. I am setting up mutual authentication [ 2 way ssl] on a weblogic server [in this case the client, calling outbound to a web service] and the third party sent me a digitally signed cert and a certificate chain. Why do I need these. Isn't this what the server replies with after the handshake?
the server sends the client it's public key and a digitally signed certificate signed by a CA.
The certificate contains the public key. The key is not sent extra.
If the client has this CA's public key, it can decrypt the certificate
The certificate is not encrypted, it is signed by the CA. Thus no decryption is done but the client can verify this signature if the client has the CA's certificate (and thus its public key). But usually the certificate is not signed directly by a CA trusted by the browser but there are intermediate certificates. In this case the server will not only send the servers certificate but also all intermediate certificates which are needed to build the trust chain.
then the client will send the server over it's public key and a digitally signed cert.
Again, the public key is part of the certificate.
the third party sent me a digitally signed cert and a certificate chain. Why do I need these.
The first certificate is the client certificate. The chain certificates are needed to build the trust chain because the server does not trust the issuer CA of the clients certificate directly and thus needs the intermediate certificates.
I have trust store which contains Symantec. I am trying to connect to server which is signed by VeriSign. I am getting ssl "No trusted certificate was found” during the handshake. Can it be because I don't have VeriSign CA in trust store?
I am using Axis framework with SSLConnectionSocketFactory. With openssl I see the VeriSign certificate chain on the server
My problem solved after adding the VeriSign CA to trust store.