Missing certificate for *.mozilla.com subdomains

VERIFIED FIXED

Status

--
major
VERIFIED FIXED
12 years ago
4 years ago

People

(Reporter: stephend, Assigned: mrz)

Tracking

Details

(Whiteboard: Need docs)

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
Using Safari 3.0 beta on Windows Vista/XP SP2, I can't even access http://www.trunk.stage.mozilla.com due to some sort of domain-security mismatch on the certificate.
This is because we have a wildcard SSL certificate for *.mozilla.com but not *.trunk.stage.mozilla.com, and wildcard SSL certificates only extend one level, so a certificate for *.mozilla.com doesn't extend to *.trunk.stage.mozilla.com. Read bug 159483 for more details.

I asked stephend to file this here, as I would like for us to drop our geolocation garbage so we don't prefix all our websites with "ab-CD." (such as en-US.www.mozilla.com), as the same issue is being seen on https://en-us.www.mozilla.com for Safari users (and probably other browsers that aren't as lax as we are about this issue). The NetScaler doesn't take it into account at all when geo-loadbalancing currently, as it does its balancing based on the IP address requesting the site, which makes much more sense. Getting rid of the ab-CD portion in the subdomain would fix this issue, and it would fix a lot of other problems we've had in the past due to having to accommodate this useless part of the domain (such as swapping to the appropriate subdomain based on which part of the site you're using).

If we decide (and I hope we do) to drop requiring the ab-CD part in the subdomain, we can drop the addition of it in all our products, too, as long as we set up redirects for *.www.mozilla.com to www.mozilla.com, which isn't hard at all.

Also, it may be wise for IT to purchase a *.stage.mozilla.com wildcard SSL certificate and rename www.trunk.stage.mozilla.com to www-trunk.stage.mozilla.com for trunk and leave www.stage.mozilla.com as production, so that only one certificate would be needed. However, I'm less worried about certificate mismatches on the trunk staging site, but I do think we should have one staging site for the production tag (currently www.stage.mozilla.com) that doesn't cause an SSL certificate mismatch so we can see if we actually have problems and be able to test new site features.

Thoughts? Comments? Let me know what you all think.
I'm moving this to IT to get their opinion since I haven't received any response from them.
Assignee: nobody → server-ops
Component: www.mozilla.com → Server Operations
Product: Websites → mozilla.org
QA Contact: www-mozilla-com → justin
Version: unspecified → other
Severity: critical → major
(Assignee)

Updated

11 years ago
Assignee: server-ops → mrz
(Assignee)

Comment 3

11 years ago
All of what reed said is correct and there's a substantial cost associated to wildcard certificates that I don't think is warranted for a stage site.

We've talked about setting up a MoCo root certificate so we can self-sign CSRs for tasks like this.  

I'll be working on that and some method to securely distribute the root CA.
mrz: How would you feel about dropping the "ab-CD." portion from the subdomains? As I understand it, it was added to assist in future geo-loadbalancing, but with the NetScaler actually going by IP address instead, it seems useless. Is there any reason from an IT point of view to keep it?
(Assignee)

Comment 5

11 years ago
/me has no comment .  The bug was about www.trunk.stage.mozilla.com, not $locale.www.mozilla.com.

Who accesses the latter over SSL?
(In reply to comment #5)
> /me has no comment .  The bug was about www.trunk.stage.mozilla.com, not
> $locale.www.mozilla.com.

This bug is about both issues. $locale.www.trunk.stage.mozilla.com, $locale.www.stage.mozilla.com, and $locale.www.mozilla.com are all used under SSL, though the first two have to be, while the latter is for users who wish to have a secure connection to mozilla.com (which we should definitely permit).
(Assignee)

Comment 7

11 years ago
www.trunk.stage.mozilla.com is now behind Mozilla's self-signed certificate.  I'm working on documentation and a place for folks to grab the root certificate for import.
(Assignee)

Updated

11 years ago
Whiteboard: Need root certficate/md5 hosted under mozilla.com & docs
(In reply to comment #7)
> www.trunk.stage.mozilla.com is now behind Mozilla's self-signed certificate. 
> I'm working on documentation and a place for folks to grab the root certificate
> for import.

You broke staging. More later.
Whiteboard: Need root certficate/md5 hosted under mozilla.com & docs → Need root certificate/md5 hosted under mozilla.com & docs

Comment 9

11 years ago
There is a cert warning, but that's expected unless you import the root cert.  WFM.  You should probably describe what you think is broken before posting to the bug.
(In reply to comment #9)
> There is a cert warning, but that's expected unless you import the root cert. 
> WFM.  You should probably describe what you think is broken before posting to
> the bug.

No, now the "www.trunk.stage.mozilla.com" SSL certificate is used for every staging site, which is just wrong. It should only be used for www.trunk.stage.mozilla.com and not all the staging sites (e.g., https://addons.stage.mozilla.com).

(Assignee)

Comment 11

11 years ago
So what are you asking for?

I can't do a wildcard cert for *.stage.mozilla.com and solve the actual problem with www.trunk.stage.mozilla.com.  

The original wildcard broke access for Safari and IE which you could argue is bad and works with this host specific URL.  I'm more inclined to leave it as it is now.  You claimed it was broken but it works better than it did earlier and I'm not clear why a cert warning is a big issue on a stage site.  

Can you clarify?

Comment 12

11 years ago
Furthermore, does anyone else besides Reed care about this?  Seems like a very minor issue which we are spending a lot of time on.  Please chime in (anyone other than reed) if you are bothered by this or have ideas.
I'm not particularly bothered by this.  Only thing I'd be concerned about is if the cert warning breaks any non-browser automated testing tools.  But there are ways around it anyway.  The bike shed is purple!
(Reporter)

Comment 14

11 years ago
(In reply to comment #12)
> Furthermore, does anyone else besides Reed care about this?  Seems like a very
> minor issue which we are spending a lot of time on.  Please chime in (anyone
> other than reed) if you are bothered by this or have ideas.

This is critical to being able to test Safari and Internet Explorer, which are part of our web-dev testing matrices.

Also, even currently, with mrz's fixes/cert implementations, I still get errors when those clients connect to staging.

I can post those errors in the form of screenshots, or just show justin/mrz...
(Assignee)

Comment 15

11 years ago
Is it the standard hostname mismatch error?  Is that important to get rid of?  Would importing a Mozilla root certificate get you around that (assuming hostname matches)?
(Reporter)

Comment 16

11 years ago
(In reply to comment #15)
> Is it the standard hostname mismatch error?  Is that important to get rid of? 
> Would importing a Mozilla root certificate get you around that (assuming
> hostname matches)?

Actually, the errors are annoying, but not critical themselves to testing; Safari 3.0.3 on Windows makes me authenticate via LDAP twice, but allows me to access the site (which it didn't, before).  Even IE 7 works now, where it didn't, before.

The cert errors seem to be that it's complaining about a self-signed cert; sorry for the false alarm, this seems to be OK (from my side, at least).
(Assignee)

Comment 17

11 years ago
Created attachment 283371 [details]
Mozilla Root Certificate
(Assignee)

Comment 18

11 years ago
md5 for the attached certificate :

fcd2026c3b8de102b36042c50e627cca
The cert and the md5sum were checked into Subversion under /libs/certs/ by morgamic four days ago.
(Assignee)

Comment 20

11 years ago
I'm closing this as FIXED since the original problem in comment #1 is resolved and you can bypass the browser warnings in comment #16 by importing the attached root certificate (and because this bug appears to be suffering from feature creep).

reed mentioned two separate issues:

> I would like for us to drop our geolocation garbage so we don't 
> prefix all our websites with "ab-CD." (such as en-US.www.mozilla.com)

This isn't IT's decision and should be in a seperate bug/discussion.  As far as justin/morgamic/mrz could tell, nothing in the browser uses https://$locale.www.mozilla.com/ .  

> The NetScaler doesn't take it into account at all when geo-loadbalancing 
> currently, as it does its balancing based on the IP address requesting 
> the site

That's true but the original reason for doing $locale.www.mozilla.com was for future flexibility.  Just because we use GSLB today doesn't mean we always will and this gives the ability to assign different IP addresses outside of GSLB.

> it may be wise for IT to purchase a *.stage.mozilla.com wildcard SSL
> certificate and rename www.trunk.stage.mozilla.com to 
> www-trunk.stage.mozilla.com for trunk and leave www.stage.mozilla.com

Renaming this probably involves a whole host other folk and should be discussed in a separate bug.

And, my bike shed is orange.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Created attachment 283455 [details] [diff] [review]
v1, simple patch to add certs/ and rewrite so it can be placed in /includes

This places _just the certs_ in a central location on mozilla.com and should not affect anything or anybody.
Attachment #283455 - Flags: review?(clouserw)
Attachment #283455 - Attachment is patch: true
Attachment #283455 - Attachment mime type: application/octet-stream → text/plain
Comment on attachment 283455 [details] [diff] [review]
v1, simple patch to add certs/ and rewrite so it can be placed in /includes

The patch came out a little weird (the svn:externals patch is messed up), but I know what you're doing, so r+.

Also, just for the record, these are never going to change, right?  So we should be able to just check out the external directly instead of giving it a revision?
Attachment #283455 - Flags: review?(clouserw) → review+
(Assignee)

Comment 23

11 years ago
Cert will change when it expires in 10 years or so.  Far from never but pretty infrequent (and we'll be using something other than svn anyways I bet!).
Comment on attachment 283455 [details] [diff] [review]
v1, simple patch to add certs/ and rewrite so it can be placed in /includes

>+# certs 
>+RewriteRule ^certs/mozilla-root.crt includes/certs/mozilla-root.crt [L]
>+RewriteRule ^certs/mozilla-root.crt.md5sum includes/certs/mozilla-root.crt.md5sum [L]

The md5sum file can never be viewed because the regexp for certs/mozilla-root.crt will always match certs/mozilla-root.crt.md5sum due to the lack of an ending '$'.

Also, this got checked-in on the trunk but not tagged for production. Once this other issue is fixed, would you like for Wil or me to tag it for you?
Attachment #283455 - Flags: review-
I'll be filing bugs addressing the issues mrz mentioned plus other issues I have noticed as soon as I find some time.
Whiteboard: Need root certificate/md5 hosted under mozilla.com & docs → Need docs
(In reply to comment #25)
> I'll be filing bugs addressing the issues mrz mentioned plus other issues I
> have noticed as soon as I find some time.

Filed bug 398934, bug 398935, bug 398936, and bug 398938.
Attachment #283371 - Attachment is patch: false
(In reply to comment #24)
> Also, this got checked-in on the trunk but not tagged for production. Once this
> other issue is fixed, would you like for Wil or me to tag it for you?

Issue was fixed on trunk. I have tagged the changes for production.

Sending        production
Sending        production/.htaccess
Transmitting file data .
Committed revision 7280.
Comment on attachment 283455 [details] [diff] [review]
v1, simple patch to add certs/ and rewrite so it can be placed in /includes

Besides the missing '$', the periods needed to be escaped and the .md5sum rule needed to come before the .crt one. Fixed in r11912.
Attachment #283455 - Flags: review-
(Reporter)

Comment 29

10 years ago
Been fine for a while, afaik; verified fixed.
Status: RESOLVED → VERIFIED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.