Issue Connecting to HiveMQ Using Let's Encrypt Certificate

Help
1

Hello,

We are currently trying to connect to HiveMQ using the certificate provided by Let's Encrypt. However, we keep encountering an "invalid certificate" error during the connection process.

Although HiveMQ shows some connection activity, we are unable to gain access to our HiveMQ instance due to this issue. We have already installed and configured the certificate correctly, but the problem persists.

We are using only the CA certificate (without a client certificate) for authentication, and we need guidance on whether additional configurations are required.

Here are the AT commands we executed:

  1. List available certificates:
    AT+CCERTLIST
    Response: +CCERTLIST: "e6.ertificate.pem"

2.Configure authorization mode:
AT+CSSLCFG=authmode,0,1
Response:OK

3.Set CA certificate:
AT+CSSLCFG=cacert,0,isrgrootx1.pem
Response: OK

  1. Start MQTT service:
    AT+CMQTTSTART
    Response:OK

5.Acquire client status:
AT+CMQTTACCQ=0,"TEST_USER32",1
Response: OK

6.Set SSL context:
AT+CMQTTSSLCFG=0,0
Response: OK
Your guidance would be greatly appreciated.

7.Connect to MQTT broker:
AT+CMQTTCONNECT=0,"453f80f5df2941fcaf3697b7c1fd8848.s1.eu.hivemq.cloud",8883,1,1,"test_user","Test1234"
Response: ERROR

Could you please help us identify what might be causing this issue? Are there any additional settings required for Let's Encrypt certificates to work with HiveMQ?

Your guidance would be greatly appreciated.

Thanks in advance!

2

You're doing what now?

Can you perhaps explain a little bit more about this unusual situation and probably more about this setup?

1 Like
3

For info this is the output I get from openssl, to me it looks like the [server] certificate is OK unless I'm missing something. I presume your system does not require a client certificate for authentication.

openssl s_client -connect 453f80f5df2941fcaf3697b7c1fd8848.s1.eu.hivemq.cloud:8883

CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R11
verify return:1
depth=0 CN = *.s1.eu.hivemq.cloud
verify return:1
---
Certificate chain
 0 s:CN = *.s1.eu.hivemq.cloud
   i:C = US, O = Let's Encrypt, CN = R11
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Feb 21 21:54:32 2025 GMT; NotAfter: May 22 21:54:31 2025 GMT
 1 s:C = US, O = Let's Encrypt, CN = R11
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFDDCCA/SgAwIBAgISBMta5F9baTiGGVMMyyIfyuJOMA0GCSqGSIb3DQEBCwUA
MDMxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQwwCgYDVQQD
EwNSMTEwHhcNMjUwMjIxMjE1NDMyWhcNMjUwNTIyMjE1NDMxWjAfMR0wGwYDVQQD
DBQqLnMxLmV1LmhpdmVtcS5jbG91ZDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAKVuz2sMPmxx2w/f81/YAEKTbNZMJPk2+ooLFg5hxXvReF+AwIT4XvZ+
MLhSKvFxmghJF+BB9WyhqrcJLGDCP4s6SOLWTYixEoTcaLUviqqn+06kYqDJ6E83
NGsc7T42DlPnzqcZZjPRed9rt4CP3RgeZlWyYZgiD8FoJG9gie8ytihF/FkGZT8T
N4Vkl2vQa3mfBWeeKrcuhcLPxqIWDz/30iYfLtEe5JYYScoCKTXcP9SUStjpR8pD
vfOWdvasOAuBy7yBbx01/4lcQt50hfbhTR/K14/D4rNkuuvU7ktSQnoxVXC8YDwG
zkny10DFt65mVYLNZcBQtOLHHOZGV30CAwEAAaOCAiwwggIoMA4GA1UdDwEB/wQE
AwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIw
ADAdBgNVHQ4EFgQUgsEjDU35+EWJKBsFxJ0lM0PXMi4wHwYDVR0jBBgwFoAUxc9G
pOr0w8B6bJXELbBeki8m47kwVwYIKwYBBQUHAQEESzBJMCIGCCsGAQUFBzABhhZo
dHRwOi8vcjExLm8ubGVuY3Iub3JnMCMGCCsGAQUFBzAChhdodHRwOi8vcjExLmku
bGVuY3Iub3JnLzAzBgNVHREELDAqghQqLnMxLmV1LmhpdmVtcS5jbG91ZIISczEu
ZXUuaGl2ZW1xLmNsb3VkMBMGA1UdIAQMMAowCAYGZ4EMAQIBMIIBBAYKKwYBBAHW
eQIEAgSB9QSB8gDwAHYAouMK5EXvva2bfjjtR2d3U9eCW4SU1yteGyzEuVCkR+cA
AAGVKrbguQAABAMARzBFAiAu8e2AhMVBQ20Ho/VdVn0O1hND8cahMS5LNp4i+d22
gAIhALfY7HqznFKIV/9pMFwir1M2dofh2iuXrNc2NT/G23uXAHYAzxFW7tUufK/z
h1vZaS6b6RpxZ0qwF+ysAdJbd87MOwgAAAGVKrbg+gAABAMARzBFAiEA5t4gaB9/
9ReLvpUAVUvdUHtNs1yCVNXGaFhwZcBnrxACIGjbFQ8HCCdkrXNVpsaOg9HC+LhI
XL6S09i9lgRnwUgLMA0GCSqGSIb3DQEBCwUAA4IBAQBNfUjHftHJ4ZUIIvR5SgyN
LbyvcJsR1DeM1QyzRy/lDaLaD58/nSghNTkdwTDZxkl6VsGslqL2wsEAT/6l31TF
1JaqlP531rEplNgZfwbhj+LlcKWPBi3KkN7hg90UXCWA5iR7uIs0ntgolkNB/1S2
aPAaWI226YEzf/tHhuOxsQwyPSSAOd47G0dIuayZycqDKnuaeORKJdnEckp93+Kr
3xixQoJD2m04l2tgKd9j/gTA9GGncMedJI96XlaQkv9O2+q/WZdPiRYS9GMwsqnz
E0rmnWfEB2gMwZ9xwFFJKAewSVjMkjvOWjEGnG9OcSkZIkqumUy88ooisl/mAQuA
-----END CERTIFICATE-----
subject=CN = *.s1.eu.hivemq.cloud
issuer=C = US, O = Let's Encrypt, CN = R11
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3069 bytes and written 446 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: FD744C245A2ECD926CCD0E560533A41B40EEB2C236AEE7DE041DB761FC047AFF
    Session-ID-ctx:
    Master-Key: D309083179B27B5B509D956C75B31E615EDCDF9C0BDD6DF0A507E8CC1566D2B69D57E2847E17A19DDDEB39F79780849F
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1742988422
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
---
closed
2 Likes
4

We are working on connecting a SIM7672G module to HiveMQ Cloud using MQTT over SSL/TLS. Since HiveMQ Cloud uses Let's Encrypt certificates, we are trying to configure our module to trust these certificates and establish a secure connection.

Setup Details:

  • We are using a SIM7672G module to connect to HiveMQ Cloud.
  • The connection is being established over port 8883 (secure MQTT).
  • We have uploaded the ISRG Root X1 certificate (which is the root certificate for Let's Encrypt).
  • We are not using client certificates, only the CA certificate for authentication.
  • The MQTT connection process is being performed using AT commands on the module.

Issue:

  • When attempting to connect, HiveMQ shows some connection activity, but the connection is rejected due to an "invalid certificate" error.
  • We are unsure if we are missing any additional configuration steps for Let's Encrypt to work properly with HiveMQ.

Could you provide any insights or guidance on what might be causing this issue?

Thanks!

5

Thanks for checking! Yes, from the OpenSSL output, it looks like the server certificate is valid, and no client certificate is required for authentication.

To clarify our setup:

  • We are using a SIM7672G module and sending AT commands via SimComSPT_3.5 to configure SSL and MQTT.
  • We have uploaded the ISRG Root X1 certificate (Let's Encrypt root CA).
  • We are NOT using a client certificate, only the CA certificate for server verification.

Here’s our command sequence:
AT+CCERTLIST
+CCERTLIST: "isrgrootx1.pem"

AT+CSSLCFG=authmode,0,1
OK

AT+CSSLCFG=cacert,0,isrgrootx1.pem
OK

AT+CMQTTSTART
OK
+CMQTTSTART: 0

AT+CMQTTACCQ=0,"TEST_USER32",1
OK

AT+CMQTTSSLCFG=0,0
OK

AT+CMQTTCONNECT=0,"453f80f5df2941fcaf3697b7c1fd8848.s1.eu.hivemq.cloud",8883,1,1,"test_user","Test1234"
ERROR

Despite the correct SSL setup, we still get an "ERROR" when trying to connect to HiveMQ Cloud over port 8883.

Possible Issues & Questions:

1.MQTT Credentials: The credentials are correct, but does HiveMQ require a specific username format (e.g., full email or an organization prefix)?

  1. CA Certificate Format: The isrgrootx1.pem file was uploaded correctly, but should it be converted to DER format instead of PEM?
6

We’ve been testing MQTT over TLS on the SIM7672G module with HiveMQ Cloud and ran into an issue with authmode=1 (strict certificate validation).

What Works (authmode=0 - No Cert Validation)

  • TLS encryption works
  • MQTT connection succeeds
  • Confirms PDP context, TCP, SNI, and TLS stack are functional

What Fails (authmode=1 - Strict Cert Validation)

  • Fails with +CMQTTCONNECT: 0,12 (SSL handshake error)
  • Possible causes:
    • Certificate chain is incomplete or mismatched

Troubleshooting Steps We’ve Taken

  1. Certificate Upload:
  • Downloaded ISRG Root X1 from Let’s Encrypt
  • Used AT+CCERTDOWN="isrgrootx1.pem",<exact_byte_size>
  • Unsure if a full chain is needed instead of just the root
  1. Checked HiveMQ Starter Plan
  • Found that authentication can be via client cert or username/password
  • We’re currently using username/password
  1. Possible Next Steps
  • Ensure SNI is enabled and broker domain matches certificate CN

Does anyone have experience successfully connecting the SIM7672G to HiveMQ Cloud with TLS and authmode=1?
Would love to hear any insights, especially regarding certificate handling and AT commands.

Thanks in advance!

7

I don't have anything of my own to add except have you tried posting at at the HiveMQ community forum?

You are more likely to find someone there with specific experience configuring that client. The volunteers here have a wide range of experience and maybe someone will offer ideas. I just think asking the HiveMQ experts directly is a good resource.

2 Likes
8

I already asked on the HiveMQ community forum, but no reply yet. Our team looked into it, and we’re pretty sure the problem is with the certificate itself.

9

Have you tried a connection to HiveMQ from something else? TLS connections require two things, a valid certificate on the server and a common set of Cipher suites supported by both the client and the server. The specific Cipher suite used also depends on your certificate private key type (RSA or EC), so for broader compatibility try an RSA key (certbot defaults to EC). Connecting to HiveMQ cluster via LTE module - #2 by Diego - HiveMQ Support Forum

[Edit: I assume you actually have no control over the certificate HiveMQ use and they are using RSA anyway, check you have required cipher suites enabled on your client (the Simcom module). Also refer to the SSL and HTTP application notes they provide in case there's something useful in there SIM7672X Series]

1 Like
10

The CN is no longer used in most TLS Clients. It was deprecated long ago.

But, taking the above comment literally ... the CN of the "leaf" cert is *.s1.eu.hivemq.cloud

See the openssl results from an earlier post

But, isn't the "broker domain" the fully qualified domain name? In which case it won't match the CN. Or, at least not by strict "equals".

Are you sure auth=1 should work for this connection?

Do you have a link for the docs for this client hardware / package?

3 Likes
11

I haven't had touched stuff like this in 15-20 years, but FWIW:

1- Unless HiveMQ has an onboarding guide for this platform as recommended hardware, the best resource is going to be SimCom

2- I quickly looked through the Command Manual for the hardware, they use .pem files in the examples so I doubt DER is needed

3- IMHO, you're going to drive yourself crazy trying to debug the connectivity and communication issues like this. What I've typically done when working on hardware projects that utilize cellular and radio networks is to clone the platform that I'm talking to as closely as possible.

I would set up your own server that mimics the HiveMQ server - you can generate your own ISRG SSSL cert that anchors to X1 with essentially the same chain (you can't control which intermediate is used), and only differs in domain names and keys - but uses the same key tech/size, and the server is configured to support the same ciphers, etc.

Your team can use something like SSL Server Test (Powered by Qualys SSL Labs) to determine their server config. Run that server in verbose debug mode and try to get your hardware to talk to it. That should help you quickly pinpoint where things are failing and why, giving you realtime feedback from both sides of the connection at the same time - instead of only having optics into one side of the connection as you do now.

3 Likes