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.
I installed Rundeck on a new RHEL 7.7 box, using the rpm method. I can access the server just fine with http, but when I follow the directions in the docs, the server is not accessible from browsers or by curling localhost.
The only error I receive is:
WARN SslContextFactory --- [ main] No supported ciphers from [SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,...(many more ciphers)
Grails application running at https://localhost:4443 in environment: production
curl localhost:4443
curl: (35) Peer reports it experienced an internal error.
Relevant parts of the configuration files are as follows:
/etc/rundeck/profile:
RDECK_JVM="-Drundeck.jaaslogin=$JAAS_LOGIN \
-Djava.security.auth.login.config=$JAAS_CONF \
-Dloginmodule.name=$LOGIN_MODULE \
-Drdeck.config=$RDECK_CONFIG \
-Drundeck.server.configDir=$RDECK_SERVER_CONFIG \
-Dserver.datastore.path=$RDECK_SERVER_DATA/rundeck \
-Drundeck.server.serverDir=$RDECK_INSTALL \
-Drdeck.projects=$RDECK_PROJECTS \
-Drdeck.runlogs=$RUNDECK_LOGDIR \
-Drundeck.config.location=$RDECK_CONFIG_FILE \
-Djava.io.tmpdir=$RUNDECK_TEMPDIR \
-Drundeck.server.workDir=$RUNDECK_WORKDIR \
-Dserver.http.port=$RDECK_HTTP_PORT \
-Drdeck.base=$RDECK_BASE \
-Djdk.tls.ephemeralDHKeySize=jdk8 \
-Drundeck.rundeck.jetty.connector.ssl.excludedCipherSuites=SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384,SSL_RSA_WITH_AES_256_CBC_SHA256,SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384,SSL_DHE_RSA_WITH_AES_256_CBC_SHA256,SSL_DHE_DSS_WITH_AES_256_CBC_SHA256,SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_AES_256_CBC_SHA,SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA,SSL_ECDH_RSA_WITH_AES_256_CBC_SHA,SSL_DHE_RSA_WITH_AES_256_CBC_SHA,SSL_DHE_DSS_WITH_AES_256_CBC_SHA,SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256,SSL_RSA_WITH_AES_128_CBC_SHA256,SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256,SSL_DHE_RSA_WITH_AES_128_CBC_SHA256,SSL_DHE_DSS_WITH_AES_128_CBC_SHA256,SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_AES_128_CBC_SHA,SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA,SSL_ECDH_RSA_WITH_AES_128_CBC_SHA,SSL_DHE_RSA_WITH_AES_128_CBC_SHA,SSL_DHE_DSS_WITH_AES_128_CBC_SHA,SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384,SSL_RSA_WITH_AES_256_GCM_SHA384,SSL_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,SSL_ECDH_RSA_WITH_AES_256_GCM_SHA384,SSL_DHE_DSS_WITH_AES_256_GCM_SHA384,SSL_DHE_RSA_WITH_AES_256_GCM_SHA384,SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256,SSL_RSA_WITH_AES_128_GCM_SHA256,SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256,SSL_DHE_RSA_WITH_AES_128_GCM_SHA256,SSL_DHE_DSS_WITH_AES_128_GCM_SHA256"
#
# Set min/max heap size
#
RDECK_JVM="$RDECK_JVM $RDECK_JVM_SETTINGS"
#
# SSL Configuration - Uncomment the following to enable. Check SSL.properties for details.
#
if [ -n "$RUNDECK_WITH_SSL" ] ; then
RDECK_JVM="$RDECK_JVM -Drundeck.ssl.config=$RDECK_SERVER_CONFIG/ssl/ssl.properties -Dserver.https.port=${RDECK_HTTPS_PORT} -Dorg.eclipse.jetty.util.ssl.LEVEL=DEBUG"
fi
/etc/sysconfig/rundeckd:
export RUNDECK_WITH_SSL=true
export RDECK_HTTPS_PORT=4443
If I add export RDECK_JVM_OPTS="-Dserver.ssl.ciphers=SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384" to /etc/sysconfig/rundeckd I get the following:
[2020-03-29 09:01:51.533] WARN config --- [ main] Weak cipher suite SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 enabled for SslContextFactory#1456dec8[provider=null,keyStore=file:///etc/rundeck/ssl/keystore,trustStore=file:///etc/rundeck/ssl/truststore]
Grails application running at https://localhost:4443 in environment: production
curl: (35) Peer reports it experienced an internal error.
Other configurations:
/etc/rundeck/framework.properties:
framework.server.name = server-dns
framework.server.hostname = server-dns
framework.server.port = 4443
framework.server.url = https://server-dns
framework.rundeck.url = https://server-dns
/etc/rundeck/rundeck-config.properties:
grails.serverURL=https://server-dns:4443
keystore and truststore exist, I have attempted both self signed and real crts.
I'm at a loss here. I followed all sorts of guides and advice from the internet leading to my current (mis?)configuration.
Thanks
Edited to fix mistakes in the post.
Maybe you need to reference your keystore/trustore in ssl.properties file (usually at /etc/rundeck/ssl/ssl.properties path). I wrote a little guide to set up Rundeck with SSL.
1.- install Rundeck.
rpm -Uvh https://repo.rundeck.org/latest.rpm
yum install rundeck
2.- create keystore: (if you already have a certificate in .key/.crt or .pk12 formats, skip to 2b)
keytool -keystore /etc/rundeck/ssl/keystore -alias rundeck -genkey -keyalg RSA -keypass password -storepass password
2b.- in case you have your own certificate, do below:
If you have .crt and .key files, create a .p12 file:
openssl pkcs12 -export -in YOUR.crt -inkey YOUR.key -out NEW.p12
Convert it to a .jks (also if you have only the .p12 file):
keytool -importkeystore -destkeystore keystore -srckeystore NEW.p12 -srcstoretype pkcs12
3.- copy keystore as truststore.
4.- edit /etc/rundeck/ssl/ssl.properties file:
keystore=/etc/rundeck/ssl/keystore
keystore.password=password
key.password=password
truststore=/etc/rundeck/ssl/truststore
truststore.password=password
5.- edit /etc/rundeck/framework.properties file:
framework.server.port = 4443
framework.server.url = https://localhost:4443
6.- edit /etc/rundeck/rundeck-config.properties file:
grails.serverURL=https://localhost:4443
7.- edit/create /etc/sysconfig/rundeckd file:
export RUNDECK_WITH_SSL=true
8.- start the rundeck service.
systemctl start rundeckd
I have a Kubernetes that runs 3 node cassandra cluster. when I try to connect to cqlsh from the local machine it works fine. but after enabling SSL on the cluster, I am seeing the below error. I tried setting up the cqlshrc on my local machine and also kubernetes pods but still the same error. can someone help me?
$ kubectl run -i --tty --restart=Never --rm --image cassandra cqlsh -- cqlsh cassandra-0.cassandra.default.svc.cluster.local -u cassandra -p password --ssl
Validation is enabled; SSL transport factory requires a valid certfile to be specified. Please provide path to the certfile in [ssl] section as 'certfile' option in /root/.cassandra/cqlshrc (or use [certfiles] section) or set SSL_CERTFILE environment variable.
pod "cqlsh" deleted
pod default/cqlsh terminated (Error)
Follow the below steps to troublshoot
Check the subject,validity,issuer of remote node certificate (host-remote) from host-local
echo | openssl s_client -showcerts -connect host-remote:cassandra-ssl-port 2>/dev/null | openssl x509 -noout -subject -dates -issuer
Check cqlsh.cer.pem it may only one entry and has subject with CN=host-local, this can be a possible reason that you are able to connect to local but not remote host.
openssl x509 -text -noout -in path to trustore in cqlhrc file/cqlsh.cer.pem
Your truststore shoud have root certificate/CA certificate as well to connect to remote host by successfully validating the certificate chain which is coming from remote node .
You may need to embed the root certificate in trutstore
Refer this to apply ssl in in cassandra.
I have implemented the mosquitto broker for ubuntu on port 8883 and port 1883 and can't figure out why I keep getting the CA related errors shown below.
It happens when I test it using mosquitto_pub locally on the server and when I use the Paho/Python script as the client on my MacBook. My mosquitto.config file, mosquitto_pub command, and my mosquitto log messages are shown below. I've also included my openssl certificate creation commands in case I did something wrong.
This is my mosquitto.conf file
# Place your local configuration in /etc/mosquitto/conf.d/
# A full description of the configuration file is at
# /usr/share/doc/mosquitto/examples/mosquitto.conf.example
pid_file /var/run/mosquitto.pid
persistence true
persistence_location /var/lib/mosquitto/
#log_dest file /var/log/mosquitto/mosquitto.log
log_dest stdout
include_dir /etc/mosquitto/conf.d
log_type all
#-----------------------------------------------
#Default Listener
#-----------------------------------------------
port 8883
#------------------------------------------------
#Certificate Based SSL/TLS Support
#------------------------------------------------
cafile /../etc/mosquitto/ca_certificates/ca.crt
keyfile /../etc/mosquitto/certs/server.key
certfile /../etc/mosquitto/certs/server.crt
listener 1883
This is the mosquitto_pub command I use to test it.
sudo mosquitto_pub -h 305.875.987.34 -t test -m "Typing this" -p 8883 --cafile /../etc/mosquitto/ca_certificates/ca.crt
This is what the mosquitto log says when I run it.
1546507891: mosquitto version 1.5.5 starting
1546507891: Config loaded from /../etc/mosquitto/mosquitto.conf.
1546507891: Opening ipv4 listen socket on port 1883.
1546507891: Opening ipv6 listen socket on port 1883.
1546507891: Opening ipv4 listen socket on port 8883.
1546507891: Opening ipv6 listen socket on port 8883.
1546507929: New connection from 305.875.987.34 on port 8883.
1546507929: OpenSSL Error: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca
1546507929: Socket error on client <unknown>, disconnecting.
These are the openssl commands I used to create ca.crt, server.crt, and server.key. I created them in a folder called certs.
openssl genrsa -des3 -out ca.key 2048
openssl req -new -x509 -days 1826 -key ca.key -out ca.crt
openssl genrsa -out server.key 2048
openssl req -new -out server.csr -key server.key
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 360
I then moved ca.crt to /../etc/mosquitto/ca_certifications after deleting an old ca.crt I had made trying to fix the problem. I did this with the following two commands.
sudo rm /../etc/mosquitto/ca_certifications/ca.crt
sudo mv ca.crt /../etc/mosquitto/ca_certifications
I did the same thing with server.crt and server.key except I put them in /../etc/mosquitto/certs.
The broker seems to work fine on port 1883.
Let me know if you need any more info.
To start with I would rearrange your mosquitto.conf to make things more obvious what is linked to what and to remove the relative paths to your certs/key files as follows:
# Place your local configuration in /etc/mosquitto/conf.d/
# A full description of the configuration file is at
# /usr/share/doc/mosquitto/examples/mosquitto.conf.example
pid_file /var/run/mosquitto.pid
persistence true
persistence_location /var/lib/mosquitto/
#log_dest file /var/log/mosquitto/mosquitto.log
log_dest stdout
include_dir /etc/mosquitto/conf.d
log_type all
#-----------------------------------------------
#Default Listener
#-----------------------------------------------
port 1883
#------------------------------------------------
#Certificate Based SSL/TLS Support
#------------------------------------------------
listener 8883
cafile /etc/mosquitto/ca_certificates/ca.crt
keyfile /etc/mosquitto/certs/server.key
certfile /etc/mosquitto/certs/server.crt
I've swapped the port/listener entries to make it obvious that the SSL setup is bound to the port 8883 listener. I've also removed the /../ from the start of the paths as this is meaningless as it's impossible to go "up" a directory from the / "root".
Likewise you should use the direct paths for the mosquitto_pub command.
Also as you are copying files around as root (with sudo), make sure that the cert/key files are readable by the mosquitto user.
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.