Supporting x.509 v1 certificates and v3 certificates with no extensions

[lufte]

I wonder if it's in the interest of this fork to support these two types of certificates. The original repository already has two open pull requests to add these features:

• accept x.509 v1 certificates briansmith/webpki#234
• Allow validating V3 certificates that have no extensions briansmith/webpki#241

[djc]

What's your use case for these?

[fspreiss]

Support for v3 certificates without extensions is actually quite important for our project, e.g., to be backward-compatible with self-signed certificates (that we generated using openssl) that are deployed in production and difficult to change.

We were waiting for https://github.com/briansmith/webpki/issues/219 (which has quite a bit of support via 👍) to be resolved (via briansmith/webpki#241) for a long time now (almost 2 years), but unfortunately it hasn't happened yet. For the time being, we are working with a private fork of briansmith/webpki, but maintaining it is cumbersome and we'd be very happy to see this addressed in rustls/webpki (e.g., via briansmith/webpki#241).

[lufte]

I'm writing a gemini browser and I see a fair amount of servers with v1 certificates in the wild.

[djc]

#34 has since been merged, so we now accept V3 certificates without extensions. Thanks @fspreiss!

[cpu]

I'm quite hesitant to see support for X509 v1 certificates and don't think there's been enough compelling evidence presented to motivate support in this crate.

Is that the only remaining aspect keeping this ticket open now that the V3 sans extensions work has landed?

[djc]

I'm quite hesitant to see support for X509 v1 certificates

Why's that?

Is that the only remaining aspect keeping this ticket open now that the V3 sans extensions work has landed?

I think so.

[cpu]

Why's that?

I think it's more code surface for limited benefit. X509v3 was standardized in ~1996 and the web PKI has required V3 for over a decade. I believe remaining use-cases of V1 are largely self-signed certificates generated with poor defaults and I don't think the deployment of those certificates in 2023 is wide spread enough to merit adopting workarounds (or at least haven't been convinced of that yet).

[lufte]

That sounds like a fair argument. I say we're good with @fspreiss work.

[djc]

Thanks for your gracious response, will close this.

[djc]

If it turns out that for some reason V1 certificates are in widespread use in the MQTT ecosystem, perhaps we should reconsider this?

[cpu]

Do we know that they're in widespread use beyond test.mosquitto.org? It seems like an easy fix for the maintainers of that server to fix their certificate. They already have a valid certificate for the same hostname on :443 and a self-issued test PKI should be quite malleable.

[djc]

I don't know -- just speculating that there might be some obscure reason some ecosystems are sticking to V1.