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

example

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

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

@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?

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

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?

I have a similar issue. Connecting to TLS with LetsEncrypt certificate I'd like to verify that root ca is either LetsEncrypt (I'd expect that to come from the system cert pool) or my own root ca certificate (I don't claim cryptographic correctness).

On windows this will error when retrieving the system cert pool:

certPool, err := x509.SystemCertPool()
if err != nil {
	return nil, err
}

if !certPool.AppendCertsFromPEM(caPEM()) {
	return nil, fmt.Errorf("failed to add CA certificate")
}

// create the credentials and return it
config := &tls.Config{
	RootCAs: certPool,
}

In the absence of SystemCertPool, what is the right way to check the root CA (on Windows)?