Comment 6 for bug 1795242

On Wed, Oct 03, 2018 at 05:55:59AM -0000, Stan Janssen wrote:
> (I wonder why DigiCert has not been able to convice Mozilla to include
> this certificate, yet they still sign certificates that are intended for

Most CAs have multiple levels of certificates. The ones that the browsers
include in trust bundles are normally stored off-line in locked vaults in
multiple shards and are only reconstructed once every few years for use,
to sign intermediary certificates.

The intermediary certificates are the ones that are used to sign end-user
certificates. These are not included in the browser bundles. Every site
that uses them is expected to include them in their certificate chains.

> public verification using this. And, to make matters worse, why most
> other browsers do seem to include the certificate by default or a least
> trust the certificate chain enough to load the pages.)

The trouble is, browser authors have seen incomplete chains before, and
have gone to some efforts to try to remediate the problem themselves. They
will *store* intermediate certificates as they discover them around the
wider web. If a misconfigured site forgets to include the full chain of
certificates, quite often site admins won't even notice because the
intermediate certs will be in their *local* user configuration.

This is what makes a service like Qualys's TLS checker so wonderful: it's
a well-written neutral third-party that knows how to diagnose a suprising
number of deployment and implementation mistakes.

Thanks