Certificate Chain when using ListenAndServeTLS

[sadbox]

When I use a certificate chain in ListenAndServeTLS it doesn't seem to serve up any more than the first certificate. This works properly using the stdlib's ListenAndServeTLS.

[zowens]

I got around this by adding AddChainCertificate, which you can use to add subordinate certificates. It may be a good idea to add some sort of function to parse the certificate and detect a chain. However, I don't think there's an analog for that behavior in openssl.

[jtolio]

yep, thanks zowens. we had been adding certificates separately to the certificate store manually (GetCertificateStore), but AddChainCertificate was a good addition.

sadbox: okay to close the ticket or is there something else you'd like us to do?

[sadbox]

I could take a look at making something to detect whether it's a chain or not, just depends on what @jtolds would like. In the mean time I'll just manually add the chain.

[jtolio]

It would be nice to have something nicer for people used to the Go lib behavior. If that's something you'd like to do I'd be happy to pull it in.

[lunixbochs]

I might be willing to do this. What if LoadCertificateFromPEM could return multiple certs, then the caller decides how to chain them? (or a new function, LoadCertificatesFromPEM).

Based on the basic PEM "spec" found here, my proposed solution would be to split the PEM into its sections using a multiline regex like this: (^-----[\s-]*?BEGIN.*?-----$.*?^-----[\s-]*?END.*?-----$), then parse each section as a separate cert.

[jtolio]

go's standard library actually already has a PEM parser which seems fine to use (http://golang.org/pkg/encoding/pem/), but that sounds good to me lunixbochs

[lunixbochs]

I do like the idea of using Go's internal one, but the next step feels a little weird. I guess we could use the internal DER format they generate, or re-marshal the individual certs as PEM? I think it's adding an abstraction + place to fail, and I don't know where Block.headers come into play.

[jtolio]

yeah i think the DER format isn't internal or go-specific here, it should just be something openssl can understand as-is, though the openssl der operations are super undocumented cause openssl docs suck. we use a few of them in a few places, i think they're the i2d and d2i type operations?

[lunixbochs]

This should be fixed by #21, though someone should test it.

[zeebo]

Closing due to inactivity.