Question
Mongoose TLS hostname verification limits with an unset mg_tls_opts.name
Kavi Orbit
0 reputation · 24 Dec 2024, 03:02 UTC
112.1K views1
Loading…
0 reputation · 24 Dec 2024, 03:02 UTC
This question concerns Cesanta Mongoose, not the Node.js MongoDB ODM. In mg_tls_opts, the CA bundle (ca/ca_len) and expected peer name (name) appear to control separate parts of TLS validation: chain-of-trust verification and endpoint identity matching.
The unresolved issue is what an application should require when name is unset. Does a successful handshake then establish only that the peer chains to the configured CA, or does the selected TLS backend still enforce a hostname check? A CA-valid certificate issued for another host is the relevant boundary case.
Behavior may also vary across Mongoose releases and between mbedTLS and OpenSSL builds, including how an unset name is interpreted. No specific release is assumed here: field names, defaults, and backend behavior must be confirmed against the exact mongoose.h/mongoose.c pair and build configuration. A controlled comparison with a CA-signed certificate for a different hostname could distinguish backend behavior from configuration effects.
Is hostname matching mandatory whenever mg_tls_opts.name is empty, and is there a supported global setting that enforces it without weakening certificate validation?
35275 reputation · 24 Dec 2024, 04:29 UTC
No. For Cesanta Mongoose, an unset mg_tls_opts.name means the library does not send an expected peer name to the TLS stack. Certificate-chain validation and hostname identity matching are separate: if ca and ca_len are configured, Mongoose still verifies that the peer chains to that CA. Whether the peer certificate's CN or SAN is compared to a hostname depends on the TLS backend and build, not on a Mongoose global switch.
Mongoose separates trust from identity. ca and ca_len establish trust; name supplies the identity to check. With name unset, trust can succeed while identity matching is left to backend defaults.
mongoosename is set.name is empty or NULL, hostname matching is not mandatory in Mongoose itself; a CA-signed certificate for a different host may be accepted.mg_tls_opts.name to the expected host is the supported way to request identity matching.name empty.Behavior varies between mbedTLS and OpenSSL builds and across Mongoose releases; Mongoose 7.x may have changed defaults. Treat the exact handshake result as version-dependent until confirmed against your mongoose.h and mongoose.c pair and build configuration.
ca configured and name omitted or empty.name was unset.name set to the expected hostname. The connection should fail for the different-hostname certificate if matching is enforced.MG_ENABLE_DEBUG=1 and inspect handshake logs for peer-name comparison events.Do not rely on an unset name for server identity. Set mg_tls_opts.name to the expected hostname for every TLS client connection, keep CA validation enabled, and confirm the failure case with the different-hostname certificate. If your build still accepts the wrong certificate after setting name, share the Mongoose version and TLS backend for further review.
Use comments to ask for clarification. Post a solution as an answer.
6,210 reputation · 24 Dec 2024, 07:12 UTC
When mg_tls_opts.name is NULL, both mbedTLS and OpenSSL backends skip hostname verification entirely—the handshake succeeds if the certificate chain validates against the configured CA, even if the certificate's CN/SAN belongs to a different host. This is not a Mongoose-level policy; it reflects each backend's default when no hostname is provided to mbedtls_ssl_set_hostname or SSL_set1_host.
A practical way to confirm the behavior for your build is to run a handshake against a test server presenting a valid chain for host-a.example but a leaf certificate issued for host-b.example. If the connection succeeds, hostname verification is disabled for that backend/configuration.