I started mosquitto broker with SSL using CA,cert and key when I am trying to connect to broker the library in elixir tortoise is asking me to put the key and cert with certifi. When I looked into certifi it is showing the list of CA can we use this self signed?
Tortoise.Supervisor.start_child(
client_id: "smart-spoon",
handler: {Tortoise.Handler.Logger, []},
server: {
Tortoise.Transport.SSL,
host: host, port: port,
cacertfile: :certifi.cacertfile(),
key: key, cert: cert
},
subscriptions: [{"foo/bar", 0}])
Should I put the key and cert and client side?? I think that is very bad as key is secret please help me understand how it works
For "normal" SSL connections where the client wants to prove the broker is who they claim to be the client should only require a list of CA certificates to check the certificate presented by the broker. For this case you should normally leave the key and cert fields empty
If you are doing mutually authenticated SSL where the client is also proving to the broker who they are then you need to supply the client with it's own certificate/key (not the certificate/key from the broker but probably[but not required] signed by the same CA)
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
We have a K8S service leveraging NGINX and in some flows would like to accept client certificate authentication.
Service has a dynamic list of public trusted client certificates (PEM format), and the root CAs aren't known.
In NGINX, it seems like the best setting to use would be:
nginx.ingress.kubernetes.io/auth-tls-verify-client: optional_no_ca
While sending the full certificate ($ssl_client_escaped_cert) to the upstream service to compare the entire public cert.
The question is whether NGINX will still perform the client cert validations during SSL handshake (and only skips CA checks), to verify the request is indeed sent by the one and only owner of the cert and its private key.
It will still check in the TLS handshake that the public key in the certificate can be used to verify the signature in CertificateVerify, i.e. that the client actually owns the private key to the sent certificate.
It will not check that the certificate itself is issued by a trusted CA etc - such verification are expected to be done elsewhere.
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
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. ;-)
I am sure this is embedded in the details of the SSL certificate/HTTPS specs but I am not entirely grokking this subject.
If a modern browser connects to a HTTPS site, the body of the HTTP request is encrypted. Is the SSL certificate essentially the "public" key used to communicate back and forth between the client and server?
Couldn't a hacker get the public key from the public site, say "https://www.google.com" and monitor client/server traffic and decrypt the data?
Also, do clients need to verify the "issuer" of a certificate. For example, self sign certificates clients don't need to verify but for certificates provided from a trusted issuer, what happens during the certificate verification process?
The server's certificate contains a public key which in fact is visible to everybody. This key in turn is used during the handshake between the server and client in order to create a unique session key that will be used to encrypt any further messages:
http://en.wikipedia.org/wiki/Secure_Sockets_Layer#TLS_handshake_in_detail
Couldn't a hacker get the public key from the public site, say
"https://www.google.com" and monitor client/server traffic and decrypt
the data?
The hacker won't know the session key. He will be listening to (senseless) encrypted stuff.
Also, do clients need to verify the "issuer" of a certificate. For
example, self sign certificates clients don't need to verify but for
certificates provided from a trusted issuer, what happens during the
certificate verification process?
Like you said, the issuer of the certificate is verified against a pre-defined list of trusted authorities. Any certificate up in the chain will be verified too, including the trusted issuer, expiration dates. Additionally each certificate contains URLs that point to Certificate Revocation Lists (CRL Distribution Points), the client will attempt to download the list from such URL and ensure the certificate at hand has not been revoked.