4 ms·
> If the HTTP/3 implementations allowed self-signed certs Is it forbidden at the protocol level or by the implementations?
by afiori 3y ago
> If the HTTP/3 implementations allowed self-signed certs
Is it forbidden at the protocol level or by the implementations?
- treesknees 3y agoIt'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-deployment-options-part3/ https://www.smashingmagazine.com/2021/09/http3-practical-dep...
- remram 3y agoYou can add trusted CAs to your system though...
- treesknees 3y agoThat 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.)
- tambre 3y agoRFC 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 https://www.rfc-editor.org/rfc/rfc9114#section-3.1-2