devx for wt is rough...

[mac 💬]

the webtransport  chrome sample needs some love, why is it so oppressive to get chrome to connect to a localhost wt server?

why isnt the google wt server open?

if i can get time ill further 
```
# HTTP/3 always operates using TLS, meaning that running a WebTransport over
# HTTP/3 server requires a valid TLS certificate.  The easiest way to do this
# is to get a certificate from a real publicly trusted CA like
# <https://letsencrypt.org/>.
# https://developers.google.com/web/fundamentals/security/encrypt-in-transit/enable-https
# contains a detailed explanation of how to achieve that.
#
# As an alternative, Chromium can be instructed to trust a self-signed
# certificate using command-line flags.  Here are step-by-step instructions on
# how to do that:
#
#   1. Generate a certificate and a private key:
#         openssl req -newkey rsa:2048 -nodes -keyout certificate.key \
#                   -x509 -out certificate.pem -subj '/CN=Test Certificate' \
#                   -addext "subjectAltName = DNS:localhost"
#
#   2. Compute the fingerprint of the certificate:
#         openssl x509 -pubkey -noout -in certificate.pem |
#                   openssl rsa -pubin -outform der |
#                   openssl dgst -sha256 -binary | base64
#      The result should be a base64-encoded blob that looks like this:
#          "Gi/HIwdiMcPZo2KBjnstF5kQdLI5bPrYJ8i3Vi6Ybck="
#
#   3. Pass a flag to Chromium indicating what host and port should be allowed
#      to use the self-signed certificate.  For instance, if the host is
#      localhost, and the port is 4433, the flag would be:
#         --origin-to-force-quic-on=localhost:4433
#
#   4. Pass a flag to Chromium indicating which certificate needs to be trusted.
#      For the example above, that flag would be:
#         --ignore-certificate-errors-spki-list=Gi/HIwdiMcPZo2KBjnstF5kQdLI5bPrYJ8i3Vi6Ybck=
#
# See https://www.chromium.org/developers/how-tos/run-chromium-with-flags for
# details on how to run Chromium with flags.
```

[James Davidson]

Did you get something working? I can use https://wt-ord.akaleapi.net/echo/ in Safari, Firefox and Chrome (all on macOS) but can't for the life of me get any of those browsers to accept my localhost dev certificate (self signed) with our without serverCertificateHashes in place.

[Luke Curley]

Chrome does not support system root CAs for WebTransport. I don't know why; it's pretty frustrating that the same certificate works on localhost for HTTP but not for WebTransport. I use HTTP(S) to fetch serverCertificateHashes for local development. 

I wrote an entire blog post about WebTransport and TLS if you're interested: https://moq.dev/blog/tls-and-quic/

--
You received this message because you are subscribed to the Google Groups "web-transport-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-transport-...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/web-transport-dev/b326fb4e-134a-4d95-a653-b737ac8d63ecn%40chromium.org.

[guest271314]

I don't think you need the actual hash, if you use serverCertificateHashes in the WebTransport constructor. 

This code https://github.com/guest271314/webtransport-js-bundle works to generate a self-signed certificiate, insert the diget into client side JavaScript and HTML, and is used for the server, too, stored as JSON. 

Works in Chromium-based browsers and Firefox (windowed and headless), Node.js, Deno, and Bun. Basically, just run 

bun bundle-webtransport.js
or 

deno -A deno-bundle-webtransport.js

and go.

[Victor Vasiliev]

For what it's worth, the blogpost is incorrect on what WebTransport Developer Mode does:

> If the description is to be trusted, this would mean disabling certificate validation on every website (that uses WebTransport) which is just a horrific thought.

WebTransport Developer Mode removes the requirement of the certificate being chained to a known root.  It still has to be chained to some root CA that is actually trusted (either well-known or locally installed).

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/web-transport-dev/CAHVo%3DZ%3DiX%3DCwm7y33%2B4ZnctYrxX0pizpdqbjbBjvpfHeHZBGSw%40mail.gmail.com.

[mac 🔐]

why does wt function differently than it's siblings w/r/t trust ?

The fact that  someone in this thread cares enough to blog about it, _and is still wrong_ , then surely we've got a dx problem.

Was there some plan to do an ipfs style cert hash for the chromium wt ? e.g., https://github.com/ipfs/in-web-browsers/issues/190

Isn't it in cronet?   Why isn't the wt server open source? 

Not trying to pitchfork here but it's just frustrating the amount of work people at chromium put into that protocol so many years and ; and to seeit stuck with bad dx ....

://

[guest271314]

All you should need to do is generate your self-signed certificates and use the digest in the client in serverCertificateHashes. It's basically just an array. Generate certificate ever 13 days or so.

You don't even need --ignore-certificate-errors command line switch.

The last time I checked the GoogleChromeSamples WebTransport source code is here https://github.com/GoogleChrome/samples/tree/gh-pages/webtransport. Uses Python's aioquic library. Though you can use any WebTransport server library you want. I've used several, including that one when this thing was QuicTransport https://github.com/guest271314/quictransport, and after when it was switched to WebTransport https://github.com/guest271314/webtransport. The discrete QUIC and WebTransport library do not all behave the same. 

WebTransport is a moving target right now. At the specification level and at the individual library level. I would suggest continuing to try to test. I would not necessarily expect consistency among libraries, or even among browser clients or non-browser clients, or server implementations.

What specific issue are you having playing around with WebTransport locally?

[James Davidson]

> It still has to be chained to some root CA that is actually trusted (either well-known or locally installed).

Thanks Victor

[mac 🔐]

If I had a magic wand, chromium would have one server impl (no bidi), one client and a document that describes the way trust is established, with spec links.

I know its not always possible but even =>

""" 

We treat root of trust differently here vs  http because we were playing with post quantum root of trust stuff 

"""  

.. would improve devx as you don't feel like a complete idiot for not understanding

 ://