Bug 404362 and bug 401923 both use subdomains under the *.addons.mozilla.org suffix. A wildcard SSL certificate needs to be purchased in order to support these new subdomains completely, as using the *.mozilla.org wildcard SSL certificate for them is in violation of RFC 2818 (bug 159483). Note that this is becoming an issue with Firefox, too, as bug 159483 has a patch, is sg:want (security group wants it), and blocking1.9 (blocking for final release of Firefox 3) has been requested.

need a csr...oremj, can you generate it?

You might want to double check this csr.

cert & key added to netscaler.

Thanks for the quick response on this guys. Now, can we get facebook.addons.mozilla.org and services.addons.mozilla.org to use this new wildcard cert instead of (ab)using the *.mozilla.org cert? Otherwise, this new cert isn't being used. :)

Is there a way to test the switch before the actual switch to make sure we don't screw over users?

Also: services.addons.mozilla.org is an alias for addons.mozilla.org So no change to do there. Not sure what that is anyways.

(In reply to comment #6) > Also: services.addons.mozilla.org is an alias for addons.mozilla.org > > So no change to do there. Not sure what that is anyways. SSL certificates don't work that way. They don't accept the value of a CNAME as what to use for hostname matching, so it's still going to try to compare services.addons.mozilla.org against *.mozilla.org and fail. I think you'll probably need to create a separate vip for this (addons-services-ssl?) so that you can use a separate SSL certificate for this host. As far as what services.addons.mozilla.org is going to be used for, check out bug 404362.

When services.addons goes live, we'll add the right cert/ip then. I'll leave it to webdev to let me know when it's ready.

So, facebook.addons isn't actually being used per fligtar, so I swapped it out. I tested and it works. Yay for buying certs and doing work for sites that aren't even in use (both facebook and services). Let's not do this again.

We should set this up so nightly users can test services.addons.mozilla.org without the Fx3 SSL exception dialog. I don't see a reason to delay adding the cert since release is in the near future and we need to have an arbitrarily large audience use this -- thoughts?

Mike, just to clarify - services.amo needs SSL right?

Yes: https://services.addons.mozilla.org/

Attaching CSR. -----BEGIN CERTIFICATE REQUEST----- MIICPjCCAacCAQAwgcsxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh MRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRwwGgYDVQQKExNNb3ppbGxhIENvcnBv cmF0aW9uMSQwIgYDVQQLExtzZXJ2aWNlcy5hZGRvbnMubW96aWxsYS5vcmcxJDAi BgNVBAMTG3NlcnZpY2VzLmFkZG9ucy5tb3ppbGxhLm9yZzElMCMGCSqGSIb3DQEJ ARYWaG9zdG1hc3RlckBtb3ppbGxhLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAybYZMQ92gkMRAsw3JTzPr//apq9rCJUPQwpW7/630v015fqKGzrhhVBY shusHbOglwDHRTcNV2fc+sXgUhQy8/kamPsbgbvIz873gPXE7UZeq4pfX63VEeNq otdxRNflIrqXIjhBYRHPbGg+Dtz0Zl3GJNQMOLIPeDTFuncThusCAwEAAaAyMDAG CSqGSIb3DQEJDjEjMCEwEQYJYIZIAYb4QgEBBAQDAgZAMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEAk+Xmq5778R3f4/TtHHeW+XBu14rDHNnzBKtASMCF eRQKkIuRRpTjyvJmpFM9eFlLbWXRrIWxEuXz4oniBarI/hkqiesk1HULuyp9ED5A 7M0duThXr+lOmQ3pKgE//TV2/gAfaAsDREWIlP3EcLl8Tjten1Vvw128IqcaZAa7 zzI= -----END CERTIFICATE REQUEST-----

(In reply to comment #13) > Attaching CSR. You already have a certificate, as per comment #3... No need to get a new one.

(In reply to comment #12) > Yes: > https://services.addons.mozilla.org/ Do you -only- need https or do you also need :80 open?

Site is up @ 63.245.209.15, https only. Looking for webdev signoff before flipping DNS.

We could leave 80 open as a redirect to 443/https as a convenience thing. Any objections? Other than that, we're set. Thanks for setting this up.

Added. Scheduled for Thursday night.

updated - services.addons IN CNAME dyna-services-amo.nslb.sj.mozilla.com.

Thanks Reed!

Host services.addons.mozilla.org not found: 3(NXDOMAIN) Host dyna-services-amo.nslb.sj.mozilla.com not found: 3(NXDOMAIN) Umm... mconnor/Mossop: This is why "Get Add-ons" isn't working right now.

Upping severity based on comment 21; unless there's another way to resolve that issue, we need this fixed ASAP so that our testers can continue their testing work. Also, it puts a firm deadline on the fix for Feb 4, which is when we start handing builds to QA for testing.

Error in the mozilla.com zone, wasn't loading changes. Fixed and verified - host dyna-services-amo.nslb.sj.mozilla.com dyna-services-amo.nslb.sj.mozilla.com has address 63.245.209.15 [root@mradm01 external]# host services.addons.mozilla.org services.addons.mozilla.org is an alias for dyna-services-amo.nslb.sj.mozilla.com. dyna-services-amo.nslb.sj.mozilla.com has address 63.245.209.15