In most of the online sources, I was told that in the two way TLS,
the client needs to provide the cert for the server to validate. My
case is that the device gets the cert from the CA, but when the
device attempt establish a tls connection, the pfx is required which
will contain the private key from the device.
I have used openssl to convert the pfx to .cert and .key. By only using the .cert part on
POSTMAN, I failed to connect to the server with 403. Only when I
include both .key and .cert the TLS 1.2 connection was established.
For the regular TLS (one-way), the private key will never be sent
from the server, but why is the client need to send pfx.
Related
I am trying to setup a Netty Server with HTTPS enabled. In order to establish the SSL/TLS connections, I need to fetch the certificiate from Safenet Luna Network HSM and pass that Cert to Netty's SSL Context.
I have generated a keypair in the Luna HSM and then generate a self sign certificate using the generated keypair. So now my self sign cert is present inside the HSM and I need to use that cert to establish TLS connections by initializing the SSL Context. According to the usgae of HSM we should not extract our cert and private key details outside of the HSM box.
Then how can i establish a TLS connection by using the certificate present inside Luna Network HSM.
I have tried to fetch the certiciate from HSM box by using the alias name of the certificate and later use that to initialize the SSL context but no luck.
My expectation is to establish TLS connections by using the generated certificate directly from HSM to initilaize SSL Context without extartcting any information oustide of the HSM box.
Thanks
So HSM works on 2way handshake to establish mutual trust, So HSM over HTTPS needs the following configuration:
From the client side: The client will have a self-signed certificate of the HSM host stored inside its own trust store.
On top of the client will have its own key pair of let's say RSA 2048 stored in keystore
From the HSM side: HSM will have a self-signed certificate received from the client (public key of rsa keypair) inside its trust store.
in a similar way its own key-store pair to communicate to client
End result:
Each party has trust between them (as they have their certificates loaded inside truststore) and a key pair to share messages in an encrypted format.
Article to get you started: https://dzone.com/articles/implementing-one-way-and-two-way-ssl-mutual-authen
I have traffic between clients (which send XML over HTTPS) to my IIS.
I tried to decrypt the traffic using Wireshark and the following settings:
Adding the private key:
But even after setting this, I can't see the decrypted data:
Should I change any other settings to see the original data?
There is strong possibility that a Diffie-Hellman (DH) key exchange is being used here. In that case Wireshark cannot decipher SSL/TLs with a private key. You can check for this in the handshake packet.
From the Docs:
The RSA private key file can only be used in the following
circumstances:
The cipher suite selected by the server is not using (EC)DHE.
The protocol version is SSLv3, (D)TLS 1.0-1.2. It does not work with TLS 1.3.
The private key matches the server certificate. It does not work with the client certificate, nor the Certificate Authority (CA)
certificate.
The session has not been resumed. The handshake must include the ClientKeyExchange handshake message.
I have a flask application(client) from where I need to send some data to a server(another flask application as of now) and get some corresponding data. I need to use REST because the server can be anything later(the current flask app is a dummy server for testing). I need to have SSL connection between client and server. I see that SSL works in several steps:
Client requests for an encrypted connection.
Server responds with an SSL Certificate which will have a public key.
Client verifies the SSL Certificate
Client creates a private key
Client encrypts the private key with the public key and sends it to the server.
Server decrypts it and gets the private key.
Thus an encrypted connection is established between client and server. Further exchange of data between client and server happens by encrypting the data with the private key.
This is what I am trying to achieve. Please correct me if I got the SSL concept wrong.
I have seen below implementation and works perfectly for me.
Client side uses requests.get() with verify=<path to server SSL certificate>. I have generated SSL certificate for server using openssl as follows.
openssl req -x509 -newkey rsa:4096 -nodes -out cert.pem -keyout key.pem -days 365
But I don't think all the above 7 steps are being covered here. What is the actual way of implementing SSL? Any help would be appreciated.
Client requests for an encrypted connection.
Correct.
Server responds with an SSL Certificate which will have a public key.
Correct.
Client verifies the SSL Certificate
Correct.
Client creates a private key
Incorrect. It is already far too late for this to occur.
Client encrypts the private key with the public key and sends it to the server.
Incorrect. There is no such step. See RFC 2246 and successors.
Server decrypts it and gets the private key.
Incorrect, ditto.
Thus an encrypted connection is established between client and server.
Incorrect, ditto.
Further exchange of data between client and server happens by encrypting the data with the private key.
Incorrect, ditto. TLS works by (1) establishing trust via the server certificate and PKI; (2) optionally establishing trust via the client certificate; and (3) establishing a symmetric session key via a process of key negotiation, in which the actual session key is never transmitted.
This is what I am trying to achieve.
No it isn't. You are trying to establish a TLS connection. What it does is really very little concern of yours.
Please correct me if I got the SSL concept wrong.
You got it totally wrong.
I have generated SSL certificate for server using openssl as follows.
No you haven't. You have created a Certificate Signing Request (CSR). This is useless until you get it signed by a Certificate Authority (CA). It isn't an SSL certificate.
In the above method of implementation, client verifies the server's certificate for every rest call but I dont want to do this. I want to create an encrypted connection between client and server and then the further exchange of data should be encrypted. So, I think the initial creation of enrypted connection between client and server is missing. Also, the private key generation from client side is missing. I want to implement SSL and I think TLS is different from SSL. Correct me if I am wrong.
You are wrong. TLS supports session resumption, which allows for abbreviated handshakes, which eliminates the certificate exchange steps. The 'private key generation from client side' step is missing because it doesn't necessarily exist. You're guessing.
What is the proper way of using SSL certificates for private applications? By private I mean that I am the only user, and software is running on my computers.
I want to have a encrypted communication between two of my programs. I want to send passwords between them, so I need to be sure that remote program is not fake/hacked.
As far as I understand I don't need to get paid SSL certificate from the CA, if there is no third party involved.
Is the following correct?
Server has a private key and self-signed SSL certificate.
Client has a copy of server's self-signed certificate (it needs to be well protected).
During the handshake server sends the certificate to client.
client checks if the certificates are the same.
client can start encrypted transmission.
Is there other way?
Server has a private key and self-signed SSL certificate.
Yes
Client has a copy of server's self-signed certificate (it needs to be well protected).
The client has either a copy of the certificate or the certificates public key or the fingerprint of these. Since the certificate is public these information do not need to be protected. Only the private key of the server (residing only in the server side) needs to be protected because using this key one could prove ownership of the certificate.
During the handshake server sends the certificate to client.
Yes.
client checks if the certificates are the same.
Kind of. It might check the certificate or the public key or the fingerprints.
client can start encrypted transmission.
Yes.
I would recommend that you read the OWASP article about certificate and public key pinning. It also contains sample code for various environments.
Client has a copy of server's self-signed certificate (it needs to be well protected).
Clients do not have copy of the server certificate. They get it in SSL handshake
client checks if the certificates are the same.
NO! Clients will have the public certificate of the Certificate Authorities who would have signed the server certificate. They will validate the server cert with the CA cert including things like certificate expiry, CRLs. Not compare for 'sameness'
In your case you are using the self-signed certificates. The clients should be made to ignore the self signed certificate and proceed with SSL handshake.
I would recommend you read through SSL handshake sequence again.
I'm trying to create web application with client certificates, generated programmatically. My main problem is following: I've added generated .p12 keystore to my web browser, but it doesn't send certificate to the server.
How does browser understand which x509 certificate it should use? And is it possible to debug SSL in Chrome of Firefox?
SSL/TLS server sends Certificate Request message (see RFC 4346 for TLS 1.1 or others). In this message there is only certificate type and acceptable certificate authorities names, so server doesn't tell anything about particular certificate.
The possible reason is that your certificate of invalid type (i.e. DSA instead of RSA but key exchange algorithm depends on client RSA certificate), or server requests certificate of different certificate authority.