1

I'm trying to install a Thawte SSL123 certificate on OS X 10.8.5, but having a difficulty. While the certificate and intermediates appear to be installed without any errors, running the Qualys SSL Labs report produces a "Chain issues Contains anchor" message. Running openssl s_client -showcerts -connect externalcortex.com:443 command shows a duplicate (see below)

Any help would be much appreciated!

CONNECTED(00000003) depth=3 /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/[email protected] verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/OU=Go to https://www.thawte.com/repository/index.html/OU=Thawte SSL123 certificate/OU=Domain Validated/CN=externalcortex.com i:/C=US/O=Thawte, Inc./OU=Domain Validated SSL/CN=Thawte DV SSL CA -----BEGIN CERTIFICATE----- xxx -----END CERTIFICATE----- 1 s:/OU=Go to https://www.thawte.com/repository/index.html/OU=Thawte SSL123 certificate/OU=Domain Validated/CN=externalcortex.com i:/C=US/O=Thawte, Inc./OU=Domain Validated SSL/CN=Thawte DV SSL CA -----BEGIN CERTIFICATE----- xxx -----END CERTIFICATE----- 2 s:/C=US/O=Thawte, Inc./OU=Domain Validated SSL/CN=Thawte DV SSL CA i:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA -----BEGIN CERTIFICATE----- xxx -----END CERTIFICATE----- 3 s:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/[email protected] -----BEGIN CERTIFICATE----- xxx -----END CERTIFICATE----- 4 s:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/[email protected] i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/[email protected] -----BEGIN CERTIFICATE----- xxx -----END CERTIFICATE----- --- Server certificate subject=/OU=Go to https://www.thawte.com/repository/index.html/OU=Thawte SSL123 certificate/OU=Domain Validated/CN=externalcortex.com issuer=/C=US/O=Thawte, Inc./OU=Domain Validated SSL/CN=Thawte DV SSL CA --- No client certificate CA names sent --- SSL handshake has read 6318 bytes and written 328 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: C88DB986D7A10D5FB17737D335153FF382E61A8564348235746A23B484E5630A Session-ID-ctx: Master-Key: CDA9E6D3FC8E8E5D7CCA7D3240FCA8E4BECFF3381064AFFE130B2E9DC2E0B471CC01D3C41E22792 5CB8197349606E047 Key-Arg : None Start Time: 1381459203 Timeout : 300 (sec) Verify return code: 0 (ok) ---
Improve this question

1 Answer 1

Reset to default
5

"Anchor" here means trust anchor: nominally, the named-and-public-key which is known a priori by the SSL client, and used to validate the server's certificate. Traditionally, trust anchors are encoded as certificates, which is a kind of a stretch because a number of fields in a certificate do not make much sense for a trust anchor.

In particular, a certificate has a SubjectDN field and an IssuerDN field, the latter being equal to the SubjectDN of the certificate issuer. A trust anchor has no issuer, so when the trust anchor is encoded as a certificate, it is customary to set the IssuerDN to the same value as the SubjectDN (the certificate is then "self-issued"). This is what you observe; it is not a "duplicate". Similarly, a certificate is signed, so there is a signature field to be filled; trust anchors are then often self-signed. A trust anchor encoded as a self-issued, self-signed certificate is also known as a "trusted root", or "root certificate", or "root CA", or a few other terminology variants.

When the SSL server talks with the SSL client, the server sends its certificate as part of a chain, beginning with a trust anchor and ending on the server's certificate proper. Then the question is: should the trust anchor, assuming that it is encoded as a certificate, be sent as part of the chain ? Sending that certificate is useless, because if the client is to validate the chain, then it must already have it. Nevertheless, it is allowed to send the trust anchor. The standard says so:

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.

Your server apparently sends the trust anchor. It would be exaggerated to call it an "issue": the standard allows it. At most, we could say that you may omit this trust anchor with no ill effect, and it would save a little bandwidth (about 1 kB per full handshake; the effect will usually not be significant).

(SSL Labs is known to award bad points and pronounce anathemas on details which are, actually, purely cosmetic.)

Improve this answer
1
  • Thanks for the thorough answer. It appears I managed to correctly configure SSL on my server then :) Commented Oct 11, 2013 at 13:02

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.