Skip to content

crypto/x509: crlSign key missing for CreateRevocationList #49414

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.

Sign up for GitHub

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

Jump to bottom
Closed
solyard opened this issue Nov 6, 2021 · 6 comments
Closed

crypto/x509: crlSign key missing for CreateRevocationList #49414

solyard opened this issue Nov 6, 2021 · 6 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Backlog

Comments

@solyard
Copy link

solyard commented Nov 6, 2021

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

$ go version
go version go1.17.2 darwin/arm64

Does this issue reproduce with the latest release?

IDK

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

go env Output
$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/test/Library/Caches/go-build"
GOENV="/Users/test/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/test/Documents/coding/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/test/Documents/coding/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/opt/homebrew/Cellar/go/1.17.2/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/opt/homebrew/Cellar/go/1.17.2/libexec/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.17.2"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/0f/8wz3fk011cs1tmkk44fbb_fr0000gn/T/go-build3175916892=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I used method x509.CreateRevocationList to create CRL and gave on input my cert and private key for signing CRL. But library returns error : x509: issuer must have the crlSign key usage bit set

In attributes of my certificate I see this:

Certificate purposes:
...
CRL signing : Yes
CRL signing CA : Yes
...

Maybe the problem is my cert is x509.v3 and CreateRevocationList returns x509.v2? (who knows?)

After I commented this lines in x509.go everything started works nice:

2115	if (issuer.KeyUsage & KeyUsageCRLSign) == 0 {
2116		return nil, errors.New("x509: issuer must have the crlSign key usage bit set")
2117	}

What did you expect to see?

CRL []byte

What did you see instead?

x509: issuer must have the crlSign key usage bit set
@cagedmantis cagedmantis added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Nov 8, 2021
@cagedmantis cagedmantis added this to the Backlog milestone Nov 8, 2021
@cagedmantis cagedmantis changed the title crypto/x509 crlSign key missing for CreateRevocationList crypto/x509: crlSign key missing for CreateRevocationList Nov 8, 2021
@cagedmantis
Copy link
Contributor

cc @FiloSottile @agl @katiehockman @rolandshoemaker

@antong
Copy link
Contributor

antong commented Nov 9, 2021 •
edited
Loading

@solyard , can you give an example of a certificate that exhibits this problem? To me it sounds like CreateRevocationList works as it should when it doesn't agree to sign a CRL when the issuer certificate that doesn't have that key usage. I think the question is why the issuer certificate doesn't have that key usage bit set. An example would be great and a description of how you got the x509.Certificate struct. Did you use x509.ParseCertificate?

Here is an example to show that CreateRevocationList works, if the certificate struct does have the right key usage bit set: https://play.golang.org/p/2u7bk8cB__s

@solyard
Copy link
Author

solyard commented Nov 10, 2021

@solyard , can you give an example of a certificate exhibits this problem? To me it sounds like CreateRevocationList works as it should when it doesn't agree to sign a CRL when the issuer certificate that doesn't have that key usage. I think the question is why the issuer certificate doesn't have that key usage bit set. An example would be great and a description of how you got the x509.Certificate struct. Did you use x509.ParseCertificate?

Here is an example to show that CreateRevocationList works, if the certificate struct does have the right key usage bit set: https://play.golang.org/p/2u7bk8cB__s

You are right I used certificate that was created without keyUsage block. Can I use certificate that I have and add keyUsage for CRL in code runtime? I cannot replace certificates that already exists with that who have keyUsage block :( Any workaround here?

@antong
Copy link
Contributor

antong commented Nov 12, 2021

Sure you can set the correct key usage bit and get the CreateRevocationList to produce a result, like cert.KeyUsage |= x509.KeyUsageCRLSign (https://play.golang.org/p/dQN-0txU5FJ). But, who will be consuming the CRL and how will they verify its validity? I mean, if they use the same certificate to validate it, then they will probably also check the key usage.

@solyard
Copy link
Author

solyard commented Nov 12, 2021

Thanks a lot I will try this workaround and give feedback. I want to use generated CRL in my Nginx installation so I think CRL will be work fine. You are my saviour 👍

@solyard
Copy link
Author

solyard commented Nov 18, 2021 •
edited
Loading

@antong Thanks for helping. Everything works fine. Closing this thread

@solyard solyard closed this as completed Nov 18, 2021
@golang golang locked and limited conversation to collaborators Nov 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
4 participants
@cagedmantis @antong @gopherbot @solyard