STR: 1. Visit https://marketplace-dev.allizom.org/ in the browser or on the phone 2. Notice that the lock icon goes away (switches to globe in desktop browsers, switches to crossed-out lock on Unagi).

Which browser? I can't reproduce in nightly on linux. CCing QA

(In reply to Wil Clouser [:clouserw] from comment #1) > Which browser? I can't reproduce in nightly on linux. CCing QA Nightly 2012-12-18 desktop, and a B2G unagi build from about a week ago.

Krupa: can you reproduce this? I updated nightly and still can't reproduce.

I'm seeing the notification about "Connection Partially Encrypted" in Page Info. That said, I don't see any mixed (non https) content in the network logs. Hm.

Have you enabled "security.ssl.treat_unsafe_negotiation_as_broken" pref?

I've never tweaked any ssl settings- they're all stock.

is this a -dev regression? prod seems fine.

I bet it's from Google Analytics, which landed yesterday on -dev.

(In reply to Chris Van Wiemeersch [:cvan] from comment #8) > I bet it's from Google Analytics, which landed yesterday on -dev. That was my first guess, but I have yet to reproduce it. If you can, use the dev tools to tell us what request is going out over plain text.

This is reproducible on production: https://marketplace.firefox.com Here are my findings: http://f.cl.ly/items/3M3V3K0v3m0H0E2G3h04/Screen%20Shot%202012-12-19%20at%2010.32.37%20PM.png The common name for our prod cert is for our previous hostname: marketplace.mozilla.org.

Look at the details, marketplace.firefox.com is a SAN so that shouldn't be a problem. When I go to Page Info for marketplace.firefox.com I see "Owner: Mozilla Foundation" and "Verified by: GeoTrust Inc". From your screenshot, you see owner not supplied and "Verified by: Not specified." You cut off the cert hashes at the bottom, but my serial number is the same. I don't think I know enough about certs to debug more. CCing IT and sec.

This is what I see. (The third computer I've tried this on)

I believe the issue is the use off appcache to cache media from a different origin from the primary (the CDN in this case). From the applicationCache spec (http://www.w3.org/TR/2011/WD-html5-20110525/offline.html): If the manifest's <scheme> is https: or another scheme intended for encrypted data transfer, then all URLs in explicit sections must have the same origin as the manifest itself. Gross.

Saw security folks were copied in. Please ping us via "needsinfo" if we're needed. Agree that we shouldn't launch with mixed content errors. I think everyone is in alignment on that here.

STR: 1. Remove offline cache data for marketplace-dev in Options > Advanced > Network. 2. Reload the page. Lock icon is viible. 3. Allow marketplace-dev to use cache data offline 4. Shift-reload. 5. Mixed content indicator (globe or crossed-out lock) is shown.

Looks like this is not an SSL thing. Thanks.

Maybe this is bug 794507? If so, then that means that any SSL site will look like mixed content if it uses AppCache.

Assuming we want to fix the problem (which I am), the options I can think of are: 1) Allow offline media to be served from marmo directly 2) Modify Gecko to make this permissible 3) No appcache-based offline experience, Keep on Truckin™

bug 794507 was blocking-basecamp-'d which leaves us on the hook for this I guess which means our only reasonable option is #3?

Talked on IRC, option #3 it is. We've been struggling with appcache for weeks and I want to stop sinking out time into it. When it evolves further we'll look at it again, but in the mean time we're stopping work in that area.

This should be fixed, as appcache is presently disabled. When bug 826309 is fixed, we may be able to re-enable.