Description
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?
Activity
bradfitz commentedon 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 commentedon 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!