4 Replies to “redhat.corpmerchandise.com is fixed”

  1. I’ll try again…

    TLS only allows the tranmission of a single certificate chain. In the more complex PKI environments, there can be multiple valid chains depending on how your client builds its chain from its trust anchors.

    CompanyARoot -> Sales Dept -> Server certificate

    CompanyBRoot -> Cross-siged Sales Dept -> Server certificate

    So there is no way for this server to know which chain to send during the TLS handshake (well – without implementing RFC 6606 section 11.4, which hardly anyone does).

    As such, if you want a non trivial PKI environment, sometimes clients have to be configured with intermediate certificates. If you use Windows, these would be pushed out by the domain controller. Firefox doesn’t have any central authority, so it has the caching model as an alternative.

    There is *no security problem what-so-ever* in Firefox caching or referring to intermediate certificates when building chains. As they are public information, a malicious server could have sent them anyway.

    So the answer to “what happens if redhat.corpmerchandise.com don’t send appropriate intermediate certificates” is – guess what- it doesn’t work if there aren’t appropriate certificates on the client.

    You just got lucky in that NSS happened to know about the intermediate certificate through local configuration. Note if you used Windows, Microsoft pre-configure a number of well-known intermediates (including Verisign ones).

    In any case, Firefox isn’t a debugging tool for TLS cluelessness. There are millions of on-line SSL test sites that’ll tell when a site is misconfigured.

Comments are closed.