Background:
I have a CA root certificate (.crt) file with me and when I try to use the same certificate in MQTT.fx desktop installation tool I am able to connect to the broker successfully.
Problem:
Whereas, when I try to use the same certificate and try to connect using Java with Micronaut framework I am asked for private key, password, etc.
What did I try:
I tried converting the .crt to pem and establish connection using micronaut by using these parameters certificate-authority, certificate, private-key (Passed the same value for all)
tried to create the client certificate using the CA certificate using openssl
Expected solution:
Establishing a Connecting with MQTT broker using java either with or without Micronaut framework.
Note: All I have is the .crt certificate provided by the client.
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 setting up SSL for an IOT device that uses MQTT protocol acting as a client and connecting to a broker server. The server is using Certbot for SSL keys and registration. I configure the IOT device using AT commands and in the AT command I need the cacert, clientcert, and clientkey shown in the picture below. But I am wondering what are the names of these files on my server which is Ubuntu 20?
My best guess is one of the files below:
root#broker1:/etc/letsencrypt/keys# ls
0000_key-certbot.pem 0001_key-certbot.pem 0002_key-certbot.pem 0003_key-certbot.pem
or
root#broker1:/etc/letsencrypt/live/mydnsaddress# ls
README cert.pem chain.pem fullchain.pem privkey.pem
Unless you are using SSL Client authentication the only files you need on the client will be /etc/letsencrypt/live/<hostanme>/fullchain.pem
If you are using SSL Client authentication then you will need a certificate and private key specific to that client and that will not be issued by LetsEncrypt but by a private CA.
I need a clarity for two-way SSL, if I Create Client self-sign certificate, using OpenSSL then save it in Pkcs12 file and Server self-sign certificate using Java keytool then save it in Jks file. Can both certificate work for two-way SSL?
Which TLS version openssl used?
The structure of a certificate is a standard and independent of a specific tool. This means it does not matter what tool is used to create certificates as long as it creates proper certificates. Also, the TLS protocol version used inside a connection has nothing to do with the certificate used for the connection and what tool was used to create the certificate.
I have the root certificate pem file from a Linux server. The application that needs to connect to that server is telling me it needs a publicCert pem file and a privateKey pem file to communicate with the server.
Do I generate these from the root certificate? My thought is that I would feed openssl the path to the root cert and then it would dump out the publicCert/privateKey I want.
I've created the certs on the server as described here. Now I need to install on the downstream device as described here.
The input of client connection I need to use requires these parameters:
connString: 'HostName=foo'
protocol: MQTT
publicKeyCertificateString: certificateString or path to certificate
privateKeyString: keyString or path to key
new DeviceClient(connString, protocol, publicKeyCertificateString, privateKeyString);
Cert format: pem
Authentication Format: x509
You would only need the Root CA certificate to be available in the trust store of the downstream device. What you seem to be looking to do is mutual authentication. Azure IoT Edge doesn't currently support downstream devices to connect using client certificates (mutual authentication). (Edge device only supports symmetric key authentication but doesn't support x509 certificate authentication). For publishing messages using MQTT, you would need to generate a SAS token for the downstream device and then use it to communicate with iot hub (edge device would act as a transparent gateway).
Related : c# Azure IOT Edge Auto-provision with Device Provisioning Service(DPS) with x509 certificate sample needed
Followed steps to integrate Worklight with backend system. In 5.0.6 adapters should support mutual SSL.
Import cert into default.keystore with alias named cert1
Modified adapter's sslCertificateAlias as cert1
When using Worklight Studio to run deployed adapter connecting with server, it is complaining about "Unable to find certificate chain with alias: 'cert1'".
What are the steps missing?
Check "ssl.keystore.*" properties in "worklight.properties" file, after it check if the cert exists in the keystore file using keytool:
keytool -list -keystore default.keystore
Here is are steps to configure mutual SSL between adapter and backend server with self signed certificates:
generate adapter's private key in "default.keystore" and export its public certificate
import adapter's certificate into backend truestore file
in case backend hasn't CA signed certificate:
generate backend's private key in its keystore file and export public certificate
import backend's public certificate into "default.keystore" file on WL server
Check worklight.properties file. Make sure that ssl related setting point to a default.keystore.
Figured out yesterday. Have to config certificate chain in proper way.
All certifications (server cert, first level cert and root cert) have to combine into one in special order and import with private key into keystore. Then use one alias name so that Worklight adapter could find it.