> If the HTTP/3 implementations allowed self-signed certs

Is it forbidden at the protocol level or by the implementations?

It's an implementation limit that at least Chrome (and possibly other browsers) are enforcing for QUIC connections. The TLS certificate must be signed by a trusted CA. [1]

There does appear to be cli flags to change the behavior, but I don't see how you'd do that on mobile or embedded browsers.

[1]https://www.smashingmagazine.com/2021/09/http3-practical-dep...

You can add trusted CAs to your system though...

That is true. But an actual self-signed certificate is not signed by any CA, so it still can't be used with QUIC connections (with specific clients such as Chrome, anyway.)

RFC 9114 §3.1 ¶2 [0] requires TLS certificates, but I imagine you can easily modify existing implementations to remove this restriction. And even if the spec didn't require it I'd expect all major implementors (web browsers) to still impose this. I imagine something like curl has an opt-out for this (-k?).

Note that the spec essentially says "if verification fails don't trust this connection". What not trusting means is up to the application. For browsers that's probably equivalent to not allowing the connection at all.

[0] https://www.rfc-editor.org/rfc/rfc9114#section-3.1-2

HTTP/3 allows self-signed certs.

Chrome does not. But that choice is orthogonal to protocol.

I didn't know chrome didn't allow self-signed certificates. Since when?

The user can add self-signed certificates. Random websites using self-signed certificates won't work without that extra configuration from the user.

I'm pretty sure the old "thisisunsafe" trick will still work ...

> Chrome does not. But that choice is orthogonal to protocol.

Which means HTTP/3 de facto doesn't support self-signed certificates. Once Chrome disables HTTP 1.1/2 which it will at some point in the name of security or performance, you'll only be able to exist on the web with a CA signed certificate.

Yeah, it's difficult for me to always add the qualifer, "HTTP/3 allows self-signed certs but no implementation that exists in any browser allows self signed certs".

The original comment was opposition to HTTP/3 because of mandatory secure connections.

In reality, the opposition is misdirected; it is Chrome that requires secure connections, not HTTP/3.

Plenty of browsers allow self-signed certs—Firefox and Safari, to the best of my knowledge, treat HTTP/3 certs exactly the same as they treat HTTP/2 and HTTP/1.1 certs. Chrome has taken the position that it will no longer allow self-signed Root CAs for HTTP/3 websites, to prevent SSL interception with companies intercepting all of your traffic. For personal use, you can always whitelist an individual certificate using a CLI flag without allowing a trusted root CA

My testing in the past seems to indicate you're wrong. Firefox does not support setting up HTTP/3 connections without CA TLS. Unless they've changed it since version 115 esr. While the neqo lib they use for HTTP/3 does technically allow it unless you compile it yourself with all the flags required for it FF ships with neqo having CA TLS required and no support for self-signed certs when setting up HTTP/3 connections.

I'd love to be wrong or shown a newer version that does allow these things. It'd be a huge load off my mind.

For some reason I wasn't aware of that, but I agree with you.

There's no reason for to mandate TLS for everything just because of a protocol.

You can use self signed certs, you just have to add your CA as a trusted CA.

"A self-signed certificate is one that is not signed by a CA at all – neither private nor public. In this case, the certificate is signed with its own private key, instead of requesting it from a public or a private CA."

This definition sounds right to me. Do you disagree with it?

I get what you're saying, that you can set up a certificate yourself. But you can't accept a certificate someone else set up. (in Chrome)

That's definitely the wrong definition. A self-signed certificate is a certificate that is signed by the private key corresponding to the public key contained in that certificate - in other words it's signed by itself.

In fact every CA root are by necessity self-signed and therefore signed by a CA (i.e. itself)

I don't think they were talking about certificates that were also CAs. It's not wrong, it's insufficiently precise.

Anyway, your definition is clearer, but it still supports the point I was trying to make. You don't "add your CA" in order to use self-signed certs. You do that to use a private CA that will sign all your certs. And doing so only allows you to use websites you signed, not websites other people signed. It would be a terrible idea to add anyone else's CA, and you can't easily use your CA to slap your signature onto websites other people signed. Adding your own CA is a completely different situation from trying to visit a self-signed site.

If you need certs for local dev, use a local CA. Tools like mkcert automate this.

If you need certs if a private network, either use Let's Encrypt/ACME or run your own CA and add the CA cert to your machines.