Due to Safari 3.03's correct implementation of RFC 2818, users of Safari 3.03 cannot connect to https://<locale>.add-ons.mozilla.com because Safari 3.03 does not accept the use of the "*.mozilla.com" wildcard SSL certificate for https://<locale>.add-ons.mozilla.com, as the wildcard is only meant for that one level in the domain name. This may also affect other browsers (and I think I remember stephend mentioning another one, but I can't remember right now). This does not affect Firefox because of bug 159483, but if that bug were to ever be fixed, it would cause the same problems in Firefox. I believe it's better to be safe than sorry in this case. Possible solutions to this problem: * Purchase a wildcard SSL certificate for *.add-ons.mozilla.com * Stop using locale-based subdomains and just connect to add-ons.mozilla.com (or even just addons.mozilla.org); see bug 398938 for more information about this as it concerns *.www.mozilla.com, too I'd much prefer the second solution, personally, as I believe the locale-based subdomains are not needed at all and have only caused problems since their implementation. These https://<locale>.add-ons.mozilla.com URLs that are affected are used on both the www.mozilla.com website and in the Firefox product itself. For links on the website, just look at http://www.mozilla.com/en-US/firefox/updated and http://www.mozilla.com/en-US/firefox/2.0.0.7/whatsnew/ to see where these types of links are used. The same thing holds true for https://<locale>.www.mozilla.com, which is also currently using the "*.mozilla.com" SSL certificate. Nothing in the browser itself links to https://<locale>.www.mozilla.com, but that doesn't mean it shouldn't work. Users on the website get moved around from subdomain to subdomain a lot, so if the user chose to use https to connect to www.mozilla.com, he/she could possibly (and probably easily) find himself/herself on https://<locale>.www.mozilla.com, which would be affected by the problem.

(In reply to comment #0) > Due to Safari 3.03's correct implementation of RFC 2818, users of Safari 3.03 > cannot connect to https://<locale>.add-ons.mozilla.com because Safari 3.03 does > not accept the use of the "*.mozilla.com" wildcard SSL certificate for > https://<locale>.add-ons.mozilla.com, as the wildcard is only meant for that > one level in the domain name. Out of curiosity, what links to https://<locale>.amo? I wasn't able to find any obvious link to it. Do Safari users actually goto AMO or even to locale.amo? > Possible solutions to this problem: > * Purchase a wildcard SSL certificate for *.add-ons.mozilla.com > * Stop using locale-based subdomains and just connect to add-ons.mozilla.com > (or even just addons.mozilla.org); see bug 398938 for more information about > this as it concerns *.www.mozilla.com, too I think Axel pointed out that this is a schrep call.

> Out of curiosity, what links to https://<locale>.amo? I wasn't able to find any > obvious link to it. The only page I could find on mozilla.com was http://www.mozilla.com/en-US/firefox/updated/index.html (the link only shows up if you're running ff1.5 I think). mozilla-europe.org has a few pages that link to it though.

Can you change the link on the first (shows up in Fx2 as well) and from mozilla-europe? You're already figuring out locale and 302s me to https://amo/<locale>/. Then I can close this :)

(In reply to comment #1) > Out of curiosity, what links to https://<locale>.amo? I wasn't able to find any > obvious link to it. Every whatsnew page has links to it, along with the old firstrun pages. I mentioned multiple URLs in paragraph five in comment #0. > Do Safari users actually goto AMO or even to locale.amo? If users are thinking about swapping to Firefox, they would probably want to see what is available for them when using Firefox, so users definitely may visit AMO. Now as to if they use the locale.amo urls, that's something I can't answer, but we can never be too careful. (In reply to comment #3) > Can you change the link on the first (shows up in Fx2 as well) and from > mozilla-europe? You're already figuring out locale and 302s me to > https://amo/<locale>/. > > Then I can close this :) No, because that's against the policy for URLs. Fix bug 398938, and sure, but until the policy changes, we still use the URI scheme that was decided at the Toronto meeting (This was already brought up by somebody before).

Are you saying <locale>.add-ons.mozilla.com will no longer work, or just that there won't be links on moz.com and moz-eu?

I'm not sure who you're talking to - I can use a new IP address and pay for a new wildcard cert for *.addons.mozilla.org but I don't think that's worth the expense and I don't think that's the direction we're moving towards anyways. I was suggesting that the ahref link in http://www.mozilla.com/en-US/firefox/updated/index.html be changed to strip out the locale (all policies have exceptions). I'm also suggesting that the first run page be changed to strip out the locale (all policies have exceptions). Both would nearly immediately negate needing a wildcard cert for *.addons.mozilla.org . Otherwise, I'd rather mark this bug WONTFIX especially if we drop locale anyways.

I got around this by importing the Mozilla root CA cert into IE 7, but until then was experiencing this on https://kubla.sm-cms01.mozilla.com/en-US/firefox/2.0.0.6/whatsnew; glad it works now.

(In reply to comment #7) > I got around this by importing the Mozilla root CA cert into IE 7, but until > then was experiencing this on > https://kubla.sm-cms01.mozilla.com/en-US/firefox/2.0.0.6/whatsnew; glad it > works now. Huh? The Mozilla Root Certificate should have nothing to do with this bug. This is regarding a production URL using the XRamp "*.mozilla.com" wildcard SSL certificate, not the Mozilla Root Certificate.

(In reply to comment #8) > (In reply to comment #7) > > I got around this by importing the Mozilla root CA cert into IE 7, but until > > then was experiencing this on > > https://kubla.sm-cms01.mozilla.com/en-US/firefox/2.0.0.6/whatsnew; glad it > > works now. > > Huh? The Mozilla Root Certificate should have nothing to do with this bug. This > is regarding a production URL using the XRamp "*.mozilla.com" wildcard SSL > certificate, not the Mozilla Root Certificate. Sorry, yeah; that particular case (https://en-us.add-ons.mozilla.com/en-US/firefox/) is indeed broken with IE 7.

(In reply to comment #2) > > Out of curiosity, what links to https://<locale>.amo? I wasn't able to find any > > obvious link to it. > > The only page I could find on mozilla.com was > http://www.mozilla.com/en-US/firefox/updated/index.html (the link only shows up > if you're running ff1.5 I think). Which is likely a non-issue for Safari users. > mozilla-europe.org has a few pages that link to it though. Which pages exactly?

> The only page I could find on mozilla.com was > http://www.mozilla.com/en-US/firefox/updated/index.html (the link only shows up > if you're running ff1.5 I think). This link was broken to begin with since we never had a *.add-on.mozilla.com and IIRC Fx took some liberty in processing wildcard certificates and obviously wasn't QA's against other browsers. Those specific links should be changed to remove the https since the http version redirects and handles locale. Hopefully this doesn't violate any URL policy. Morgamic - comments?

I am not sure why we are QA-ing the en-us.* links in Safari? The subdomains were used for in-product links in Firefox. Why is it an issue if Safari doesn't behave properly using these URLs? My reaction is that this bug is a WONTFIX because people using Safari don't use these URLs as a point of entry -- and I don't see why that would ever change given that these are internal URLs. Can someone comment on that?

(In reply to comment #12) > I am not sure why we are QA-ing the en-us.* links in Safari? > > The subdomains were used for in-product links in Firefox. Why is it an issue > if Safari doesn't behave properly using these URLs? "Because it's in stephend's browser test matrix." No, really; that's the reason as it currently stands, and I agree it's not a very valid one, at that. Could we get Marketing to agree that Firefox-specific pages don't need to be certified in other browsers to the extent they are for Firefox? (Paul?) I agree with you, morgamic, just want to make sure that we're all on the same page. When devising my matrix, I incorporated notions of support, articulated in priority levels, but we've never fully fleshed (we= Marketing/WebDev/QA, et al.) the true level of support; I think "graceful degradation" was described as our support for non-Firefox browsers, but that's not a very explicit summation. > My reaction is that this bug is a WONTFIX because people using Safari don't use > these URLs as a point of entry -- and I don't see why that would ever change > given that these are internal URLs. > > Can someone comment on that?

I should mention that this only applies to Fx2. Fx3 won't work with any of these URLs in their current form (or rather, with the current single level *.mozilla.com wildcard cert). For Fx3, either the URLs need to change or I need to get a *.add-ons.mozilla.com certificate. The latter has a large non-recurring dollar amount, of course. - mz

-----BEGIN NEW CERTIFICATE REQUEST----- MIIB/jCCAWcCAQAwgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh MRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRwwGgYDVQQKExNNb3ppbGxhIENvcnBv cmF0aW9uMRwwGgYDVQQLExNNb3ppbGxhIENvcnBvcmF0aW9uMR4wHAYDVQQDFBUq LmFkZC1vbnMubW96aWxsYS5jb20xJTAjBgkqhkiG9w0BCQEWFmhvc3RtYXN0ZXJA bW96aWxsYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKORCcmdNt5/ 5LY3UPx9MJUsKcbrSD+JZ1DU56e9sLyTFdwo7CwRc7nTInElv9BIukasuayb9Nd9 rBPNDodz2mwZ3utbquKZADSLyVmU1vVxjRGpzMEqlvAzCTn4ir56zv5g9kDHm900 9hgUfnX6mIwEtZESc/h63fU4NKlUTjtZAgMBAAGgADANBgkqhkiG9w0BAQUFAAOB gQAJLcx/eE9w3zZGcmFuv9AOwORr5aZnZnPzd/aJYQid+pWtzOceSHFBj4kjIzE9 JfbqHME/4jI4XGr4j+KfSd9OKFN5J5DP4bvagNs7PeS0OAdw//gEKvKjjucypxp/ 2bXIFQFpyBS0uLrUh0UB7Sh2P1CxyIjiphJo0lKmY0OOPQ== -----END NEW CERTIFICATE REQUEST-----

cert on order.

-----BEGIN CERTIFICATE----- MIIDDDCCAnWgAwIBAgIDCFISMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT MRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDcxMTE1MTk0ODIxWhcNMDgxMTE1MTk0ODIx WjCBljELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcT DU1vdW50YWluIFZpZXcxHDAaBgNVBAoTE01vemlsbGEgQ29ycG9yYXRpb24xHDAa BgNVBAsTE01vemlsbGEgQ29ycG9yYXRpb24xHjAcBgNVBAMUFSouYWRkLW9ucy5t b3ppbGxhLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAo5EJyZ023n/k tjdQ/H0wlSwpxutIP4lnUNTnp72wvJMV3CjsLBFzudMicSW/0Ei6Rqy5rJv0132s E80Oh3PabBne61uq4pkANIvJWZTW9XGNEanMwSqW8DMJOfiKvnrO/mD2QMeb3TT2 GBR+dfqYjAS1kRJz+Hrd9Tg0qVROO1kCAwEAAaOBrjCBqzAOBgNVHQ8BAf8EBAMC BPAwHQYDVR0OBBYEFANIrHnGwRvd/vSuQYsrL7tbHrh1MDoGA1UdHwQzMDEwL6At oCuGKWh0dHA6Ly9jcmwuZ2VvdHJ1c3QuY29tL2NybHMvc2VjdXJlY2EuY3JsMB8G A1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMB0GA1UdJQQWMBQGCCsGAQUF BwMBBggrBgEFBQcDAjANBgkqhkiG9w0BAQUFAAOBgQA8qQ5bPC3KLPhp3bw8GfM+ myqAhfNwnWDlzvHDWUpdeoL1c2UL3yqadCa1sKhFD1Tl2/bi8zDDGSzTB95vDd8J 2eB3Yx9QYsBkpWPqc331o4I9Gb5oscttku4kDX6B8RwkzjtePYR+0t0oyZnWx0sN KnfM3h0VYIW27nGvan62bw== -----END CERTIFICATE-----

Certificate added. New IP for *.add-ons.mozilla.com is 63.245.209.16. This probably needs some testing and verification before flipping real DNS over to it (or at least someone other than just me should sign-off on it). Punting back to the queue.

waiting on reed for testing

Appears to work, closing.

(In reply to comment #20) > Appears to work, closing. ??? blahblah.add-ons.mozilla.com is an alias for redirect-com.glb.mozilla.com. redirect-com.glb.mozilla.com has address 63.245.209.37 63.245.209.37 sure doesn't look like 63.245.209.16, as per comment #18.

That's true - everyone was waiting on you to say "yes it works, go change dns". I'll give you a couple hours to test and then I'll just change DNS and be done with this bug.

(In reply to comment #22) > That's true - everyone was waiting on you to say "yes it works, go change dns". Sorry, I'm in the middle of exams, so I haven't had time to do much at all. > I'll give you a couple hours to test and then I'll just change DNS and be done > with this bug. OLD $ curl -I https://en-us.add-ons.mozilla.com/en-US/firefox/ HTTP/1.1 302 Found Date: Thu, 06 Dec 2007 02:30:53 GMT Server: Apache/2.0.52 (Red Hat) Location: https://addons.mozilla.org/en-US/firefox/ Content-Type: text/html; charset=iso-8859-1 NEW $ curl -I -k -H'Host: en-us.add-ons.mozilla.com' https://63.245.209.16/en-US/firefox/ HTTP/1.1 302 Found Date: Thu, 06 Dec 2007 02:30:12 GMT Server: Apache/2.0.52 (Red Hat) Location: https://addons.mozilla.org/en-US/firefox/ Content-Type: text/html; charset=iso-8859-1 $ curl -I -H'Host: en-us.add-ons.mozilla.com' https://63.245.209.16/en-US/firefox/ curl: (51) SSL: certificate subject name '*.add-ons.mozilla.com' does not match target host name '63.245.209.16' All looks good to me. Things to 63.245.209.16 are being sent the '*.add-ons.mozilla.com' wildcard SSL certificate, which is correct. Should be fine to swap DNS. Thanks.

Updated - *.add-ons IN CNAME wild.add-ons.nslb.sj.mozilla.com.

Re-opening as per bug 407164. Added non-https vserver, need QA signoff.

boo... I should have tested http://, too, but I didn't think about it since Firefox 3 only uses https://. oh well. :/

Punting back to the queue for oncall to deal with next week (I'm very remote). :80 and :443 work for me. Would like someone else to verify - morgamic?

Both https://en-us.add-ons.mozilla.com/en-US/firefox/ and http://en-us.add-ons.mozilla.com/en-US/firefox/ (http/https, respectively), work for me using Safari 3.04 (523.12.9). I do get a warning about the cert, but am able to "Continue"--the default option--and all is well; still supposing we don't want any warning at all on production server, natch?

(Vice-versa on the server/scheme, sigh; typos--)

Retrying... changed DNS. *.add-ons.mozilla.com -> wild.add-ons.nslb.sj.mozilla.com as of right now.

Both Opera 9.25 and Safari 3.04 on OS X 10.5 load fine for me using the URLs in comment 28; calling this verified. Not sure if Reed has other browsers that fail; these use to issue a cert warning for me consistently.