Closed Bug 361824 Opened 19 years ago Closed 18 years ago

certificate error (from IE7) when I attempt to get add on from https://addons.update.mozilla.org/

Categories

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

Product:
mozilla.org Graveyard
Component:
Server Operations
Platform:
x86
Windows XP
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: moco, Assigned: oremj)

References

(
URL
)

Details

(Whiteboard: Waiting for further instructions.)

Attachments

(4 files)

initial problem screen shot
65.90 KB, image/pjpeg
Details
following UI after I accept
55.13 KB, image/pjpeg
Details
Hits from 12/16 containing addons.update.mozilla.org
234.86 KB, application/gzip
Details
addons.update.mozilla.org referrers for 12/22
138.75 KB, text/plain
Details
certificate error (from IE7) when I attempt to get add on from https://addons.update.mozilla.org/ using IE7, I went to google and attempted to find the sqlite storage inspector. http://www.google.com/search?hl=en&lr=&rls=com.microsoft%3Aen- us&q=sqlite+storage+inspector the url I found on google was for https://addons.update.mozilla.org/, but I don't think that matches our cert, which is for *.mozilla.org (note, https://addons.mozilla.org does not give me a certificate error) here comes some screen shots.
note, I don't get a similar sort of cert warning with Fx 2.0, so perhaps IE 7 and Fx differ on how they accept wild card certs?
Moving to server ops for them to take a look.
Assignee: nobody → server-ops
Component: Public Pages → Server Operations
Product: addons.mozilla.org → mozilla.org
QA Contact: web-ui → justin
Version: unspecified → other
(In reply to comment #4) > Moving to server ops for them to take a look. Not exactly sure what action to take - it does look like IE7 has a markedly different wildcard cert behavior - it's claiming it's a mismatched address. They seem to be very strict in following RFC2595 2.4 Server Identity Check with regards to wildcard matching. From http://support.microsoft.com/kb/q258858/, "As described in RFC 2595, Microsoft's implementation allows a * in the leftmost element of the server's CN only. Within that leftmost element, there can be text to the left of the * but not to the right. " If I read that right, the common name is "addons" but the cert is for *.mozilla.org and not *.update.mozilla.org. (How many IE users look for addons?)
It looks like http://addons.update.mozilla.org redirects to addons.mozilla.org, but https://addons.update.mozilla.org does not redirect - it hosts the site from that url. I was going to suggest having https://addons.update.mozilla.org redirect to addons.mozilla.org, but I think it would still get the cert mismatch based on testing of https://addons.update.mozilla.org/developers which does direct to addons.mozilla.org/developers. (In reply to comment #5) > (How many IE users look for addons?) Maybe if we looked at some user agent logs to see just how many IE visitors are experiencing this problem, we could feel OK about not resolving this anytime soon.
I believe there was a bug filed against Firefox because it *didn't* complain about it. We discovered that back when we initially did that addons.update.thing after all the weird 1.0.x crap pre-1.0.4. That's why the modern site is just addons.mozilla.org now. addons.update should probably redirect unless the useragent says it's firefox 1.0.x.
1.0.x isn't supported any more at all, AFAIK. We should just take down the addons.update.mozilla.org site entirely, IMO, rather than have another hostname (and cert config, and...) to worry about. (A redirect won't help avoid this problem, obviously, since the redirect instruction is part of the HTTP response, and the cert error manifests before any HTTP exchange can occur.)
(In reply to comment #8) > 1.0.x isn't supported any more at all, AFAIK. We should just take down the > addons.update.mozilla.org site entirely, IMO, rather than have another hostname > (and cert config, and...) to worry about. So is that the fix? Can I WONTFIX it or something?
Assignee: server-ops → mrz
Not WONTFIX, please -- the current situation is bogus. I think we should take that site down, but we should check that we don't direct users to it in the current code anywhere. morgamic, you have any insight here? I don't see anything in lxr for it, but there might be some site-config stuff that I'm not up to date on.
Never saw any updates for Shaver's comment - what's the action for server-ops to take? (In reply to comment #10) > Not WONTFIX, please -- the current situation is bogus. > > I think we should take that site down, but we should check that we don't direct > users to it in the current code anywhere. morgamic, you have any insight here? > I don't see anything in lxr for it, but there might be some site-config stuff > that I'm not up to date on. >
Can you give a uniq -c sort of summary of the referrers for addons.update.mozilla.org hits, so we can make sure that we're not missing some conspicuous link to it? If we aren't, then we should just disable the vhost and remove the DNS entry.
Oremj - can you grep this out?
Assignee: mrz → oremj
I'm sorting through 12/16 right now. It is taking a while, but it looks like there is quite a few hits coming from addons.update.mozilla.org
Shaver do you want to take a look as this? I'm not sure exactly what you want.
All those hits are referred by addons.update.mozilla.org -- I'd like to find out what the _other_ referrers are (i.e., what other pages/sites are linking to addons.update.mozilla.org).
Doesn't look like those logs have that kind of data, however I can start logging that and look at this once we have some more data.
I am now recording the data needed to make this type of analysis.
Whiteboard: Waiting for more data
Here are all the referrers for 12/22. The - means there was no referrer. More useful data may be obtained with grep -v 'addons.update.mozilla.org' on this file.
Whiteboard: Waiting for more data → Waiting for further instructions.
Closing now that the requested data is attached. Please reopen if anything else needs to be done.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: