I'm playing with mqtthub and ESP32 CHIP. I would like to connect in most secure way so i thought maybe try with TLS connection at the beginning and later i could also encrypt data which is sent to broker(mqtthub).
I successfully managed to connect with mosquitto on linux using /etc/ssl/certs path to CA certificates.
I would like now to copy the certificate I need into flash memory that my app written in C can use it while it connects to broker on port 8883. How can i guess which one public CA certificate is the right one i need to copy from /etc/ssl/certs ?
PS: i found this on mqtthub forum:
https://decoder.link/sslchecker/node02.myqtthub.com/8883
might it be helpful?
Looking at the certificate chain returned from your server I see the root certificate has a common name DST Root CA X3:
$ openssl s_client -showcerts -connect node02.myqtthub.com:8883
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = node02.myqtthub.com
verify return:1
The directory /etc/ssl/certs in my host happens to contain a cert named DST_Root_CA_X3.pem. This would be a good candidate to try.
ok, i found the solution. Instead of pointing to entire directiory
mosquitto_sub -h node02.myqtthub.com -p 8883 --capath /etc/mosquitto/certs -i linux_machine -u nariox -P myPassword -t test/connection -q 2
i run the command with cafile instead of capath
mosquitto_sub -h node02.myqtthub.com -p 8883 --cafile /etc/mosquitto/certs/DST_Root_CA_X3.crt -i linux_machine -u nariox -P myPassword -t test/connection -q 2
what solved my problem. If anyone could explain it to my why i will be grateful
Related
I am using the command ...
openssl s_client -showcerts -connect reds-cluster-01:443
And I get the output:
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1
verify return:1
depth=0 CN = *.my-co-example.com
verify return:1
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=*.my-co-example.com
i:/C=US/O=DigiCert Inc/CN=RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1
-----BEGIN CERTIFICATE-----
MIIGnxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxgkqhkiG9w0BAQsFADBZ
...
I assume that means somewhere on the filesystem of my server there would be a file somewhere that has the string ...
MIIGnxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxgkqhkiG9w0BAQsFADBZ
... in it. How can I find that file without having to execute something like?
sudo grep -sr MIIGnxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxgkqhkiG9w0BAQsFADBZ /
I assume that means somewhere on the filesystem of my server there would be a file somewhere that has the string ...
This assumption is wrong. What you see is part of the server certificate, which need to be checked against a CA certificate located in the local trust store. The server certificate is typically not in the local trust store. See SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate? for more on certificates are checked.
You can see more with "CURL -W CERTS" from Daniel Stenberg (also on Stack Overflow), which works on curl for the past 25+ years.
When a client connects to a TLS server it gets sent one or more certificates during the handshake.
Those certificates are verified by the client, to make sure that the server is indeed the right one: the server the client expects it to be; no impostor and no man in the middle etc.
When such a server certificate is signed by a Certificate Authority (CA), that CA’s certificate is normally not sent by the server but the client is expected to have it already in its CA store.
(So no file to check on the filesystem)
Ever since the day SSL and TLS first showed up in the 1990s user have occasionally wanted to be able to save the certificates provided by the server in a TLS handshake.
The openssl tool has offered this ability since along time and is actually one of my higher ranked stackoverflow answers.
Now (for curl 7.88.0,to be shipped in February 2023), Daniel proposes:
Using the –write-out (-w) option and the new variables %{certs} and %{num_certs}, curl can now do what you want.
Get the certificates from a server in PEM format:
$ curl https://curl.se -w "%{certs}" -o /dev/null > cacert.pem
$ curl --cacert cacert.pem https://curl.se/
That is easier to parse than the openssl s_client -showcerts -connect current alternative.
I am trying mtls authentication in MQTT. I am using mosquitto to achieve this. When I created a server and client certificate from the same CA then the connection was successful. But if I use a different CA for creating a client certificate then it's failing with the below message
Client null sending CONNECT
OpenSSL Error[0]: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca
Error: The connection was lost.
Is it mandatory to use the same CA for both client and server certificates in mtls?
Mosquitto.conf
listener 8883
certfile C:\\server.crt
keyfile C:\\server.key
require_certificate true
cafile C:\mqtt-ssl-demo\ca.crt
allow_anonymous true
Running broker using
mosquitto -c "C:\Program Files\mosquitto\mosquitto.conf"
Subscribe with a client with a certificate signed by server cert ca [SUCCESS]
mosquitto_sub --cafile C:\mqtt-ssl-demo\ca.crt -t test -d -h Computername -p 8883 --cert C:\mqtt-ssl-demo\client.crt --key C:\mqtt-ssl-demo\client.key
Subscribe with a client with a certificate signed by other ca [FAILURE]
mosquitto_sub --cafile C:\mqtt-ssl-demo\ca.crt -t test -d -h Computername -p 8883 --cert C:\mqtt-ssl-demo\otherclient.crt --key C:\mqtt-ssl-demo\otherclient.key
Created certificate using Mosquitto SSL Configuration -MQTT TLS Security
The important thing to realise here is that the CA file passed to the broker as part of it's config is used to verify the certificate of any connecting clients.
Where as the CA file passed to the client (mosquitto_sub) is used to verify the certificate the broker presents.
So if you are using different CAs then these files need to be different, it's not clear from what you've posted which CA certs you are using where.
Right now I have to do an initial test of a mqtt broker (ssl).
However right now I don't have the valid truststore certificates, however I would like to test the basic connectivity, ignoring SSL errors regarding hostname verification, certificate validation etc.
Unfortunately I am not successful, even with a broker I know it's working.
What I'm doing:
mosquitto_sub -h the_host -p 8883 -t '#' -v -u myUser -P myPass --insecure -d --capath /etc/ssl/certs
According to the manpage I just use the --capath to identify it's a TLS connection, well knowing that the necessary root certificate is not available here.
What I get is this:
Client mosqsub|11262-csbox sending CONNECT
Error: A TLS error occurred.
Any idea what I'm doing wrong?
Using --insecure just disables the verification of the hostname in the certificate presented by the broker. It does not remove the need to have a copy of the CA certificate that signed the brokers certificate.
So if /etc/ssl/certs doesn't contain a matching CA certificate then the connection will fail.
If needed you should be able to use something like openssl s_client to download the certificate chain directly from the broker, you can then point to that file with the --cafile option instead of the --capath option.
I have a simple question that I hope has a simple answer! I can connect and publish/subscribe to my broker using a Certificate Authority in .pem format. For example, the command:
mosquitto_pub --cafile CA.pem -h www.example.com -p 8883 -t test -u "usr" -p "pw"
is successful. However, when I convert CA.pem to CA.der using
openssl x509 -in CA.pem -out CA.der -outform DER
and use CA.der as the --cafile I get an error:
Unable to connect (A TLS error occurred.).
I believe the conversion is correct because if I convert CA.der back to CA2.pem using openssl x509 I can successfully connect. My guess is that I have to set something in my mosquitto.conf file to allow *.der, or something similar, but cannot find anything that addresses this in the documentation, or anywhere online. I need to use the .der format because I am setting up an MQTT client on a TI CC3200 dev board, and TI's API requires all certs in .der format.
Some additional information in case it's needed
I got the CA for my domain through CertBot, and the certificate chain looks like this:
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = <www.example.com>
verify return:1
mosquitto.conf
allow_anonymous false
password_file /etc/mosquitto/passwd
listener 1883 localhost
listener 8883
certfile /etc/letsencrypt/live/<www.example.com>/cert.pem
cafile /etc/letsencrypt/live/<www.example.com>/chain.pem
keyfile /etc/letsencrypt/live/<www.example.com>/privkey.pem
No, mosquitto only supports supplying certificates in PEM format, you can not use DER files.
There is nothing to say you have to use the same format (PEM/DER) of certificate storage on the broker side as on the client side.
I tried following the guide shown by mosquitto but once I launch the mosquitto
mosquitto -c mosquitto.conf
which defines port, location of ca.crt, server.crt, server.key
then I followed similar step using the same CA file, to sign the client key and certificate.
Then launched client
mosquitto_pub -p [port] -h localhost --cafile [ca.crt filepath] -t "hello" -m "hello world"
when I do it like this without key and certificate I get
Error: Success
but when I do it with key and certificate
mosquitto_pub -p [port] -h localhost --cafile [ca.crt filepath] --cert [client.crt path] --key [client1.key path] t "hello" -m "hello world"
I get
Error:Success
On the server side I See the following errors
... routines:SSL3_READ_BYTES: sslv3 alert certificate unknown
... routines:SSL3_READ_BYTES: ssl handshake failure
I ran openssl commands to verify CA approves of both generated certificates, and it did.
It turns out, when entering the detail of the certificate, i mistake the common name section's purpose. After I set it to the ip address of the server, it all worked well
I was getting the same error. I tried to subscribe like this:
mosquitto_sub -h ip_address -p 8883 -t topic --cafile /etc/mosquitto/ca_certificates/ca.crt -d.
Replace ip_addres with your ip address that you wrote when you created certificate. In your question, you wrote localhost. If you replace it with ip address it will be work.