1115960 - bordeaux3d.ants.builders doesn't send a complete cert chain

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[David Bruant]

https://bordeaux3d.ants.builders/ triggers a certificate warning when first visited.
This seems to only happen in Firefox Developer Edition (but not all were tested)
https://twitter.com/ttaubert/status/549152903240638464

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.

Comment 1

[Julien Wajsberg [:julienw]]

Happens in Nightly v37 as well

Comment 2

[Daniel Veditz [:dveditz]]

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:
https://www.ssllabs.com/ssltest/analyze.html?d=bordeaux3d.ants.builders

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 https://www.comodo.com/ 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.

Comment 3

[Daniel Veditz [:dveditz]]

We must be persisting the intermediate cache now, although I can't find a relevant bug for it: When I restart this profile the bordeaux3d.ants.builders site loads just fine.

Comment 4

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Looks like successfully validated intermediate certificates starting being persistently cached as of bug 399045 (see in particular bug 399045 comment 10).

Comment 5

[Daniel Veditz [:dveditz]]

Thanks David. And it looks like this code was migrated to the new certverifier in Bug 891066 (part 6). Tech Evangelism it is.

Comment 6

[Julien Wajsberg [:julienw]]

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 !

Comment 7

[Daniel Veditz [:dveditz]]

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.

Comment 8

[Julien Wajsberg [:julienw]]

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.

Comment 9

[:Cykesiopka]

This still appears to be an issue.

Comment 10

[:Cykesiopka]

Fixed.