Self-signed certificate rejected with WebPKIError(CAUsedAsEndEntity)

[elf-bot]

Hello,
I'm trying to connect to a gRPC server that provides a self-signed certificate.
However I'm getting the following error WebPKIError(CAUsedAsEndEntity).
If I understand correctly WebPKI wants the CA to issue an end entity certificate instead of using just the self-signed CA cert itself.
Unfortunately I don't control the server software that generates the certificate, so I was wondering if there is a way to allow a self-signed CA cert to be used as an End Entity cert?

webpki/src/verify_cert.rs

Line 234 in 0573c1e

(UsedAsCA::No, true, _) => Err(Error::CAUsedAsEndEntity),

(fwiw removing this line passes the validation of the cert and the connection happens on rustls tlsclient example)

Here is an example of the certificate used in case it helps:
Thank you

-----BEGIN CERTIFICATE-----
MIICcTCCAhagAwIBAgIQDojMgC+HAukHYJZqAr1SpTAKBggqhkjOPQQDAjAwMR8w
HQYDVQQKExZsbmQgYXV0b2dlbmVyYXRlZCBjZXJ0MQ0wCwYDVQQDEwRkaXZhMB4X
DTIwMDEwNzEzMTcxNloXDTIxMDMwMzEzMTcxNlowMDEfMB0GA1UEChMWbG5kIGF1
dG9nZW5lcmF0ZWQgY2VydDENMAsGA1UEAxMEZGl2YTBZMBMGByqGSM49AgEGCCqG
SM49AwEHA0IABEp6UaeVXTezbuWdAxl9Bs3EAZIVjdrpBm1/ejz4tCy5exvLUl53
7xATtOHM0Ge1mQ2FqtckSBgGlh4n1EW7cvKjggEQMIIBDDAOBgNVHQ8BAf8EBAMC
AqQwDwYDVR0TAQH/BAUwAwEB/zCB6AYDVR0RBIHgMIHdggRkaXZhgglsb2NhbGhv
c3SCBHVuaXiCCnVuaXhwYWNrZXSHBH8AAAGHEAAAAAAAAAAAAAAAAAAAAAGHBMCo
AcOHBKwTAAGHBKwSAAGHBKwRAAGHBAqTFLWHBKwUAAGHEP3yBa9KDwAATsxq//6w
HRWHEP6AAAAAAAAATsxq//6wHRWHEP6AAAAAAAAAAEKD//7cLCmHEP6AAAAAAAAA
WAe7//7DpFuHEP6AAAAAAAAAAEIt//7LJ5KHEP6AAAAAAAAAWAXw//6dcH6HEP6A
AAAAAAAAQJm2//44NHwwCgYIKoZIzj0EAwIDSQAwRgIhAKsgfl5XCcFUF9SUKsZw
eHQX0p/gIn79PdzilaX7uodzAiEAivOYSZcPz7BtqHD+MIP2NopFL84b3yK+T/a+
ZueR0PE=
-----END CERTIFICATE-----

[briansmith]

Imagine we had a flag on each trust anchor indicating whether it was supposed to be a normal CA certificate or a self-signed end-entity certificate. Then on any such trust anchors, we could skip this check. I would be happy to review a PR that adds such a mechanism with appropriate tests.

[jbg]

I sent a PR (#127) adding support for self-signed certificates using the mechanism proposed by @briansmith

[jbg]

@briansmith Have you got any feedback, or is there anything I can do to help #127 get merged?

[Stargateur]

wow I blocked here, what the hell, I just want a TLS tunnel with full self signed certificate... I really need to make a root and sign it for nothing ?

[briansmith]

One of the original ideas I had for webpki was to support self-signed certificates as described above. The idea was implement roughly what web browsers do with respect to "certificate error exceptions." However, given all the other things that need to be done, I think we have to be realistic about the prioritization of this feature. In particular, I think we should first focus on correctly implementing and verifying the correctness of the real, correct (web) PKI semantics, and de-prioritize other things. So, I'm just going to close this. Once we're past 1.0 we might reconsider.

[briansmith]

Also, as far as I know, most users of this webpki crate are using it through Rustls. If you look in the Rustls issue tracker, you can see a relatively recent discussion about making it possible to implement alternate certificate validation that doesn't depend on webpki, and such an alternative mechanism was implemented in Rustls. So now you can use Rustls and plug in your own certificate processing to get the semantics you need.

[casey]

We're running into this with self-signed certificates generated by LND that are accepted by OpenSSL, but not rustls/webpki. We don't have an in-depth understanding of the relevant specs, and don't fully understand why exactly webpki rejects the certificates.

We'd like to understand the situation better so we can make LND generate certificates that work with both rustls and OpenSSL. Is the cause of the different behavior of webpki and OpenSSL that OpenSSL will accept a self-signed end-entity certificate to be added as a root certificate, which makes it trust servers that present that certificate, but this isn't spec-complaint, so webpki doesn't do this?

[casey]

I created an issue in the lnd repo, and they mentioned that they had run into similar problems in the past, which they had fixed by adding the Extended Key Usage value serverAuth to the certificate. Is this a spec-complient way of getting this to work, or is it OpenSSL-specific?

[jbg]

@casey using webpki with LND was the original motivation for the PR I made which is linked above. It was never merged.

LND's self-signed certs are not invalid in any way according to any spec that I'm aware of. webpki just doesn't support trusting self signed certs.

You can apply the linked patch to webpki, or you can replace LND's certs with certs from a CA (and add that CA as a root for webpki if it's not an existing trusted one). The latter approach is what I ended up doing since I don't want to maintain a fork of webpki.

You can also bypass webpki. For example, if using rustls, set your own certificate verifier.

[casey]

@jbg Ahhh, I see. Thank you for clarifying!

[Kixunil]

LOL, I had the same problem also with lnd and I managed to figure it out. I have published my own lnd client library based on tonic.

Not sure if just bytewise comparing of the certificate is good idea but at least I don't see any way it could be insecure. If anyone has pointers I'd appreciate any advice.

[briansmith]

This issue was closed 6 months ago. I locked the conversation here to avoid distracting people. I am open to making webpki more flexible but doing things that are just flat-out wrong and dangerous is out of scope of this project, so I'd rather not discuss such solutions here. I know this sounds harsh; not trying to be. I just want to keep discussion here focused on implementing correct certificate validation. I hope you understand.