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

The --insecure option on the included clients is not working #3232

Open
vatine opened this issue Mar 11, 2025 · 0 comments
Open

The --insecure option on the included clients is not working #3232

vatine opened this issue Mar 11, 2025 · 0 comments
Labels
Status: Available No one has claimed responsibility for resolving this issue.

Comments

@vatine
Copy link

vatine commented Mar 11, 2025

Just a bit of a preface why we want/need the --insecure option, so it's clear why this is necessary. We need to run mosquitto in a Kubernetes container and we have, as a policy, that all containers should have a liveness check. For hat purpose, we're using the "exec" type of liveness check and run mosquitto_sub to connect to "mqtts://127.0.0.1:2283/liveness_probe_subject" (we will not know the IP of the pod when we write the manifest and we do not want to check more than "Mosquitto responds").

The last version we know this worked on was 2.0.14 (it may have worked on later versions, I have not done the bisecting) and from some experimentation, where it seems to break somewhere in the "pre-verification" (the test setup uses a self-signed cert and CA, both expiring in 2027).

I have managed to get this to work in two ways, one is to move the preverify_ok check to after the code pulls the struct mosquitto *mosq out of the SSL context, then instead of returning 0, return mosq->tls_insecure.

The other is to remove the preverify_ok check and return 1 after the check (after all, insecure means "insecure", right?).

I am actually not sure if this has started failing due to a change in OpenSSL, or due to a change in the mosquitto codebase.

@github-actions github-actions bot added the Status: Available No one has claimed responsibility for resolving this issue. label Mar 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Available No one has claimed responsibility for resolving this issue.
Projects
None yet
Development

No branches or pull requests

1 participant