-
Notifications
You must be signed in to change notification settings - Fork 18k
crypto/x509: ParseCertificate and ParseCertificateRequest should return an error when there are duplicate x509 extensions #50988
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Change https://golang.org/cl/383215 mentions this issue: |
Change https://go.dev/cl/398314 mentions this issue: |
Hello, I've encountered the result of this and just wanted to double check on the expected behavior. The RFC linked indicates there are no duplicate extensions allowed in certificates, this also seems reasonable to imply that there can be no duplicate extensions requested in a CSR. The changes made also consider it an error to have duplicate attributes in a CSR, not extensions which I can't find anything in PKCS #10 RFC which would indicate that this should be the case but I could be reading that wrong. Section 2.1 in RFC 2985 has: Aside from that, the duplicate attribute case is also not covered in the unit tests that were included. Can I get a confirmation/correction on the interpretation of the RFC? |
…sent in the CSR SAN extension and UseCSRValues is true. When UseCSRValues is true (as is the case on the sign-verbatim endpoint), all extensions including Subject Alternative Names are copied from the CSR to the final certificate. If the Subject Alternative Name in question contains any othernames (such as a Microsoft UPN) the SAN extension is added again as a workaround for an encoding issue (in function HandleOtherSANs). Having duplicate x509v3 extensions is invalid and is rejected by openssl on Ubuntu 20.04, and also by Go since golang/go#50988 (including in Go 1.19). In this fix I do not add the extension from the CSR if it will be added during HandleOtherSANs.
* Fix for duplicate SANs in signed certificates when othernames are present in the CSR SAN extension and UseCSRValues is true. When UseCSRValues is true (as is the case on the sign-verbatim endpoint), all extensions including Subject Alternative Names are copied from the CSR to the final certificate. If the Subject Alternative Name in question contains any othernames (such as a Microsoft UPN) the SAN extension is added again as a workaround for an encoding issue (in function HandleOtherSANs). Having duplicate x509v3 extensions is invalid and is rejected by openssl on Ubuntu 20.04, and also by Go since golang/go#50988 (including in Go 1.19). In this fix I do not add the extension from the CSR if it will be added during HandleOtherSANs. * Added unittest and changelog entry.
Duplicate attributes in CSRs were re-allowed in https://go.dev/cl/428636. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release? Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Create a malformed CSR with multiple SAN extensions manually. Then I tried to parse the malformed CSR.
Proof of Concepts:
What did you expect to see?
Per RFC5280, Section 4.2 I expected to see a failure in parsing CSRs and Certificates that contain any specific extension more than once.
What did you see instead?
Go did not create any errors parsing malformed CSRs and Certificates.
The text was updated successfully, but these errors were encountered: