bug: The CN name of the certificate does not match the value transmitted.

[ISensuiI]

Description

When using iroh 0.90.0 and a custom relay server on a Windows system, HTTPS detection consistently fails with a certificate verification error. The error is caused by RelayUrl automatically adding a dot to the end of the domain name (generating an FQDN like relay-node1.example.com), but standard TLS certificates only include domains without a trailing dot (e.g., relay-node1.example.com).

Using iroh alone works fine, but my application requires iroh + rust_socketio. Rust_socketio uses native TLS, and I'm unsure if this is a problem with rust_socketio or iroh. I tried forking rust_socketio and adjusting dependencies, but it failed, and I encountered many stack overflow issues that I haven't resolved yet.

Using the iroh example listen example alone, or removing rust_socketio, works perfectly. The problem is that I need both libraries to work together. I don't know how to solve this right now. I'm only testing on Windows 11; the situation on Linux is unknown.

Or is there a better solution?

Error Message

reqwest::Error {
kind: Request,

url: "https://relay-node1.example.com./ping",

source: hyper_util::client::legacy::Error(

Connect,

Os {

code: -2146762481,

kind: Uncategorized,

message: "Certificate CN The name does not match the transmitted value.

}

)
} Windows error code -2146762481 corresponds to the CERT_E_CN_NO_MATCH error for Schannel.

Root Cause

FQDN Design: RelayUrl::from() automatically adds a dot to the end of the domain name to create a fully qualified domain name (FQDN) (relay_url.rs:24-38).

Certificate Mismatch: Standard TLS certificates (such as Let's Encrypt and commercial CAs) do not include a trailing dot in the CN or SAN fields because this is not standard practice.

Strict Validation: When reqwest uses a native-tls backend on Windows, it relies on Schannel, and Schannel does not canonicalize trailing dots when performing strict hostname matching.

Impact

I primarily develop using Windows. Currently, the impact is that whenever this certificate error occurs, the connection to the relay becomes unstable, with a success rate of around 30%. If Rust SocketIO is removed, the certificate error disappears, and the success rate becomes almost 95% or even higher.

[flub]

This is arguably a bug in OpenSSL which fails to validate a certificate when the full name up to the root anchor is used. We've seen this behaviour before. RustLS does not have this bug which is why iroh makes sure to always use the RustLS backend.

[ISensuiI]

Are there any good solutions? I tried forking and modifying rust_socketio, but my skills and time are limited, and I can't solve it quickly.

I tried cargo patching, but rust_socketio is directly inlined, so it can't be fixed by patching.

I also considered adding the domains www.a.com and www.a.com. to the certificate.

If all else fails, I'll have to slowly fork and fix the rust socketio dependencies, but that's very tedious because it takes a lot of time to fix a basic library.

[Frando]

We have a PR that uses the relay URL without a final dot in more places: #3487
But we deemed it too complex and instead made sure that we always and unconditionally use rustls, which removes a final dot from a domain before validitating the certificate's server name.

[flub]

The weird thing we do is the unconditional appending of the final dot to custom relay URLs. It was always an odd choice, but seemed to make sense at the time. While I think our default RelayURLs should end in a dot, not giving the user the option to not do so is perhaps a bit unusual.

[flub]

Which is to say that I would consider a PR that changes that behaviour :)

[ISensuiI]

Thank you very much for the answer. For now, I'll have to fix the rust_socketio library myself, trying to remove the dependency and fix the overflow error.

I also think there should at least be an option provided, and frankly, I don't understand why this needs to be added at the end of .com.