Closed Bug 1115960 Opened 7 years ago Closed 6 years ago doesn't send a complete cert chain


(Web Compatibility :: Desktop, defect)

Not set


(firefox36 affected, firefox37 affected)

Tracking Status
firefox36 --- affected
firefox37 --- affected


(Reporter: bruant.d, Unassigned)



Details triggers a certificate warning when first visited.
This seems to only happen in Firefox Developer Edition (but not all were tested)

I don't know yet if it's a Firefox bug or if the warning is on purpose (so the problem would be on the certificate side).

I'm unsure "Security" is the right component. Feel free to change it to something more appropriate of course.
Happens in Nightly v37 as well
When I check using affected builds there appears to be no certificate chain when I try to add an exception (which is what the error under "technical details" means). And SSLLabs concurs:

The site loads fine in my nightly, and looking at the cert details shows a complete chain to COMODO. Does our cache of intermediates now persist on disk? (In the past it was in-memory only.) Does one of my addons ping some comodo-issued site and populates the intermediate cache early?

If you browse to and then reload the bordeaux3d site it should load because now Firefox knows about those intermediates. At least, WFM on my Firefox Dev Ed where I could reproduce the issue.

So I think this is a tech evangelism bug.
We must be persisting the intermediate cache now, although I can't find a relevant bug for it: When I restart this profile the site loads just fine.
Looks like successfully validated intermediate certificates starting being persistently cached as of bug 399045 (see in particular bug 399045 comment 10).
Thanks David. And it looks like this code was migrated to the new certverifier in Bug 891066 (part 6). Tech Evangelism it is.
Component: Security → Desktop
Product: Firefox → Tech Evangelism
Version: 36 Branch → unspecified
To understand properly, is it how it works ?

* Prior to Firefox 36, we were accepting this certificate because we had the root certificate in Firefox trust store
* Now, we don't accept the certificate because the server is not presenting us the full chain including the root certificate

I try to understand the previous behavior vs the current behavior.

Thanks !
No, nothing has changed since 2007 and bug 399045. When encountered with a fresh profile sites configured like this one have always been broken in Firefox. The site is misconfigured, period (see SSLLabs analysis in comment 2).

If a user has visited some other site that uses the same Comodo intermediate they will have it cached any time in the past then this site will appear to work. Comodo is a popular CA so this pre-condition will hold true for many (most?) users who have browsed around a bit. It will still be broken for people with a fresh profile, or for users of other browsers who don't cache intermediates like pre-2007 Firefox. We have gone beyond the TLS specification to accommodate broken sites, and this is exactly the fear Nelson Bolyard expressed in bug 399045.

The site is misconfigured and needs to send a complete certificate chain. Then whether it works or not does not depend on prior behavior of the visitor.
Thanks, this makes sense. Configuring the intermediate cert in the server is part of all SSL doc I read lately, so I hope we won't see this too often.
This still appears to be an issue.
OS: Linux → All
Hardware: x86_64 → All
Summary: Certificate warning for in Firefox Developer Edition (36) → doesn't send a complete cert chain
Closed: 6 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.