Can't make the example server work with Chrome's example client

[Pascualex]

I'm trying to use your example server with Chrome's example client.

First, I had to change the ALPN used in the server to h3 to avoid the peer doesn't support any known protocol error, since WebTransport works over HTTP/3 and not pure QUIC.

After that I started facing problems with the TLS certificate, mainly a not very descriptive TLS handshake failure (ENCRYPTION_HANDSHAKE) 46: certificate unknown. Since then I have tried:

• Using both OpenSSL and rcgen to create the certificate.
• Passing the --origin-to-force-quic-on=localhost:4433 and --ignore-certificate-errors-spki-list=$certificate_fingerprint arguments to Chrome, as indicated in Chrome's example server.
• Adding the certificate as a trusted certificate in Chrome.
• A bunch of other flags and configurations which probably are not worth discussing.

Have you been able to use Quinn with a WebTransport client?

I've stumbled upon other libraries that seem to be implementing changes to support WebTransport and I want to be sure that Quinn has everything I need before I go even crazier trying to fix the problem.

[Ralith]

As far as I'm aware, you're the only person currently experimenting with WebTransport and Quinn. It is something that we expect to be feasible, though. However, there's a missing piece: because WebTransport is currently defined on top of HTTP/3, an HTTP/3 implementation is probably required. We don't have plans to maintain a HTTP/3 implementation inside Quinn. https://github.com/hyperium/h3/ is an HTTP/3 implementation effort that should be Quinn-compatible, but I'm not sure what its status is. It may be possible to instead implement a subset of HTTP/3 for WebTransport support alone; I think that would be best pursued as an external crate, though we'd be happy to work closely with such an effort to ensure Quinn doesn't make it harder than necessary.

That said, it sounds like your immediate problem is a Chrome certificate configuration issue. Unfortunately I have no idea what might be going on there, except that it probably has nothing to do with the QUIC implementation per se. Perhaps Chrome's usual certificate configuration stuff isn't being applied to their incomplete WebTransport implementation? My advice would be to attach a debugger and work out what their certificate verifier is checking.

[Pascualex]

That makes a lot of sense. I will check the h3 repo and see if I can make it work... but I suspect it might be a little bit to early to start experimenting with WebTransport.

Thank you for your help (again!).

[Pascualex]

Ok, I can now confirm that everything seems to be working from your side. The commands to obtain the fingerprint of the certificate gave me different results in Windows and Linux (being the ones in Linux the correct ones) and the TLS problem is now solved.

Right now the Quinn server seems to complete the handshake successfully but the client fails. This behavior is consistent with the fact that the client expects an extra HTTP/3 layer and the server doesn't.

[Ralith]

Thanks for the update!