# TLS Mutual authentication problem **URL:** \ **Category:** HiveMQ Community Edition\ **Created:** [June 26, 2023, 10:49pm UTC](https://community.hivemq.com/t/tls-mutual-authentication-problem/2181 "2023-06-26T22:49:48Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Fabio](https://avatars.discourse-cdn.com/v4/letter/f/f4b2a3/32.png) [@Fabio](https://community.hivemq.com/u/Fabio)\ **Post date:** [June 26, 2023, 10:49pm UTC](https://community.hivemq.com/t/tls-mutual-authentication-problem/2181/1 "2023-06-26T22:49:48Z")
Hello. I set up an MQTT broker cluster on AWS as explained here: [Building an elastic high availability MQTT broker cluster on AWS](https://www.hivemq.com/article/running-hivemq-cluster-aws-auto-discovery). Then I wanted to implement mutual TLS authentication. I have a RootCA, a BrokerCA and a ClientCA that are both signed by RootCA. Actual broker certificates are signed by intermediate BrokerCA and client ones are signed by ClientCA (RootCA → BrokerCA → broker and RootCA → ClientCA → client). After having generated all certificates, what I did was: 1. Creating broker keystore, with a broker certificate signed by intermediate BrokerCA (common name set to Cluster Load Balancer DNS name): ```auto keytool -import -file ~/myCA/brokerCA/certs/hivemq.cert.pem -alias hivemq -keystore hivemq-keystore.jks -storepass password -storetype JKS ``` 1. Creating broker truststore, with ClientCA certificate (Broker has to accept only certificates signed by ClientCA) ```auto keytool -import -file ~/myCA/clientCA/certs/client.cert.pem -alias client -keystore hivemq-truststore.jks -storepass password -storetype JKS ``` 1. Copying keystores into broker’s /opt/hivemq/conf directory, modifying /opt/hivemq/conf/config.xml accordingly and restarting hivemq daemon. At this point TLS listener is ready to accept connections, according to logs: _Enabled protocols for TCP Listener with TLS at address 0.0.0.0 and port 1883: [TLSv1.3, TLSv1.2, TLSv1.1, TLSv1]_ _2023-06-26 22:13:26,723 INFO - Enabled cipher suites for TCP Listener with TLS at address 0.0.0.0 and port 1883: [TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384, TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_GCM\_SHA256, TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256, TLS\_ECDHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384, TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA, TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA, TLS\_RSA\_WITH\_AES\_128\_GCM\_SHA256, TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA, TLS\_RSA\_WITH\_AES\_256\_CBC\_SHA, TLS\_AES\_128\_GCM\_SHA256, TLS\_AES\_256\_GCM\_SHA384]_ _2023-06-26 22:13:26,725 INFO - Starting TLS TCP listener on address 0.0.0.0 and port 1883_ _2023-06-26 22:13:26,771 INFO - Started TCP Listener with TLS on address 0.0.0.0 and on port 1883._ 1. Now, i use mqtt cli to connect to the broker, specifying _cafile_ as the BrokerCA cert file, that signed the hivemq broker, _key_ as the private key of a certificate signed by the ClientCA that represents the current client, _cert_ representing the certificate chain that contains a concatenation of current client certificate, ClientCA certificate and RootCA certificate (as suggested here: **NOTE:** \*In production, we recommend using client and server certificates that are signed by a trusted CA or the internal CA of your company. To create individual client certificates for IoT devices, create an intermediary from your ROOT CA and sign individual certificates with this intermediary. Make sure that clients present the entire certificate chain on connection, this way, you only need to include your ROOT certificate in the HiveMQ truststore. \*) mqtt sub -t topic -q 1 -h [HiveMQCluster-XXX.elb.eu-central-1.amazonaws.com](http://HiveMQCluster-XXX.elb.eu-central-1.amazonaws.com) -i client --cafile ~/myCA/brokerCA/certs/broker.cert.pem --key ~/myCA/clientCA/private/publisher.key.pem --cert ~/myCA/clientCA/certs/client-chain.cert.pem -d **CLIENT LOGS:** _failure: com.hivemq.client.mqtt.exceptions.ConnectionFailedException: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake\_failure_ _Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake\_failure_ **BROKER LOGS:** _SSL Handshake failed for client with ID UNKNOWN and IP X.X.X.X: no cipher suites in common_ It works if I use the simple TLS configuration provided here [Setting up TLS for your cloud-based MQTT broker](https://www.hivemq.com/article/end-to-end-encryption-in-the-cloud/), but does not If I use this setup. Could you please help? ---
**Author:** ![Diego](https://avatars.discourse-cdn.com/v4/letter/d/f04885/32.png) [@Diego](https://community.hivemq.com/u/Diego)\ **Post date:** [June 28, 2023, 1:47pm UTC](https://community.hivemq.com/t/tls-mutual-authentication-problem/2181/2 "2023-06-28T13:47:42Z")
Hello @Fabio Welcome to HiveMQ Community! Looking into the scenario you have described and the broker error message, the issue could be related with: - Server and client don’t have a cipher suite in common so the TLS handshake can’t be done. - Misconfigured server private key and certificate. Can you please share the results of both commands below? `mqtt sub -t topic -q 1 -h HiveMQCluster-XXX.elb.eu-central-1.amazonaws.com -i client --cafile ~/myCA/brokerCA/certs/broker.cert.pem --key ~/myCA/clientCA/private/publisher.key.pem --cert ~/myCA/clientCA/certs/client-chain.cert.pem --tls-version TLSv1.2 --ciphers='TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256' -d` `openssl s_client -connect HiveMQCluster-XXX.elb.eu-central-1.amazonaws.com:1883 -servername HiveMQCluster-XXX.elb.eu-central-1.amazonaws.com -debug` Kind regards, Diego from HiveMQ Team