My fault, I misinterpreted the diagram on Wikipedia. You are right, the root CA would not have to be sent to the client then.
When I visit the source of ListenAndServeTLS and drill down the function calls that receive the cert file as a parameter, I end up at function X509KeyPair (Sourcegraph.com link here <https://sourcegraph.com/github.com/golang/go/-/blob/src/crypto/tls/tls.go?q=ListenANdServeTLS#L193:6>) that seems to read all blocks of type CERTIFICATE out of the cert file in a loop. This would then indeed include the root certificate, right? So it seems you have a valid point. On Tuesday, September 19, 2017 at 9:56:15 AM UTC+2, Karsten Weiss wrote: > > The client can validate the entire certificate chain because it must have > the root CA(s) in its root certificate store already. > > Sending the root certificate only increases the TLS message size and adds > latency. The TLS client doesn't need the root CA certificate because it > must only trust the root CAs in its own root certificate store anyway. > > Here are some 3rd party pointers on the topic that I've collected: > > - https://community.qualys.com/thread/11026 ("If the client does not have > the root in their trust store, then it won't trust the web site, and there > is no way to work around that problem. Having the web server send the root > certificate will not help -- the root certificate has to come from a > trusted 3rd party (in most cases the browser vendor).") > > - https://certsimple.com/blog/https-certificate-chains ("The top level, > or 'root' certificates are normally trusted because they came with your OS > or browser. ... When your browser visits an HTTPS website, it checks the > signatures of that site's certificate, and then checks the parent > certificate. It keeps checking certificates until it hits the root > certificate, stored in whatever trust store you're using.") > > - > https://blog.hboeck.de/archives/847-Incomplete-Certificate-Chains-and-Transvalid-Certificates.html > > ("a common issues is that people unneccesarily[sic] send the root > certificate, which doesn't cause issues but may make things slower") > > BTW: The Baseline Requirements do not allow that a server certificate is > signed directly by a root certificate. (See the certsimple blog post for > the explanation.) > > On Tuesday, September 19, 2017 at 8:52:14 AM UTC+2, Christoph Berger wrote: >> >> I am no TLS expert, but your question makes me wonder why the server >> should *not* serve the root CA's certificate. After all, it contains the >> signature >> <https://en.wikipedia.org/wiki/Public_key_certificate#TLS.2FSSL_server_certificate> >> >> that validates the server's certificate (either directly of via one or more >> intermediate CA's signatures). How can the client verify the server's >> certificate if the root CA's signature is not handed over to it? >> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
