Skip to content
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

crypto/x509: ParseCertificate and ParseCertificateRequest should return an error when there are duplicate x509 extensions #50988

Closed
aaomidi opened this issue Feb 3, 2022 · 4 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@aaomidi
Copy link

aaomidi commented Feb 3, 2022

What version of Go are you using (go version)?

go version: 1.17.6

Does this issue reproduce with the latest release? Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
go version go1.17.6 windows/amd64
PS C:\Users\private\GolandProjects\awesomeProject> go env
set GO111MODULE=auto
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\private\AppData\Local\go-build
set GOENV=C:\Users\private\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\private\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\private\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.17.6
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\Users\private\GolandProjects\awesomeProject\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\private\AppData\Local\Temp\go-build554477491=/tmp/go-build -gno-record-gcc-switches

What 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.

A certificate MUST NOT include more than one instance of a particular extension.

What did you see instead?

Go did not create any errors parsing malformed CSRs and Certificates.

@FiloSottile FiloSottile added the NeedsFix The path to resolution is known, but the work has not been done. label Feb 3, 2022
@rolandshoemaker rolandshoemaker added this to the Go1.19 milestone Feb 4, 2022
@gopherbot
Copy link

Change https://golang.org/cl/383215 mentions this issue: crypto/x509: reject duplicate extensions

@gopherbot
Copy link

Change https://go.dev/cl/398314 mentions this issue: crypto/x509: reject duplicate extensions

rubendv added a commit to Awingu/vault that referenced this issue Aug 12, 2022
…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.
rubendv added a commit to Awingu/vault that referenced this issue Aug 12, 2022
…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.
rubendv added a commit to Awingu/vault that referenced this issue Aug 12, 2022
…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.
@Radranic
Copy link

Radranic commented Sep 6, 2022

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: Some attribute types are restricted in their definition to have a single value; others may have multiple values. Not sure if that has meaning context.

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?

rubendv added a commit to Awingu/vault that referenced this issue Oct 7, 2022
…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.
cipherboy pushed a commit to hashicorp/vault that referenced this issue Oct 7, 2022
* 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.
@FiloSottile
Copy link
Contributor

Duplicate attributes in CSRs were re-allowed in https://go.dev/cl/428636.

jayant07-yb pushed a commit to jayant07-yb/hashicorp-vault-integrations that referenced this issue Mar 15, 2023
* 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.
@golang golang locked and limited conversation to collaborators Jan 3, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

5 participants