I want to establish a secure connection using TLS to m12.cloudmqtt.com (MQTT Cloud - cloudmqtt.com) for my owntracks MQTT client (Android device).
According to documentation at OWNTRACKS (http://owntracks.org/booklet/features/tls/ ) one has to provide CA CERT and the CLIENT CERT.
CA CERT I can understand according to documentation at cloudmqtt.com (www.cloudmqtt.com/docs-faq.html#TLS_SSL) is a trusted public CA. (That I can obtain from any cert store)
But for CLIENT CERT, how do I obtain this? Do I need to obtain a certificate ( for my android MQTT Client) from the above CA. Or is any other way possible to encrypt the session ?
Client certificates are only needed if the broker supports certificate based client authentication. The connection will still be encrypted and you can verify the broker is who they claim to be.
The cloudmqtt doc does not mention certificate based client authentication. So the implication is that they do not support client authentication.
You should be able to set Owntracks up with a username and password and TLS without a client certificate
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
In a TLS communication I always thought the server would send the public certificate to the client during the handshake process.
However, I received a request from a provider asking us to manually install a certificate in order to initiate a TLS communication with one of their STunnel server.
I'm a bit confuse by this request. Is there's a situation where TLS server would not be able to send the certificate to the client and therefore required a manuel certificate installation?
There are two cases where a certificate installation is needed on the client side:
The server is using a certificate not issued by a public CA, i.e. self-signed or issued by a private CA. In this case the client must import the certificate or CA up front and install it as trusted.
The server is requiring client authentication based on certificates, i.e. not only the server authenticates to the client with a certificate but also the client to the server (instead or additionally to typical passwords). In this case the client has to get a client certificate and matching key and import so that it can be used for authentication.
It is unclear which of these cases is the one you are dealing with.
There is a PKI with a single CA issuing all the x509 certificates in my network.
So on my network all the servers and clients possess a certificate from my CA stored in their corresponding keystore together with the private key. Each server and client has also the CA certificate in a chain file available to validate the trust chain of the peer x509 certificate when TLS mutual authentication is going on. All fine.
Let’s suppose I have now on my network two servers and two clients and I want to make sure Client_A and Server_A succeed with TLS mutual authentication using their x509 certificates, as Client_B and Server_B should do.
At the same time, I want to make sure TLS mutual authentication between Client_A and Server_B will not succeed. (Also valid between Client_B and Server_A).
How can I make the servers and clients in my network not only verifying the trust chain, but also respecting some kind of whitelist?
Maybe this is not feasible on TLS Layer, that is what I want to have clarified.
You can achieve this using any of the below 2 approaches-
Verifying client certificate at TLS layer: Create separate intermediate issuing CA for each client group. For example, for all the clients of Server_A, create a CA named Ca_Client_A. So your chain will look like rootCA -> Ca_Client_A -> client certificates. Import this Ca_Client_A in the trust-store of Server-A. Now Server_A will allow connections to the clients which has issuing ca Ca_Client_A. Similarly, you can create Ca_Client_B intermediate CA for serving client group B by server B.
Verifying client certificate at Application layer: For this, you need to write authentication logic in your application server where you need to put constraints such as allowed client certificate-serial numbers or CN name matching with keyword for successful authentication.
Hope that helps.
There isn't any way (that I know of) to do this at the TLS layer.
Most TLS libraries offer a callback option during the certificate exchange, and that would be the appropriate place to check the certificate against a list. Returning the library-specific version of failure/unacceptable will usually cause a TLS handshake failure, and no data will have been transmitted.
A lot of this depends on the server software you are using, not the TLS standard itself. Some software packages can be configured to trust certificates issued by a particular CA certificate. In your scenario, this would allow ANY certificate issued by your CA to connect to ANY server configured to trust your CA certificate. Other server software can be configured to trust a particular certificate, or certificates with a given subject (distinguished name of the certificate, subjectAltName, etc.) So, it depends on which particular "server" you're trying to connect to. Is this an Apache web server? IIS? Tomcat? The answer varies depending on what server platform we're talking about.
I'm debugging SSL errors between Websphere MQ Server and Client using T.Rob's suggestions and need help understanding the SSL handshake (SSL connect to MQ using .net mq client SSLV3?).
My WMQ 7.5 client application is C code and uses a keystore (.kdb). Utilizing a CHLTAB provided by the WebSphere admin. The WMQ server is running Java and the channel is defined with mutual authentication.
The article states that in the SSL/TLS handshake, the server always sends its public certificate in response to a connections request. The client then must validate that certificate by first checking the signature and validity date, then looking in its trust store for the thing that signed the certificate.
Here's my confusion: Since my keystore on the client side has only the application personal cert, how does the client validate the public certificate sent by the server? I have provided the Common Name of my application cert to the WebSphere server admin but nothing more than that.
Thanks in advance for the clarification!
The bit about "my keystore on the client side has only the application personal cert" is troubling. That won't work. The client KDB must have the server's public key. If the MQ server has SSLCAUTH(OPTIONAL) the the server's public cert is all that's required in the KDB for the connection to succeed.
The first part of the TLS handshake is where the client validates the server's certificate. The use of public/private key pairs is how the authenticity of the thing on the other side is assured. In order for that to happen the server must have its own personal certificate and the client must have the public key of the root of the signer chain. In the case of self-signed certificates the public portion of the personal cert must be trusted by the client. In the case of CA-signed certs the CA Root must be trusted by the client. Whichever one it is, the client must trust something used to sign the server's personal cert or that cert can't be validated.
The TLS handshake is symmetrical so the second part works exactly the same as the first but the roles are reversed. Therefore, in cases where mutual authentication is enabled the client must have its own personal cert (because that contains the private key) and the server must trust whatever signed the client's matching public key. If the client cert is self-signed the QMgr has to trust it. If the client's cert is CA-signed, the QMgr must trust the signer. Either way, the QMgr has to have a cert to validate the client in its KDB.
Following this logic, for anonymous client connections the required parts are the personal certificate in the QMgr's keystore (because it contains the QMgr's private key), and the matching trusted certificate in the client's KDB or for Java the Trust Store. Neither of these is optional.
If the client is to be authenticated you still need the same two certs as for anonymous clients because that part of the handshake has to complete before the client is authenticated. In addition, now you also need the client to have its own personal certificate (because it contains the client's private key) and the QMgr now needs to trust whatever signed the client's certificate - the client cert if self-signed or the signer root if CA-signed.
As a side note, There is also some confusion in the post because it says that "My WMQ 7.5 client application is C code and the WMQ server is running Java." There is nothing in the queue manager that uses Java on the server side. There are Java components installed to do things like manage JNDI objects and run the sample code. In modern MQ versions Java runs the Web Console. But there are no Java components in the QMgr itself and no Java components in the path of the incoming channel connection request. That's all habdled by the QMgr's listener, agent, and other internal processes. So I'm not at all sure what is being referred to there other than that the notion of Java running on the MQ server side and participating in the TLS handshake might be a source of some of the confusion mentioned in the post. ;-)
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.