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: export CertPool’s certificates #19606

Closed
stapelberg opened this issue Mar 18, 2017 · 2 comments
Closed

crypto/x509: export CertPool’s certificates #19606

stapelberg opened this issue Mar 18, 2017 · 2 comments

Comments

@stapelberg
Copy link
Contributor

@stapelberg stapelberg commented Mar 18, 2017

I’m having a similar issue to #13335 which resulted in the SystemCertPool method.

However, for my use-case (https://gokrazy.github.io/), I don’t want to verify TLS certificates right away, I want to verify them later, on a different machine. Hence, I’d like to dump the SystemCertPool to a file and load it on the target machine.

I’m aware that this will fail with Windows as host machine due to its lazy certificate loading and verification happening outside of Go. But it’ll work at least on Linux, macOS and other supported operating systems, which is more than our current kludge supports.

Adding the following function would satisfy my use-case (but perhaps we should also copy the certificates themselves to prevent accidental modification):

func (s *CertPool) Certs() []*Certificate {
	res := make([][]byte, len(s.certs))
	for i, c := range s.certs {
		res[i] = c
	}
	return res
}

What do you think? Should I send a CL to add the function?

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Mar 18, 2017

I don't think we should do this.

The Mac situation isn't as good as you might think. There are arguments that we should be doing the same thing on macOS as we are on Windows and having the system verify things because the Mac verification (with both cgo enabled and disabled--- we have two complicated paths) is too slow and maybe frail or wrong.

So this would only work well for Linux and other certs-on-disk Unixes.

You're better off just packaging up the certs you want to depend on explicitly.

@stapelberg
Copy link
Contributor Author

@stapelberg stapelberg commented Mar 18, 2017

Ah, I wasn’t aware that we might move to a system verification model on macOS as well. It indeed makes sense to not change things, then. Thanks!

@stapelberg stapelberg closed this Mar 18, 2017
@golang golang locked and limited conversation to collaborators Mar 18, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

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