ListenAndServerTLS() godoc comment

[knw...@gmail.com]

Hi,

I have a question about ListenAndServeTLS()'s godoc comment:

// ListenAndServeTLS acts identically to ListenAndServe, except that it

// expects HTTPS connections. Additionally, files containing a certificate and

// matching private key for the server must be provided. If the certificate

// is signed by a certificate authority, the certFile should be the concatenation

// of the server's certificate, any intermediates, and the CA's certificate.

I'm surprised about the last part ("and the CA's certificate").

A TLS web server usually does not serve the root CA certificate (only the
server's certificate and all the intermediate certificates). The root CA certs
OTOH are stored in the client's root certificate store.

However, the godoc comment seems to indicate that the root CA certificate
is expected.  Am I misunderstanding the comment?

I would have expected the following godoc comment instead:

// ListenAndServeTLS acts identically to ListenAndServe, except that it

// expects HTTPS connections. Additionally, files containing a certificate and

// matching private key for the server must be provided. If the certificate

// is signed by a certificate authority, the certFile should be the concatenation

// of the server's certificate, any intermediates, but NOT the root CA's certificate.

Comments?

[Christoph Berger]

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 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?

[knw...@gmail.com]

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.)

[Christoph Berger]

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) 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.

[knw...@gmail.com]

Reading the certs file in a loop is fine. However, the godoc comment should IMHO say, that the cert file should only consist of the server certificate and the intermediate certificate(s) but NOT the root CA certificate.

[Christoph Berger]

According to RFC4346 (found via serverfault), the root certificate can optionally be omitted from the PEM file. So sending the root CA along with the rest of the trust chain seems unnecessary but not wrong.