InvalidCertificate(Other(OtherError(UnsupportedCriticalExtension))) error with `rustls@0.23.11`

[hanabi1224]

Summary

Steps to reproduce

1. cargo update rustls@0.23.11
2. cargo run -p chat-example

Expected behavior

No panic

Actual behavior

thread 'main' panicked at transports/tls/src/lib.rs:80:10: Server cert key DER is valid; qed: InvalidCertificate(Other(OtherError(UnsupportedCriticalExtension)))

Relevant log output

thread 'main' panicked at transports/tls/src/lib.rs:80:10:
Server cert key DER is valid; qed: InvalidCertificate(Other(OtherError(UnsupportedCriticalExtension)))

Possible Solution

No response

Version

master @ 4e4b594

Would you like to work on fixing this bug ?

Maybe

[romac]

I am seeing the same error with rustls 0.23.11 and rustls-webpki 0.102.5:

$ cargo update rustls@0.23.9
    Updating crates.io index
     Locking 2 packages to latest compatible versions
    Updating rustls v0.23.9 -> v0.23.11
    Updating rustls-webpki v0.102.4 -> v0.102.5
$ cargo run -p chat-example
thread 'main' panicked at transports/tls/src/lib.rs:80:10:
Server cert key DER is valid; qed: InvalidCertificate(Other(OtherError(UnsupportedCriticalExtension)))
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Pinning rustls-webpki to 0.102.4 and rustls to 0.23.10 to allow for the former seems to alleviate the issue:

$ cargo update -p rustls@0.23.11 --precise 0.23.10
$ cargo update -p rustls-webpki@0.102.5 --precise 0.102.4
$ cargo run -p chat-example
Enter messages via STDIN and they will be sent to connected peers using Gossipsub
Local node is listening on /ip4/127.0.0.1/tcp/60573
Local node is listening on /ip4/192.168.1.41/tcp/60573
Local node is listening on /ip4/127.0.0.1/udp/55953/quic-v1
Local node is listening on /ip4/192.168.1.41/udp/55953/quic-v1

[dariusc93]

Getting the same issue here too (quic was triggering it but pretty sure libp2p-tls transport would also trigger it too). Might be an issue upstream though unless the new update is exposing something that is a bug for us?

EDIT: We could probably pin the previous version temporarily until it is worked out. Thoughts on this @jxs?

[jxs]

Hi, and thanks for reporting, I'd say no need to pin as this is will probably be addressed in the next couple hours, and each one can just follow https://github.com/libp2p/rust-libp2p/issues/5487#issuecomment-2216845050 but I am open to counter arguments ofc

[Firaenix]

Just got hit by this too, https://github.com/libp2p/rust-libp2p/issues/5487#issuecomment-2216845050 alleviated the issue for now

[jxs]

meanwhile I could not find an issue opened upstream, @dariusc93 have you?

[dariusc93]

meanwhile I could not find an issue opened upstream, @dariusc93 have you?

I have over on rust-ipfs after the lock file got updated. Disabling quic and tls was a workaround but after reverting the deps there it started working fine. I havent tried it on rust-libp2p yet but i would assume it would be affected if tls and/or quic used too.

[cargodog]

FYI, this issue is still present and no upstream issue has been reported that I can find.

Has anyone here dug in to determine if this is a bug in rustls or if this is a case of an accidental breaking change in rustls 0.23.11 which causes a break just in rust-libp2p?