I am setting up a IoT 2-way TLS authentication.
The common way is that both client- and the root (CA) certificate Private Key is RSA.
Now we have devices with limited memory, why we chose to switch to Eliptic Curve Private Keys on the client certificates in the IoT devices. The server certificate remained untouched (RSA).
From my understanding the handshake should succeed. Or do I understand anything wrong? Or do we have to switch the CA certificate to ECC as well?
After a quick test session: It IS possible to use a client certificate with a different private key algorithm than the Root Certificate on the server.
Client: OpenSSL
Server: BoringSSL
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 am working on an application hosted on Heroku that communicates with an apple system that requires SSL certificates to be in place. Apple requires that an ECC certificate be used where Heroku does not support ECC certificates - only RSA.
I am curious to know if I can generate my signing request with an ECC signature and use this to generate the certificate from apple but then convert this ECC key to an RSA key so that Heroku can still interpret this.
Do I have a drastic misunderstanding of how these two certificates are implemented that means this approach is not possible or do I just need to do the right openSSL commands to the cert to generate the key formats I need?
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.
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.