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

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

Closed
tsaridas opened this issue Dec 29, 2017 · 10 comments

Comments

@tsaridas
Copy link

@tsaridas tsaridas commented Dec 29, 2017

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 odeke-em changed the title Add support to get ssl context for x509 from certificate store windows proposal: crypto/x509: add support to get SSL context from certificate store on windows Dec 29, 2017
@gopherbot gopherbot added this to the Proposal milestone Dec 29, 2017
@gopherbot gopherbot added the Proposal label Dec 29, 2017
@odeke-em
Copy link
Member

@odeke-em odeke-em commented Dec 29, 2017

@bradfitz bradfitz added the OS-Windows label Dec 29, 2017
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Dec 29, 2017

/cc @johnsonj

@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Dec 30, 2017

@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
Copy link
Contributor

@agl agl commented Dec 31, 2017

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
Copy link
Author

@tsaridas tsaridas commented Jan 14, 2018

@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
Copy link
Contributor

@rsc rsc commented Jan 29, 2018

@FiloSottile
Copy link
Member

@FiloSottile FiloSottile commented Feb 1, 2018

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 rsc added this to Incoming in Proposals Jan 28, 2020
@rsc
Copy link
Contributor

@rsc rsc commented Feb 5, 2020

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 rsc moved this from Incoming to Active in Proposals Feb 5, 2020
@rsc
Copy link
Contributor

@rsc rsc commented Feb 12, 2020

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

@rsc rsc moved this from Active to Likely Decline in Proposals Feb 12, 2020
@rsc
Copy link
Contributor

@rsc rsc commented Feb 26, 2020

No change in consensus, so declined.

@rsc rsc closed this Feb 26, 2020
@rsc rsc moved this from Likely Decline to Declined in Proposals Feb 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Proposals
Declined
Linked pull requests

Successfully merging a pull request may close this issue.

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