Relax version field check for x509 certificate requests

[uedvt359]

Many x509 systems erroneously issue v3 (0x02) CSRs when they want an X509v3 certificate. But only v1 (0x00) CSRs are valid and accepted by Cryptography.

This issue is pretty wide spread; for example certbot had this bug for years (2014/start-of-project ~ 2022). Right now, I'm wrestling with CSRs generated by some HP printers, so there's nothing we can do about them.

The relevant code is below. It should accept 0x02 (v3) CSRs, even though this version number are invalid. Most other x509 related software accepts these CSRs as well (boulder (letsencrypt backend), openssl, EJBCA (PKI/CA software)), so the strictness on Cryptography's part is creating breakage in real-world environments.

https://github.com/pyca/cryptography/blob/89228a9deb9a0901c87329414b4d8a062bd38bae/src/rust/src/x509/csr.rs#L316-L323

[reaperhulk]

I'm not opposed to parsing this and raising a warning (although @alex might be), but it is definitely desirable to fix the ecosystem by having stricter parsers reject these invalid items. Bearing in mind that products in the wild will likely never be fixed we should make sure that someone contacts HP to ensure they're aware that they're doing the wrong thing here.

It's a bit easier to allow this in the context of a CSR, which is by nature ephemeral, as opposed to a misencoded X.509 certificate itself.

[alex]

I'm not a fan of this, but as @reaperhulk indicated, to even consider it we'd need to know that HP had been contacted and were fixing their generation. Otherwise this is just an unbounded deviation from the standard.

[uedvt359]

This isn't an HP specfic problem, it was just the latest iteration of this bug I stumbled upon. Forget I mentioned it. And no, HP wasn't contacted; I can't figure out how to report this bug to them. Even if this particular instance would be fixed in future firmwares, there will be existing broken CSRs out there, and new broken CSRs generated by out-of-date firmware, and broken CSRs by other manufacturers, etc.

[alex]

You're approaching this from the precise opposite of our view:

Our view is that we've implemented the standard correctly, and HP has not. We are willing to consider limited, time bound, relaxations of some requirements in order to facilitate use, but we won't do so without the issue being reported to them and a commitment to it being fixed. We've required this same thing for similar bugs found in RedHat and Apple products -- both of whom fixed their issues.

We're uninterested in a general relaxation of requirements, particularly when it's not justified by widespread breakages. The incompatibility here is narrow and tailored.

Finally, we are very sensitive to the pathology that OSS maintainers are easier to complain to than giant corporations (we have a public bug tracker!). This creates a perverse incentive to complain to the wrong party, and so we're going to heavily push back.

[uedvt359]

found another one, the proxmox pve acme client: https://git.proxmox.com/?p=pve-common.git;a=blob;f=src/PVE/Certificate.pm;h=4ce73645a9c57407ae2abe8e0d9606fe7242d527;hb=HEAD#l433

my colleague has opened a ticket on my.proxmox.com already.

[mathiasertl]

Hi,

This already affected another user at #7783 and affects my CA implementation as well! :-(

For Debian, I have filed a bug report and got the issue fixed.

But for Ubuntu 20.04 and 22.04 (LTS), Ubuntu creates CSRs with the wrong version. This basically forces me to pin cryptography to version 37. Of course I have filed a bug report there as well: https://bugs.launchpad.net/ubuntu/+source/python-certbot/+bug/2004073 - but unfortunately it has been ignored for now.

We are willing to consider limited, time bound, relaxations of some requirements in order to facilitate use

For me, it would be sufficient to relax this until some time after Ubuntu 24.04 is released, e.g. October 2024. I definitely would add a warning for that.

kr, Mat

[mathiasertl]

Oh and,

This creates a perverse incentive to complain to the wrong party, and so we're going to heavily push back.

I of course strongly agree on this.

I don't know what else to do to get that Ubuntu bug merged, maybe you can do something to help? (You're the maintainers of a very widely used library, after all).

kr, Mat

[alex]

Thanks for flagging. As an initial matter, I'm going to reach out to folks at Canonical and see what we can do about this.

[mathiasertl]

Thanks a lot! <3

[alex]

@mathiasertl we now have an open SRU for ubuntu, however there's an open question of a test plan that demonstrates this (beyond a unit test): https://bugs.launchpad.net/ubuntu/+source/python-acme/+bug/2018252

Do you have an idea for an easy way to get certbot to generate a CSR?

I guess we could just use the acme python API to generate one, but that seems not in the spirit of what the Ubuntu maintainer requested.

[mathiasertl]

@alex I have to admit the Ubuntu process is mega-frustrating as always (which is why I usually don't submit bugreports to Ubuntu anymore). But in any case, I just wasted two hours to write up some instructions for them (for a one-line patch that is already applied Upstream, in Debian and Redhat).

[alex]

Thank you! Hopefully this will help get this resolved once and for all.

On Wed, May 24, 2023 at 4:17 PM Mathias Ertl @.***> wrote:

@alex I have to admit the Ubuntu process is mega-frustrating as always (which is why I usually don't submit bugreports to Ubuntu before). But in any case, I just wasted two hours to write up some instructions for them (for a one-line patch that is already applied Upstream, in Debian and Redhat).

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

-- All that is necessary for evil to succeed is for good people to do nothing.

[mathiasertl]

If they're not satisfied (it does not "reproduce such a rejection of a CSR", just show the CSR version), I'll have to invest more time to show this with django-ca. ugh.

[alex]

I think you've already gone above and beyond!

On Wed, May 24, 2023 at 4:20 PM Mathias Ertl @.***> wrote:

If they're not satisfied (it does not "reproduce such a rejection of a CSR", just show the CSR version), I'll have to invest more time to show this with django-ca. ugh.

— Reply to this email directly, view it on GitHub https://github.com/pyca/cryptography/issues/8625#issuecomment-1561876264, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAAGBDFBQNPFUFYFT7GKULXHZUR5ANCNFSM6AAAAAAWJILGKA . You are receiving this because you were mentioned.Message ID: @.***>

-- All that is necessary for evil to succeed is for good people to do nothing.

[alex]

The backport to acme is now in -updates for both focal and jammy. One less source of horrors in the universe.

[mathiasertl]

@alex I can't speak for @uedvt359 and his HP printer problems (TIL: There are printers that are ACME clients), but for me I would no longer request this feature.

Also thanks a lot for adding your weight to the launchpad bug report. Without it, this would certainly have been ignored until infinity.

[alex]

We've fixed this to the extent actionable (for Ubuntu), we're not willing to do workarounds for platforms not fixing their own generation.

If HP fixes generation, we could consider a time-limited work around.