In the context of SSL Labs where is the "trust store"?

Question

When I'm testing a site with https://www.ssllabs.com/ssltest/ I'm getting this:

Could you explain:

• Why are there two paths? Where do they come from, where are they configured?
• What is this "trust store" mentioned? Is it in my browser? On the server I'm testing? On the SSLLabs.com server?

In the end I'm getting an "A":

But Chrome still complains:

I'm suspecting that this is because the trust chain on the first picture, but I'm not sure how to "fix" it. I read all the links in this question so I understand the basics, but my particular situation is not covered (or I cannot connect the dots).

Answer 1

Why are there two paths? Were do they come from, where are they configured?

A signature is created by using the public key of the issuers certificate. Two certificates can contain the same public key (typical after re-issuing a certificate) and this leads to alternative trust path if both of these CA certificates are included in the trust store.

What is this "trust store" mentioned? Is it in my browser? On the server I'm testing? On the ssllabs server?

This is on the SSLLabs server where they try to use a trust store similar to the browsers. Of course the real trust store used by the browser depends on the browser and/or OS, so it does not reflect fully what happens in the browser.

But chrome still complains:

Hard to tell what's really going on, but the signature of a certificate in the trust store is not relevant, only the signatures of leaf and intermediate certificates. It might be a false positive.

Answer 2

1 - The "trust store" depends of you browser / operating system. For Firefox, it's inside firefox, for Chrome on windows, it's the trust store of your windows

There is two path because ssllabs know two certificate that can be root. If your visitor have any of the two in their trust store, your certificate will be valid.

2 - Chrome may complain because if a debian bug :

https://sslmate.com/blog/post/chrome_cached_sha1_chains

It's not because the the two paths, and SHA-1 on root certificate don't produce that error :

Note: SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash.

https://blog.chromium.org/2014/09/gradually-sunsetting-sha-1.html

Answer 3

SSL Labs uses the Mozilla trust store

• What is this "trust store" mentioned? Is it in my browser? On the server I'm testing? On the ssllabs server?

The trust store is on the SSL Labs server. They use the Mozilla trust store. Details below.

• Why are there two paths? Where do they come from, where are they configured?

Because both the StartCom certificates are inside Mozilla's trust store. The SHA-1 signed one AND the SHA-256 signed one.

SSL Labs says this at the bottom of a scan result with trust problems:

Unknown Certificate Authority
In order for trust to be established, we must have the root certificate of the signing Certificate Authority in our trust store. SSL Labs does not maintain its own trust store; instead we use the store maintained by Mozilla. [...]

So: The Microsoft, Apple or Java truststores are NOT considered.

Other trust stores on the roadmap for SSL Labs

But it's on the roadmap says project lead Ivan Ristic on the SSL Labs forum:

Re: ComSign CA is not in trust store but is trusted by Internet Explorer and Chrome Ivan Ristic posted on Nov 14, 2014 1:22 AM (in response to Zeev Tarantov)
Not at the moment. SSL Labs uses the Mozilla root store, so if the root is not there we report it as not trusted. I anticipate that in the next major version we will report trust for each major root store separately.

Chrome uses the OS trust store

But Chrome still complains

Chrome uses the OS's trust store. It does NOT maintain it's own trust store. So that's where it can be fixed.

It seems that it SHOULD have worked. Since, as Steffen Ullrich, pointed out, the signature of the trust anchor does not matter. Only on the intermediates. And the intermediates are marked as "Sent by server". So it SHOULD have worked.

Maybe your Windows has cached the intermediate certificates and doesn't actually use what the server sends.

And there are actually at least two separate "StartCom Class 2 Primary Intermediate Server CA" certificates. Again, one with SHA1, the other with SHA256.

StartCom lists one way to repair this on their forums:

• Itzhak Daniel, StartCom Forums, 2015-04-19, Thread "Problems with mixed SHA-1/SHA-2 intermediate CA" (Archived here.):

This issue (with the existing infrastructure of StartCom CA), can be solved by the clients (the visitors of your site) and the software vendors (Google and Microsoft). - A client will need to manually remove our SHA1 signed Intermediate CA.
In Chrome, write in the url bar "Chrome://settings", scroll down and click on "Show Advance Settings...", continue to scroll down, reach HTTPS/SSL and click on "Manage certificates...". Windows' certificate manager will show up, go to "Intermediate Certification Authorities", find "StartCom Class...". You can just remove it and Windows will re-import the SHA2 signed Intermediate CA the next time you will visit a site without a full certificate chain.

There is an additional screenshot on their site.