ssltest: Chain issues - Contains anchor

Question

I've run ssltest on web application and it found "Chain issues - Contains anchor" (section "Additional Certificates (if supplied)")

What does it mean? Should it be fixed? Can it be exploited?

Answer 1

When the server sends its certificate to the client, it actually sends a certificate chain so that the client finds it easier to validate the server certificate (the client is not required to use exactly that chain, but, in practice, most client will use the chain and none other). This is described in the SSL/TLS standard, section 7.4.2, with, in particular, this enlightening excerpt:

The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.

Since that's a "MAY" case (the "MAY", "MUST", "SHOULD"... terminology in RFC has very precise meanings explained in RFC 2119), the server is allowed to include the root certificate (aka "trust anchor") in the chain, or omit it. Some servers include it, others do not. A typical client implementation, intent on using exactly the chain which was sent, will first try to find the chain certificates in its trust store; failing that, it will try to find an issuer for the "last" chain certificate in its trust store. So, either way, this is standards compliant, and it should work.

(There is a minor source of confusion with regards to chain order. In true X.509, the chain is ordered from trust anchor to end-entity certificate. The SSL/TLS "Certificate" message is encoded in reverse order, the end-entity certificate, which qualifies the server itself, coming first. Here, I am using "last" in SSL/TLS terminology, not X.509.)

The only bad thing that can be told about sending the root in the chain is that it uses a bit of network bandwidth needlessly. That's about 1 kB data per connection which includes a full handshake. In a typical session between a client (Web browser) and a server, only one connection will be of that type; the other connections from the client will use "abbreviated handshakes" which build on the initial handshake, and do not use certificates at all. And each connection will be kept alive for many successive HTTP requests. So the network overhead implied by the root-sending is slight.

Answer 2

It means that the certificates the site provides include the root certificate of the certificate chain (the chain where a certificate is linked to the certificate of its issuer, the root being a certificate which is its own issuer).

As a certificate is only trusted if the root (or some inbetween) certificate of its chain is explicitly trusted by the client, supplying the root certificate is not necessary: if it is trusted, the client already has it. The report, by the way, indicates that further down by the remark "In trust store".

I wouldn't consider that a reason for a warning, maybe only for a hint. ssltest also seems happy considering their 100% rating for the certificate.

There might have been exploits the other way around: rogue sites supplying bogus root certificates which buggy clients mistake for trusted ones, which results in the client trusting the site. Users of such clients are in trouble anyways, though.