fix(mqtt): allow TLS without a custom CA certificate - #23997
Conversation
tls_set() was only called when tls_ca_certs was set, so a broker whose certificate is signed by a public CA could not be used over TLS without pointing tls_ca_certs at the system trust store by hand. paho falls back to the system certificates when ca_certs is None, so any tls_ option now enables TLS and tls_ca_certs is passed through unchanged. tls_insecure_set() also ran outside that branch, and paho raises ValueError when no SSL context has been configured yet, so a config with tls_insecure but no tls_ca_certs failed to start. It now runs inside the TLS branch, after tls_set() has built the context.
|
| Filename | Overview |
|---|---|
| frigate/comms/mqtt.py | Reworks TLS initialization correctly for public CAs, but accepts partial client-credential configurations and silently omits the supplied credential. |
| frigate/test/test_mqtt_tls.py | Covers the principal TLS activation cases but does not exercise unpaired client certificate and key values. |
| docs/docs/configuration/advanced/reference.md | Clarifies that a custom CA is optional and that other TLS options enable TLS. |
Reviews (1): Last reviewed commit: "fix(mqtt): allow TLS without a custom CA..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| or self.mqtt_config.tls_client_cert is not None | ||
| or self.mqtt_config.tls_insecure is not None |
There was a problem hiding this comment.
If a configuration supplies only tls_client_cert or tls_client_key, the config model accepts it but this TLS setup silently omits the credential, causing brokers that require mutual TLS to reject the connection without a clear configuration error.
1 participant
Proposed change
Frigate only calls paho's
tls_set()whentls_ca_certsis set, so there is no way to talk to a broker over TLS when the broker certificate is signed by a public CA such as Let's Encrypt. The workaround people have landed on in #2471 is to pointtls_ca_certsat/etc/ssl/certs/ca-certificates.crt, which is just the system trust store paho would have used on its own. paho'stls_set()falls back toload_default_certs()whenca_certsis None, so this change enables TLS when any of thetls_options is set and passestls_ca_certsstraight through. Leaving it unset now means "use the system certificates" instead of "do not use TLS at all".The same block had a second problem.
tls_insecure_set()was called outside thetls_ca_certscheck, and paho raisesValueError: Must configure SSL context before using tls_insecure_set.when no SSL context exists yet. That means a config withtls_insecurebut notls_ca_certsthrew out of the dispatcher setup and Frigate did not start. That call now sits inside the TLS branch, aftertls_set()has built the context.tls_set()already callstls_insecure_set(False)itself, so keeping the explicit call after it is still correct for anyone who wantstls_insecure: true.No new config option, and no schema or UI change. I added
frigate/test/test_mqtt_tls.pycovering the four cases (no TLS options, CA only, client certs without a CA, andtls_insecureon its own), and updated the comments fortls_ca_certsin the config reference so it reads as optional and only needed for a private CA.Type of change
Additional information
For new features
Not a new feature, this is a bugfix, so there is nothing to link here.
AI disclosure
AI tool(s) used (e.g., Claude, Copilot, ChatGPT, Cursor): Claude Code
How AI was used (e.g., code generation, code review, debugging, documentation): code generation for the rewritten TLS block, the new test module, and the doc comment wording.
Extent of AI involvement (e.g., generated entire implementation, assisted with specific functions, suggested fixes): it wrote the change to
_start()and the test file from the approach I described, which is about a dozen lines of source plus the tests.Human oversight: I read through paho's
client.pymyself to confirm thattls_set(None)callsload_default_certs()and thattls_insecure_set()raises when_ssl_contextis None, which is what the fix relies on. I went over the diff line by line, ran the new tests against the old code to check they actually fail (thetls_insecureone raises the ValueError, the client cert one showstls_setnever being called) and against the new code to check they pass, and ranruff format --checkandruff check. I could not run the whole suite locally since most of it needs dependencies that will not install on my machine, so I only ran the two MQTT test modules.Checklist
enlocale.ruff format frigate)