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: select a certificate store for systemVerify on Windows #34977

Open
SeanBurford opened this issue Oct 18, 2019 · 5 comments
Open

crypto/x509: select a certificate store for systemVerify on Windows #34977

SeanBurford opened this issue Oct 18, 2019 · 5 comments

Comments

@SeanBurford
Copy link

@SeanBurford SeanBurford commented Oct 18, 2019

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

$ go version
go version go1.13 linux/amd64

Does this issue reproduce with the latest release?

Yes.

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

Windows.

What did you do?

Attempted to build a set of certificate chains for a certificate:

var cert *x509.Certificate
...
intermediates := x509.NewCertPool()
intermediates.AddCert(intermediate)
vo := x509.VerifyOptions{
    Roots:         nil, // Use system roots
    Intermediates: intermediates,
}
chains, err := cert.Verify(vo)

What did you expect to see?

Complete chains when running as a user or as the system user.

What did you see instead?

systemVerify() in crypto.x509.root_windows.go always passes HCCE_CURRENT_USER as the hChainEngine argument to syscall.CertGetCertificateChain() (syscall.Handle(0) in the first argument). This means that chain lookups as the system user will fail for us, because the required certificates are stored in HCCE_LOCAL_MACHINE (syscall.Handle(1)).

It's possible to pass an additional store as argument 4 to the syscall. This argument is currently storeCtx.Store, which is nil but it might be possible for createStoreContext to populate it with a HCERTSTORE pointing to HCCE_LOCAL_MACHINE.

Alternately, the store preference could be specified in VerifyOptions.

@networkimprov
Copy link

@networkimprov networkimprov commented Oct 18, 2019

@SeanBurford it helps if you bracket code examples with ``` lines

example

cc @alexbrainman @mattn @zx2c4
@gopherbot add OS-Windows

@mattn
Copy link
Member

@mattn mattn commented Oct 18, 2019

x509.SystemCertPool() on Windows is not provided from standard library any more. The reason is that Windows doesn't ship with all of its root certificates installed. Instead, it downloads them on-demand.

See #18609

@zx2c4
Copy link
Contributor

@zx2c4 zx2c4 commented Oct 18, 2019

@SeanBurford Are you saying that when the process is running as S-1-5-18, HCCE_CURRENT_USER results in Go using a totally empty certificate store?

@dmitshur dmitshur changed the title Select a certificate store for systemVerify on Windows crypto/x509: select a certificate store for systemVerify on Windows Oct 21, 2019
@SeanBurford
Copy link
Author

@SeanBurford SeanBurford commented Oct 22, 2019

@zx2c4, no, I'm saying that the intermediates that we need to build the chain to a certificate are installed in the Local Machine System CA store. When running as S-1-5-18 a search of the Current User CA store doesn't find them so the chain(s) cannot be built.

@zx2c4
Copy link
Contributor

@zx2c4 zx2c4 commented Oct 22, 2019

So should we be passing HCCE_LOCAL_MACHINE all the time, or will that result in other complications when running as non-S-1-5-18?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.