@mastahyeti I assume by CertStore you meant CertPool. Just in case you meant to define a new type (I don't see CertStore anywhere), please define it a bit.

Yes. Thanks. I updated the OP.

Is there a use-case for reading all certificates returned? I could see removing certificates from a CertPool at runtime, but it might be easier to whitelist certificates into an empty CertPool.

Would inspecting the chains from a certificate perhaps solve the problem better? There's already a method for this.

func (c *Certificate) Verify(opts VerifyOptions) (chains [][]*Certificate, err error)

I'm starting to think that my use case is outside the intended purpose of this type.

I'm working on a library that creates/verifies CMS (PKCS#7 / S/MIME) SignedData structures. The structure will usually contain all or part of the chains needed to verify its signatures. It's possible though for it to contain no certificates, expecting the verifier to lookup the signing certificate by issuer/SN and build the chain itself. My verification method has a signature like this

func (sd *SignedData) Verify(opts x509.VerifyOptions) (chains [][][]*x509.Certificate, err error)

In the rare case where the SignedData doesn't include the leaf certificate that created the signature, I'd like the caller to be able to provide the leaf certificate as an additional intermediate in the VerifyOptions struct.

While this makes for a convenient API for my library, I'm realizing that I may be abusing the CertPool type by wanting to treat it as an arbitrary collection of certificates instead of just a set of intermediates or roots for chain building.

I'd like to reopen this issue.

We have, due to business requirements, a drop-in replacement for crypto/tls. The underlying library we use requires its own sort of certificate pool that we have to construct with individual certificates.

Because x509.CertPool does not provide a way to extract a copy of the certificates we have to ignore the (crypto/tls.Config).RootCAs field and load system certificates. In practice this works, but it makes testing particularly troublesome. It also limits what we're able to do with certificates in the future.

I'd like to propose this API:

// Certificates returns a copy of the certificates inside the CertPool, if any.
// The bool indicates the availability of full Certificates.
func (p *CertPool) Certificates() ([]*Certificate, bool)

I tried making a tool today that would try and verify if particular system certificates were present on the host, rather than blow up at runtime. And it's impossible to build that tool without this API change, or cloning most of the code here and building my own library.

Also: https://github.com/golang/go/blob/master/src/crypto/x509/cert_pool.go#L151-L159
is not sufficient because I still don't have a way to actually verify certificate material.

Hopefully no one finds this, but should you happen to try and actually iterate on the Subjects of your CertPool - RawSubject is actually a RDNSequence, not a pkix.Name

for i, rawSubject := range subjects {
	var rdnSequence pkix.RDNSequence
	_, err := asn1.Unmarshal(rawSubject, &rdnSequence)
	if err != nil {
		log.Fatal("could not unmarshal der formatted subject")
	}
	var name pkix.Name
	name.FillFromRDNSequence(&rdnSequence)
	fmt.Printf("cert %d: %s\n", i, name.CommonName)

}

https://play.golang.org/p/Adz1yjfm58_i