Knowing how to do that is quite a high barrier to entry.
Couldn't mkcert handle most of that process?
As far as I know, browsers don't allow self-signed certificates on HTTP/3. This was mentioned by people in comments here, and quick google seems to confirm.
Re:Why HTTP/3 is eating the world
by Majestic121 on Thursday October 05, 2023 @02:03PM
(#37781864)
You cannot use a certificate that was not signed by a trusted CA, but nothing keeps you from creating your own CA, making it trusted locally, and using it to sign your cert
Nothing except convenience and compatibility with dozens of operating systems that might operate on the network.
Can you even easily do it on Android? Without an Internet connection?
> making it trusted locally
That is precisely the problem. Most proprietary systems don't let you touch the trust store at all. Even "open" platforms like Android have been locking down the ability to do anything to the trust store.[1]
With that said, if we assume the user is only using Google Chrome and not an alternative browser, then typing "thisisunsafe" on the TLS error page should let one elide trust store modifications entirely. I cannot guarantee this is the case for HTTP/3 since the reverse proxies I deal with still use HTTP/2.
[1] https://httptoolkit.com/blog/android-14-breaks-system-certif...
Re:Why HTTP/3 is eating the world
by throwaway892238 on Thursday October 05, 2023 @07:57PM
(#37785728)
One might then ask: why not just let the user click a button in the browser to see the page, without jumping through all those hoops? How does increased human toil make it better? (Spoiler: it doesn't)
Or is there something else that prevents you from hosting HTTP/3 locally?