Unable to connect with self-signed certificate
Closed this issue · 16 comments
I'm trying to set up a client and server locally on my machine using a self-signed certificate generated with openssl. The server setup is copied from the readme, and the client initiation is rsp, conn, err := d.Dial(context.Background(), "https://localhost:443/webtransport", nil). The error I'm getting is "CRYPTO_ERROR 0x12a (local): tls: failed to verify certificate: x509: certificate signed by unknown authority" on the Dial call. Is there some other configuration I'm missing?
This is unrelated to WebTransport. You'll get exactly the same error when using crypto/tls over TCP with your certificate configuration.
Part of the reason I'm investigating WebTransport was because it was supposed to be able to support connections using self-signed certificates through the certhash: https://blog.libp2p.io/2022-12-19-libp2p-webtransport/#meet-webtransport
I'd also like to connect via QUIC, not TCP, and from the readme it should be opening a UDP port on 443. Is this not the case?
Part of the reason I'm investigating WebTransport was because it was supposed to be able to support connections using self-signed certificates through the certhash: https://blog.libp2p.io/2022-12-19-libp2p-webtransport/#meet-webtransport
There seems to be some severe confusion here. This applies to the browser API only.
This doesn't appear to be specified in the RFC, and none of the documentation makes mention that this is only a browser behavior. If non-browser clients are explicitly not supported, then can this at least be reflected in the documentation?
If non-browser clients are explicitly not supported, then can this at least be reflected in the documentation?
This is wrong again. Browsers are supported. We even have an explicit test for that in CI.
I encourage you to read the RFC and the W3C specification, and to familiarize yourself with crypto/tls.
I understand that much of the reference material discusses browsers as this is the primary targeted use case. I have not seen mention that non-browser clients are explicitly not supported though. I've reviewed these references in addition to the first link I posted:
https://www.w3.org/TR/webtransport/#certificate-hashes
https://github.com/libp2p/specs/tree/master/webtransport
https://datatracker.ietf.org/doc/draft-ietf-webtrans-http3/
The closest I've found that any come is this:
The most exciting feature for libp2p (other than the numerous performance benefits that QUIC gives us) is that the W3C added a browser API allowing browsers to establish connections to nodes with self-signed certificates
I get that it specified "browser API allowing browsers", but much of the documentation uses the terms browser and client interchangeably and prior to this conversation, I haven't seen anything differentiate between browser clients and non-browser clients. If that's the case, that's fine, and I'll look into other approaches, but could I at least propose adding a line to the readme stating that non-browser clients are not permitted to use self-signed certs?
This is wrong again. Browsers are supported.
I think there was some miscommunication here. I'm not saying browsers aren't supported, just that it was unclear this was a browser-only feature based on what I'd reviewed.
I understand that much of the reference material discusses browsers as this is the primary targeted use case. I have not seen mention that non-browser clients are explicitly not supported though.
You haven't seen this because this is not correct. As I said before, the behavior you're seeing is equivalent to what you'd see when using crypto/tls. WebTransport isn't doing anything special regarding certificate verification, it just uses the Go standard library crypto/tls package, giving you all the flexibility that comes with that. Please refer to the documentation of the standard library.
Specifically, if you want to accept self-signed certificates, you need to set InsecureSkipVerify to true, and implement certificate verification yourself. See the go-libp2p implementation for how to verify certificate hashes.
Is use of the certhash endpoint a browser-only feature or not? In this reply, you state "This applies to the browser API only." But now you're saying that my statement that non-browser clients are explicitly not supported to use the certhash endpoint is incorrect.
Non-browsers are free to implement whatever certificate validation logic they please.
But the library doesn't come with support for it and this is a conscious design choice correct? It has to be implmented on by users of the library.
Support for what?
Using the certhash endpoint as an alternate means of validating a certificate.
You're confusing the layers here. webtransport-go doesn't concern itself with certificate verification. It is simply an implementation of the IETF draft.
I see. I was mistaking links in the connectivity page. This appears to be what I was looking for. Apologies for the confusion.
No worries, I know it's a bit confusing having one IETF and one W3C WebTransport spec.