ssltest: Chain issues - Contains anchor
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.