platform-verifier cannot verify iroh's own default relays on Windows (trailing-dot hostnames)

[yukimemi]

Summary

On Windows, enabling the platform-verifier feature and building an
endpoint with CaTlsConfig::system() makes every default relay fail
TLS with NotValidForName — including relays that verify fine with the
default embedded roots.

The cause is that iroh's default relay hostnames are absolute FQDNs, with
the root label's trailing dot (iroh-1.0.3/src/defaults.rs:27):

pub const NA_EAST_RELAY_HOSTNAME: &str = "use1-1.relay.n0.iroh.link.";

rustls-platform-verifier passes that name to CryptoAPI verbatim, which
compares aps1-1.relay.n0.iroh.link. against the certificate's dot-less
SAN and returns CERT_E_INVALID_NAME. webpki drops the root label during
name matching and never sees a problem.

I filed the underlying bug as
rustls/rustls-platform-verifier#240 — it reproduces with plain
example.com. and no iroh involved. Opening this separately because the
combination is what makes the feature unusable in practice, and iroh is
where the two halves meet.

Repro

let endpoint = Endpoint::builder(iroh::endpoint::presets::N0)
    .ca_tls_config(CaTlsConfig::system())
    .alpns(vec![b"my/alpn/1".to_vec()])
    .bind()
    .await?;

with iroh = { version = "1.0.3", features = ["platform-verifier"] }, on
Windows:

ERROR endpoint:actor:reportgen-actor:run-probe{proto=Https relay=https://aps1-1.relay.n0.iroh.link./}:
  failed to verify TLS certificate: invalid peer certificate: NotValidForName
 WARN endpoint:actor:reportgen-actor:run-probe{proto=Https relay=https://aps1-1.relay.n0.iroh.link./}:
  probe failed: Failed to run HTTPS probe: HTTP request failed:
  error sending request for url (https://aps1-1.relay.n0.iroh.link./ping):
  client error (Connect): invalid peer certificate: NotValidForName

Every region, on a loop. Dropping back to the default
CaTlsConfig::embedded() makes the same relays connect immediately, so
it is not the certificates and not the network.

Why this matters more than the feature being niche

platform-verifier is exactly what a machine behind a TLS-inspecting
proxy (Cato SASE, Zscaler, any corporate MITM appliance) needs: the
interception CA is in the OS store, and webpki-roots reads neither
SSL_CERT_FILE nor SSL_CERT_DIR, so there is no way to widen trust
from outside a shipped binary. Those users are on Windows more often than
not, and Windows is where the feature does not work.

CaTlsConfig is otherwise well-shaped for this — the escape hatch below
only exists because with_extra_roots is there.

Workaround, for anyone who finds this

Take the roots from the OS but leave the name matching to webpki:

let found = rustls_native_certs::load_native_certs();
let ca = CaTlsConfig::embedded().with_extra_roots(found.certs);

rustls-native-certs reads the same stores platform-verifier would
(CryptoAPI on Windows, Keychain on macOS, the OS bundle on Linux), and
honours SSL_CERT_FILE / SSL_CERT_DIR as a bonus. Keeping embedded()
underneath rather than custom_roots also means a host with no CA bundle
at all still binds instead of failing at bind() with
InvalidCaRootConfig.

Possible fixes on this side

Whichever you prefer, and none of them are urgent if the upstream fix
lands:

1. Nothing here — wait for rustls-platform-verifier to strip the root
   label, then bump.
2. Normalise the server name where the relay URL becomes a ServerName,
   so the trailing dot never reaches the verifier.
3. Document on CaTlsConfig::system() that it is currently incompatible
   with the default relay map on Windows. Right now the feature reads as
   the supported answer for this problem, and following it makes things
   worse than doing nothing.

Environment

• Windows 11 Pro 26200
• iroh 1.0.3, rustls-platform-verifier 0.7.0
• Reproduced against the default presets::N0 relay map

[matheus23]

Seems like they merged a fix for this. We'll probably wait for it to be released, the workaround seems fine in the mean time?

[yukimemi]

Thanks for the update. Checked upstream: rustls-platform-verifier#240 is merged but nothing has been released yet (latest is still 0.7.0, the fix is not in a crate). The with_extra_roots workaround has been running fine here, so happy to wait — I will close this once the fix ships, unless iroh decides to normalise the server name first.