proposal: crypto/x509: add support to get SSL context from certificate store on windows

[tsaridas]

Please answer these questions before submitting your issue. Thanks!

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

1.9.2 windows/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 expect to see?

A way to be able to get the ssl context from windows certificate store and use it for https requests from server required client authentication.

What did you see instead?

windows syscalls which are not well documented on their usage in go. I would expect this to be done out of the box for users.

Info on windows certificate store
Windows documentation for .NET

[odeke-em]

/cc @agl @alexbrainman

[bradfitz]

/cc @johnsonj

[alexbrainman]

@tsaridas your request seems too general. Could you tell us what exactly are you trying to do?

Info on windows certificate store
Windows documentation for .NET

I briefly looked at this article, but it talks about many different things. What is your problem that you are trying to solve?

Thank you

Alex

[agl]

I think this might be asking for a way to service client-certificate requests using CAPI—i.e. if you have a client cert setup in Windows, Go should be able to use it automatically.

This is plausible, but it's a bunch of work and I feel that it's very unlikely to happen until it's needed by someone capable of implementing it. Even then, it's probably something for an external package rather than the stdlib.

[tsaridas]

@agl is right, that is what this request is about but also being able to use this certificate to perform a https call to a server that requires x509 client authentication.
I believe this is a basic functionality for Windows and maybe can be added to x/sys/windows ?

Or some documentation on how to do this in go would be really useful.

[rsc]

/cc @FiloSottile

[FiloSottile]

You can implement this functionality as a func(*tls.CertificateRequestInfo) (*tls.Certificate, error) function, which you can set as the GetClientCertificate callback in the tls.Config. You can then use it as the TLSClientConfig of a http.Transport in a http.Client to make HTTPS requests with it.

The tls.Certificate you return needs not to extract the private key if that's not possible, and can instead make PrivateKey implement crypto.Signer by using the Windows API.

I agree that this would probably be best implemented by an external package, and by someone with direct expertise/need. Chasing the Windows API for certificate validation has been painful in the past.

[rsc]

This issue hasn't been updated in a couple years, but the discussion seemed headed toward a likely decline. Has anything happened in the past two years that would change the discussion?

[rsc]

Based on the discussion above and the lack of activity, this seems like a likely decline.

[rsc]

No change in consensus, so declined.