Pardon my knowledge. If we are to get very technical instead of for average people, surely you can self-sign a cert and setup your CA chain on the computers in your local network?

Or is there something else that prevents you from hosting HTTP/3 locally?

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.

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...

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)

Impossible because you'd need a server certificate? But you can issue it yourself and add a trust anchor to your browsers.

Look for routers that run an ssh server or have a serial console I guess.

Just use a proper browser

> If HTTP/1.1 is deprecated from all browsers

If HTTP/1.1, HTTP/2, and HTTP/3 is deprecated from all browsers the World Wide Web would shut down.

WWW is in danger! /s

Routers today are already dealing with this problem because Chrome throws major security warnings for any unencrypted HTTP traffic. The current solutions I've seen are to use things like Let's Encrypt/ACME certificates for wildcard sub-domains *.routercompanylocal.tld and a bit of secure handshake magic to register temporary A/AAAA records for link-local IP addresses (DNS has no problem advertising link-local addresses) and pass the private parts of the certificate down to the local hardware. Several major consumer routers I've seen will auto-route users to something like https://some-guid.theircompanyrouterlocal.tld and everything just works including a CA chain usually up to Let's Encrypt.

Doing Let's Encrypt/ACME for random localnet web pages is getting easier all the time and anyone can use that wildcard domain loophole if they want to build their own secure bootstrap protocols for localnet. It would be great if the ACME protocol more directly supported it than through the wildcard domain name loopholes currently in use, and that may come with time/demand. I imagine there are a lot of hard security questions that would need to be answered before a generally available "localnet ACME" could be devised (obviously every router manufacturer is currently keeping their secure handshakes proprietary because they can't afford to leak those certificates to would be MITM attacks), but I'm sure a lot of smart minds exist to build it given enough time and priority.

for routers there's a simple and easy workaround. Let's say your router answers on "router.lan". All they would have to do is redirect this name via the router's DNS resolver to, say, 192-168-0-1.company.com, which would be an officially-registered domain that resolves back to ... wait for it... 192.168.0.1!

If you control company.com you can run wildcard DNS for any amount of "private" IP addresses, complete with an official and valid trusted certificate. For an internal IP address. Problem solved.

(and no, this is not theoretical, there were appliances some 10+ years ago that did exactly that...)

Yeah, that is mostly what I was describing. There's some rough security benefit to using more transient A/AAAA records under a GUID or other pseudo-random DNS name than a DNS zone that just encodes common link local addresses. There are definite security benefits to a company using mycompanyrouters.com instead of their home company.com (XSS scripting attacks and the like). So some things have changed over 10+ years, but yes the basic principles at this point are pretty old and certainly working in practice.

Google actually makes a router?