During parsing, accept v1 certificates and allow certificates without subjectAltName

[briansmith]

Currently, constructing an EndEntityCert will fail unless the certificate is a v3 certificate with a subjectAltName extension.

Instead, the following should happen:

• If the certificate version is the default (not explicitly encoded), then that means v1. In that case, accept the certificate as long as there are NO extensions. (Extensions are not allowed in v1 certificates.)
• If the certificate version is v3, accept the certificate regardless of whether there are extensions.
• If the certificate version is anything else, reject the certificate.

If/when the subject name is validated, then name validation should always fail if no name matches are found, regardless of whether there was a subjectAltName extension and regardless of the version.

[robin-kunzler]

@briansmith : From our perspective it would be great if v3 certificates would be accepted regardless of whether they have extensions.

AFAIU, the relevant code is here. The der::nested currently returns the MissingOrMalformedExtensions error if no extension block is present.

Do you have plans to address this anytime soon?

[janimo]

@robin-kunzler it seems to work for me with this small change to the code you pointed at #241

[robin-kunzler]

@janimo : Thanks a lot, this looks good to me and it works for the certificates without extensions that I would like to use. Please see a more detailed comment in the PR #241 .

[fspreiss]

@briansmith, we would like to use rustls in our project but the requirement that the dependent webpki requires v3 certificates to have extensions is a blocker. We tested our implementation with @janimo's patch and that fixes the issue for us.

Would you therefore be OK with merging #241?

If you would like to have changes to #241, we would be happy to create a respective PR.

[fspreiss]

Would you therefore be OK with merging #241?

@briansmith, did you already have time to look at this?

Support for certificates without extensions is very important for our project. Judging from the number of 👍 on your original comment, it seem others would also be interested in this. So if there is anything that can be done to help getting this supported (e.g., adapt #241, or create an entirely different PR), please let me know. Thanks!

[briansmith]

Would you therefore be OK with merging #241?

@briansmith, did you already have time to look at this?

Support for certificates without extensions is very important for our project. Judging from the number of 👍 on your original comment, it seem others would also be interested in this. So if there is anything that can be done to help getting this supported (e.g., adapt #241, or create an entirely different PR), please let me know. Thanks!

Yes, I am planning to accept the PR. #248 is my current priority for this project and that work will unblock #241 and others.

[briansmith]

Specifically, here is my plan:

• During parsing, accept v1 certificates and v3 certificates without extensions, so that constructing the EndEntityCert succeeds instead of fails.
• Name validation would continue to fail since name validation wouldn't find any names. Making name validation more flexible (e.g. providing an option to accept names in the subject CN) is out of scope for this issue and is tracked by other issues.
• Verifying signatures using the public key of the certificate will succeed. In particular, this will allow people to plug in custom certificate chain building/validation while continuing to use webpki's (ring's) signature validation code. This is especially useful when trying to integrate with the operating system's verifier.
• [Edit: added] Path building will succeed.

[blind-oracle]

@briansmith any progress on this? As far as I see it still fails and I specifically need to verify the self-signed certificate with only a common name present (no SubjectAltName). Thanks!

[fspreiss]

@blind-oracle, if your certificate is v3, then you could use the rustls/webpki fork, where this is now supported.