Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setting up mqtts port on verneMQ #337

Open
juliays opened this issue Dec 14, 2022 · 8 comments
Open

Setting up mqtts port on verneMQ #337

juliays opened this issue Dec 14, 2022 · 8 comments

Comments

@juliays
Copy link

juliays commented Dec 14, 2022

I followed the instructions in README.MD to set up mqtts port. However, it does not work. For whatever reason, k8s does not seem to recognize the secret created corrected and the pod never started properly.

I was able to create a secret using "kubectl create secret --from-file=ca.crt.pem --from-file=tls.crt.pem --from-file=tls.key.pem" and follow the mount and env variable set up in README.MD to start the verneMQ server. However, I'm not able to connec to it when using mosquitto_pub to test passing in the --cafile option.

I don't know if anyone set up the TLS/ssl access correctly? Could you update the README.MD or share some thoughts in this issue comment? Thanks!

Does .pem files work? Or do I need the .crt and .key files for CA and intermediate certs? I tried with self gen certs as well as existing certs, neither worked and all exhibit the same behavior when running the two tests below. Thanks for your input.


mosquitto_pub -h <hostIP> -t test -m ‘test’ --cafile ca.crt -i testClient -d 
Client testClient sending CONNECT
Error: Protocol error

I tried using " openssl s_client -connect :8883 -key tls.key.pem -cert tls.cert.pem", got back the info below.

CONNECTED(00000003)
write:errno=54
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 287 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Start Time: 1670975815
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
@ioolkos
Copy link
Contributor

ioolkos commented Dec 14, 2022

@juliays my ideas: try adding --insecure option to the mosquitto_pub command to see whether it's related to server hostname verification. I'd also try to enforce TLS version 1.2 to see whether there's a difference.

There could be an issue with the CA file too, like a missing intermediate certificate or wrong order. (all those files are PEM encoded, I think)


👉 Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
👉 Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.

@juliays
Copy link
Author

juliays commented Dec 14, 2022

I tried the two options and same "Protocol error" message.


mosquitto_pub -h <hostIP> -t test -m ‘test’ --cafile ca.cert.pem -d -i testClient --insecure --tls-version tlsv1.2  
Client testClient sending CONNECT
Error: Protocol error

Doe verneMQ support self generated certs? Does it support aes-256-cbc cipher for keys? I was looking at the cipher suite and I couldn't tell.

The ca file I used to set up the mqtts, is it required to be a chained cert? How about the cert I used in mosquitto_pub? Does it need to be a chained cert? Is there an order requirement? What order does the chain need to be in?

@juliays
Copy link
Author

juliays commented Dec 14, 2022

Another question is what's the right way to set up secrets representing the certs and keys? Following the instructions in Readme.md, I was not able to start vernemq broker. I used "kubectl create secret generic --from-file=ca.crt --from-file=tls.crt --from-file=tls.key" and I was able to follow the rest of the doc to set up and start verneMQ. But client wasn't able to connect. I also looked into "kubectl create secret tls --cert tls.cert --key tls.key" and created two secrets and added them to secretMounts. Neither worked. Same results. Please advise. Thanks!

@ioolkos
Copy link
Contributor

ioolkos commented Dec 15, 2022

Maybe this issue helps?
#332


👉 Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
👉 Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.

@juliays
Copy link
Author

juliays commented Dec 15, 2022

Thank you. I went over that item. It does not really apply here. We are not using acme server to generate cert. We just want to use our intermediate cert to validate client devices and expose our endpoint with TLS.

@ioolkos
Copy link
Contributor

ioolkos commented Dec 19, 2022

In general, the CAfile has to contain intermediate certs if those are part of the CA chaing.
You might also have to adapt the listener.ssl.my_listener.depth setting (adapt to your listener name).


👉 Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
👉 Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.

@ioolkos
Copy link
Contributor

ioolkos commented Dec 20, 2022

Note to self: check what the chain depth default is if it's not set. It might be unnecessary friction if too low.


👉 Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
👉 Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.

@ioolkos
Copy link
Contributor

ioolkos commented Feb 27, 2023

Note #349 (comment)


👉 Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
👉 Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants