522864 - bad cert on public site?

Status: VERIFIED DUPLICATE of bug 505031

(mozilla.org Graveyard :: Server Operations, task)

Description

[Samuel Sidler (old account; do not CC)]

A couple of people have reported this link when discussing the blocklist that we added recently:

  https://en-gb.www.mozilla.com/en-GB/blocklist/

I'm not sure how they get there (just check the blocklist from an en-GB build?), but the page currently shows the following error:

  Secure Connection Failed

  en-gb.www.mozilla.com uses an invalid security certificate.

  The certificate is only valid for *.mozilla.com

  (Error code: ssl_error_bad_cert_domain)

It shouldn't do that, especially since we're pointing users there. I consider this critical because we're actively sending users to this site and it's not allowing them to see important information. (Note: This likely applies to many, if not all, locales.)

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

here a "me too" for de-DE locale:
- get a 3.6 beta1 build from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.6b1-candidates/build1/win32/ (same for l10n trunk/MC builds)
- extras/addons/plugins + hit the "update" button to get above mentioned message

btw, shouldn't the button rather point to https://www.mozilla.com/(locale)/plugincheck/? that's what the button does in en-US builds.

Comment 2

[Shyam Mani [:fox2mike]]

Sam,

When did this site go live? 

It's because en-gb.www.mozilla.com != *.mozilla.com..so..this probably needs a new SSL certificate for *.www.mozilla.com

Comment 3

[Shyam Mani [:fox2mike]]

Also, this is just a 302...

trinity:~ shyam$ curl -I https://en-gb.www.mozilla.com/en-GB/blocklist/
HTTP/1.0 302 Found
Date: Sat, 17 Oct 2009 14:22:04 GMT
Server: Apache/2.2.3 (Red Hat)
X-Powered-By: PHP/5.1.6
Location: https://www.mozilla.com/en-US/blocklist/
Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0, private
Connection: close
Content-Type: text/html; charset=UTF-8
Set-Cookie: NSC_npa-dpn-ttm=4451663b3660;expires=Sat, 17-Oct-09 14:24:56 GMT;path=/

I'm wondering why we're doing en-gb.www.mozilla.com/en-GB/...

Skip the first en-GB and make www.mozilla.com/en-GB/destination redirect to https://www.mozilla.com/en-US/destination?

And for the record, I'm just throwing out some ideas..I don't know the design of these URLs and what they're doing...so someone more knowledgeable should chip in :)

Comment 4

[matthew zeier [:mrz]]

Bug 522877 comment #6.  

Bug 468526 - http://hg.mozilla.org/releases/mozilla-1.9.1/rev/273b9ecef4b7 - that pushed out the change to HTTPS but the server side (www.mozilla.com) still does the LOCALE redirect.

This change doesn't appear to have been tested correctly and nobody in Operations was aware of this (SSL is costly cpu, requires some scalability planning).

Short term fix, buy new certificate, setup new vserver, change DNS.  In the short term this will have to go on the Netscaler since *.www.mozilla.com behind Zeus has never been through QA or Metrics signoff.

Comment 5

[matthew zeier [:mrz]]

(and make sure logging works - shouldn't change where logs go)

Comment 6

[Axel Hecht [:Pike]]

So, the original url is https://www.mozilla.com/LOCALE/blocklist/, and if I look at wget with all redirects, it seems that some redirect from www.mozilla.com to en-gb.www.mozilla.com is bad. That might be somewhere in the path of language fallback for 404s. Note that the same redirects happens for plain http:, too.

I understood the plan to be to drop the ab-cd.www.mozilla.com urls alltogether, so not redirecting there looks like the right thing to do.

workbook:tmp axelhecht$ wget --no-check-certificate https://www.mozilla.com/en-GB/blocklist/
--2009-10-17 20:04:01--  https://www.mozilla.com/en-GB/blocklist/
Auflösen des Hostnamen »www.mozilla.com«.... 93.184.220.20
Verbindungsaufbau zu www.mozilla.com|93.184.220.20|:443... verbunden.
WARNUNG: Kann das Zertifikat von »www.mozilla.com« nicht prüfen, ausgestellt von »/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global CA«:.
  Die Authorität des Ausstellers des Zertifikates kann lokal nicht geprüft werden.
WARNUNG: Der Common Name »edgecastcdn.net« des Zertifikates entspricht nicht dem angeforderten Hostname »www.mozilla.com«.
HTTP Anforderung gesendet, warte auf Antwort... 302 Found
Platz: https://en-GB.www.mozilla.com/en-GB/blocklist/[folge]
--2009-10-17 20:04:03--  https://en-gb.www.mozilla.com/en-GB/blocklist/
Auflösen des Hostnamen »en-gb.www.mozilla.com«.... 63.245.209.10
Verbindungsaufbau zu en-gb.www.mozilla.com|63.245.209.10|:443... verbunden.
WARNUNG: Kann das Zertifikat von »en-gb.www.mozilla.com« nicht prüfen, ausgestellt von »/C=US/O=Equifax/OU=Equifax Secure Certificate Authority«:.
  Die Authorität des Ausstellers des Zertifikates kann lokal nicht geprüft werden.
WARNUNG: Der Common Name »*.mozilla.com« des Zertifikates entspricht nicht dem angeforderten Hostname »en-gb.www.mozilla.com«.
HTTP Anforderung gesendet, warte auf Antwort... 302 Found
Platz: https://www.mozilla.com/en-US/blocklist/[folge]
--2009-10-17 20:04:04--  https://www.mozilla.com/en-US/blocklist/
Wiederverwendung der bestehenden Verbindung zu www.mozilla.com:443.
HTTP Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 18908 (18K) [text/html]
In »index.html« speichern.

Comment 7

[Reed Loden [:reed]]

The correct, quickest, and cheapest solution to this problem is just to fix bug 454299.

Comment 8

[matthew zeier [:mrz]]

I agree with reed here and am hesitant to push out changes to prod load balancers over the weekend, assuming I can even get an SSL cert before Monday anyways.

Comment 9

[chizu]

Waiting on bug 454299 unless we can get a cert earlier.

Comment 10

[Cork]

Isn't this a dup on bug 505031 ?

Comment 11

[matthew zeier [:mrz]]

Dup or related, yes.

Comment 13

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified duplicate