Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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/emailAddress=premium-server@thawte.com
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/emailAddress=premium-server@thawte.com
-----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/emailAddress=premium-server@thawte.com
   i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com
-----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)
---
share|improve this question
add comment

1 Answer

up vote 1 down vote accepted

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

share|improve this answer
    
Thanks for the thorough answer. It appears I managed to correctly configure SSL on my server then :) –  Levi Oct 11 '13 at 13:02
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.