`client error (Connect): invalid peer certificate: Other(OtherError(NameConstraintViolation))` when using `rustls` backend

[9numbernine9]

Verification

• I searched for recent similar issues at https://github.com/rust-lang/rustup/issues?q=is%3Aissue+is%3Aopen%2Cclosed and found no duplicates.
• I am on the latest version of Rustup according to https://github.com/rust-lang/rustup/tags and am still able to reproduce my issue.

Problem

(This issue has been created at the request of @djc in this this comment)

Hello,

I've started running into an issue with rustup 1.28.0 + 1.28.1 since switching to the rustls backend. (Apologies for not noticing the CfT for testing sooner - I would have tried these changes in our environment sooner.)

For some context, I'm running rustup inside of a rather restrictive corporate environment and we have a mirror of Rust crates and toolchains (mirror created with Panamax) and we configure RUSTUP_DIST_SERVER and RUSTUP_UPDATE_ROOT to point to this mirror. Our crate/toolchain mirror is secured with a certificate issued from our own internal CA. When attempting to use rustup 1.28 with this mirror, I now see the error:

error sending request for url (https://rustmirror.ourcompany.com/dist/channel-rust-1.85.0.toml.sha256): client error (Connect): invalid peer certificate: Other(OtherError(NameConstraintViolation))

This CA hasn't caused any problems with rustup in the past and switching back an alternative backend (either by setting RUSTUP_USE_RUSTLS=0 or RUSTUP_USE_CURL=1 works perfectly fine. OpenSSL appears to verify the certificate used by the server correctly, and it seems to work fine with other TLS implementations as well (e.g. a dummy Golang or Java client that just tries to make an https connection works fine).

Our CA structure is something like this:

Root CA -> Issuing CA -> Server Cert (e.g. rustmirror.ourcompany.com)

The only name constraint that I can see is that our Root CA has a name constraint for C=CA so that all certs below the Root CA should have this constraint and I have verified that C=CA is part of the other certs in the chain. I will mention that I've now noticed that the leaf certificate has C=ca whereas the other certs in the chain are C=CA (note the case difference) - my understanding is that this shouldn't be problematic but I mention it for the sake of completeness.

If there's any other debugging steps that can be done on my side to provide more information I'm happy to try to do my best to help, but for now I'll be sticking with the Curl backend and would humbly request that it not be removed any time soon. 😅

Steps

1. Use rustup >= 1.28.0 to download a toolchain from our internal toolchain mirror or to update rustup itself.

Possible Solution(s)

No response

Notes

No response

Rustup version

rustup 1.28.1 (f9edccde0 2025-03-05)

Installed toolchains

stable-x86_64-unknown-linux-gnu (active, default)

OS version

Arch Linux via WSL2 (5.15.167.4-microsoft-standard-WSL2)

[djc]

Might be interesting to see if you can isolate this in a test binary directly using rustls-platform-verifier.

[ctz]

Might be interesting to see if you can isolate this in a test binary directly using rustls-platform-verifier.

(on a platform other than linux :) )

[djc]

Also if you can share the company root (or something close to it that exhibits the same behavior) that might be useful.

[djc]

(Likely to be related to https://github.com/rustls/webpki/blob/main/src/subject_name/mod.rs#L134-L151 / rustls/webpki#19.)

[9numbernine9]

@djc I spoke to some of our security people and they're not comfortable sharing the root or intermediate. I'll try to create a fake trust chain manually that shows the same behaviour if I can.

With that said, that code/issue you linked in your last comment sounds exactly like the behaviour I'm seeing! Thank you for poking around and trying to identify the source of this issue.