FIX: rustls rejects self-signed certificate: CA cert used as leaf (CaUsedAsEndEntity)

[Kshitij-K-Singh]

Problem

The self-signed certificate generated by this plugin cannot be used with clients that use rustls (e.g. Rust clients using reqwest with rustls-tls-native-roots).

Error: InvalidCertificate(CaUsedAsEndEntity)

Root Cause

In src/main.ts, the certificate is generated with basicConstraints.cA: true:

certificate.setExtensions([{
  name: "basicConstraints",
  cA: true,  // Makes this a CA certificate
  critical: true,
}, ...]);

But this same certificate is then served directly as the leaf/end-entity certificate by the HTTPS server. Per X.509 standards, a CA certificate must not be used as a leaf certificate. OpenSSL is lenient about this, but rustls/webpki correctly rejects it.

Suggested Fix

Generate two certificates instead of one:

1. CA certificate (cA: true, keyCertSign: true) - stored internally, used only to sign the leaf cert
2. Leaf/end-entity certificate (cA: false, keyCertSign: false, serverAuth: true) - served to clients via the HTTPS server

The CA cert would still be downloadable for clients that need to trust it.
This is the same approach LND took to fix the identical issue.

Impact

This affects all Rust-based clients using reqwest with rustls, which is the default TLS backend.

Should i make a PR or ISSUE about this ?

[coddingtonbear]

I have some friends who are a bit more well-versed in TLS than I am, and I'd like to take a moment to get their opinion on things before going forward on this. For anything security-related, I can't accept PRs from unvetted sources; so please don't spend the time putting together a PR, and instead let's leave things where they are for the moment while I consult with some people I trust.

[coddingtonbear]

I've looked into this more, and I think the situation is a bit more nuanced than stated above. I don't think this is a bug in the plugin's certificate generation so much as a compatibility limitation with stricter clients.

Using a CA certificate as the target/leaf certificate is not categorically forbidden by RFC 5280. The RFC explicitly says:

In most cases, the target certificate will be an end entity certificate, but the target certificate may be a CA certificate as long as the subject public key is to be used for a purpose other than verifying the signature on a public key certificate.

That said, I do understand that some TLS implementations, client libraries, or application policies may choose to be stricter and reject certificates with CA:TRUE when used as a server certificate. That is a real compatibility concern, but it appears to be an implementation/policy constraint rather than a blanket RFC 5280 requirement.

Given that, I'm not currently convinced that the plugin should change its default certificate generation behavior. The plugin does, however, already allow users to provide their own certificate and CA via the "Advanced" section of the settings panel.

If you'd be interested in writing up instructions for generating certificates and keys that are compatible with stricter TLS clients, the project's Wiki is public and I would very much welcome that contribution.

I realize that may not be the outcome you were hoping for, but I hope the ability to configure custom certificates is a workable path forward.