Revert verify_none and enable verify_peer again.
#433
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The reason Chrome (and some other browsers) cannot connect to the broker is as follows: 1. The OS (Windows 11) has a client certificate named **"Microsoft Your Phone"**. 2. This certificate was installed at some point, but it is harmless. 3. The connection is attempted from a local file (`file:///some/mqtt.html`) using MQTT.js to a WSS broker. 4. When the browser accesses the HTML page via **HTTPS**, a popup appears asking the user to choose a client certificate or not send one. * This happens because the server is configured with `verify_peer` (but not mandatory) and the OS has at least one client certificate installed. * The browser gives the choice to send a certificate or not. In this scenario, **not sending a certificate** is the correct choice. However, if the first access is directly via **wss\://** (not HTTPS), the choice popup cannot appear: * Browsers do not trigger the certificate selection dialog for JavaScript-initiated WSS connections. * As a result, the TLS handshake fails. If the user first accesses the page via **https\://**, the certificate selection popup appears, and subsequent **wss\://** connections succeed because the handshake can complete. Initially, this behavior seemed surprising to me. However, in typical use, **wss\://** connections originate from content already served via HTTPS on the same host. Since HTTPS access occurs before WSS, the user has the opportunity to choose a certificate (or not send one). In my test case, I accessed WSS directly from a local `file://`, which caused this issue.
redboltz
force-pushed
the
verify_peer
branch
from
980a8ab to
22a9505
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #433 +/- ##
==========================================
- Coverage 96.51% 96.46% -0.06%
==========================================
Files 182 182
Lines 10307 10313 +6
==========================================
Hits 9948 9948
- Misses 359 365 +6 🚀 New features to boost your workflow:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The reason Chrome (and some other browsers) cannot connect to the broker is as follows:
The OS (Windows 11) has a client certificate named "Microsoft Your Phone".
This certificate was installed at some point, but it is harmless.
The connection is attempted from a local file (
file:///some/mqtt.html) using MQTT.js to a WSS broker.When the browser accesses the HTML page via HTTPS, a popup appears asking the user to choose a client certificate or not send one.
verify_peer(but not mandatory) and the OS has at least one client certificate installed.However, if the first access is directly via wss:// (not HTTPS), the choice popup cannot appear:
If the user first accesses the page via https://, the certificate selection popup appears, and subsequent wss:// connections succeed because the handshake can complete.
Initially, this behavior seemed surprising to me.
However, in typical use, wss:// connections originate from content already served via HTTPS on the same host. Since HTTPS access occurs before WSS, the user has the opportunity to choose a certificate (or not send one).
In my test case, I accessed WSS directly from a local
file://, which caused this issue.