408952 - Various machines need the new *.mozilla.org wildcard SSL certificate

Status: VERIFIED FIXED

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

Description

[Reed Loden [:reed]]

The *.mozilla.org wildcard SSL certificate is being swapped out for a newer (non-expiring) one on various hosts. https://build.mozilla.org uses it, but it's not behind the NetScaler, so it needs the certificate manually installed on the machine and apache restarted. mrz requested a bug for this, so I'm filing it.

Comment 1

[Justin Fitzhugh]

*.mozilla.org cert should not be on this box, as that private key should not be there.  Self-signed seems the way to go unless someone other than reed objects to using a self-signed cert.

Also, lists.mozilla.org needs the updated cert too.

Comment 2

[Reed Loden [:reed]]

Other hosts/machines that need the new wildcard SSL certificate:
* build.mozilla.org (dm-wwwbuild01)
* lists.mozilla.org (notorious)
* mail.mozilla.org (dm-mailman01)
* ldap.mozilla.org (pm-ns01/pm-ns02)
* despot.mozilla.org (recluse)
* doctor.mozilla.org (recluse)
* nagios.mozilla.org (dm-nagios01)
* ftp.mozilla.org (dm-ftp01)
* archive.mozilla.org (dm-ftp01)
* hg.mozilla.org (dm-svn01/dm-svn02)
* svn.mozilla.org (dm-svn01/dm-svn02)

Comment 3

[Reed Loden [:reed]]

(In reply to comment #1)
> *.mozilla.org cert should not be on this box, as that private key should not be
> there.  Self-signed seems the way to go unless someone other than reed objects
> to using a self-signed cert.

I object to using a self-signed certificate in this case because the Try Server tool is hosted on that machine (build.mozilla.org), so any developer (even non-MoCo) that would want to use it would have to accept the MoCo cert, which I don't think is fair to them. Also, links to builds under https://build.mozilla.org/tryserver-builds/ are publicly given out for users to test, so we should not require our users to accept MoCo-only SSL certificates. I can understand using the MoCo cert for internal things only, but this is for the community, not internal MoCo use.

Comment 4

[Justin Fitzhugh]

Why can't non-moco users accept our CA?  Seems like a very easy thing for people to do.  I don't think I said self-signed certs are for only internal things, but I still haven't heard a good reason not to use self signed certs other than "it's not fair", which I don't get.

Would love to hear anyone else *other* than Reed express an issue with this, indicating they care...I am happy to be wrong, but one user can't dictate policy, especially when efficiencies can be gained at little cost.

Comment 5

[Reed Loden [:reed]]

(In reply to comment #4)
> Why can't non-moco users accept our CA?  Seems like a very easy thing for
> people to do.  I don't think I said self-signed certs are for only internal
> things, but I still haven't heard a good reason not to use self signed certs
> other than "it's not fair", which I don't get.

Because most of these services are for community members in general, not just MoCo employees, and community members should not be forced to accept a MoCo-specific certificate (http://wiki.mozilla.org/MozillaRootCertificate), especially if those members aren't tied to MoCo at all. MoFo was around a long time before MoCo, and MoFo things shouldn't be tied to a MoCo-specific certificate, imho. There are many differences between MoFo and MoCo, and I'm sure any of the community projects would agree with me.

Why do we want to add another barrier-to-entry for community members, developers, etc. by requiring them to accept this certificate, especially since by just using the *.mozilla.org wildcard SSL certificate, things will JustWork(tm)? We already have enough barriers in comparison to other projects. Why add more when we can easily avoid them?

Also, the new *.mozilla.org SSL certificate mentions "Mozilla Corporation" instead of "Mozilla Foundation", which doesn't seem right. Seems like Mozilla Organization (mozilla.org) stuff, which is under MoFo, should say MoFo instead of MoCo. The old certificate used "Mozilla Foundation", so this is a change from the old.

On a completely separate note, self-signed SSL certificates have the stigma of not being "real" or "valid", and by using self-signed SSL certificates in more places, we're basically being hypocritical by publicly saying that people need to use valid real-CA-signed SSL certificates (as seen by our changes in behavior in Firefox 3) but doing a completely different thing for our developers/community by using self-signed certificates. We should not continue to do what we ask others not to do. It just makes us look bad.

MoCo is not a valid CA. MoCo has not undergone certification by a valid trust authority, as we demand any CA that wishes to have their certificate imported into Mozilla's certificate store (http://www.mozilla.org/projects/security/certs/policy/). Why do we not uphold the same standard for ourselves that we require of others by either 1) getting MoCo validated as a proper CA; or 2) using a validated CA for our SSL certificates.

> Would love to hear anyone else *other* than Reed express an issue with this,
> indicating they care...I am happy to be wrong, but one user can't dictate
> policy, especially when efficiencies can be gained at little cost.

You already own a wildcard SSL certificate for *.mozilla.org. You are replacing an old one with a new one. There is _no_ cost to you. You would still have to do the same amount of work (actually, *more* work!) to install a MoCo self-signed certificate for all the hosts. Why can't you just replace the old certificate with the new certificate?

In conclusion, there are several things that must be remembered when making a decision: A) there's no less work involved in just using the *.mozilla.org wildcard SSL certificate; B) it adds a barrier-to-entry by requiring that users add the MoCo root certificate to access sites; C) it makes Mozilla look bad by using self-signed certificates due to the stigma surrounding them; D) it hurts our outward pleas and discussions concerning the validity of SSL certificates by us not following the same standards we wish others to follow; E) MoCo isn't MoFo and should not be treated as such.

Comment 6

[Justin Fitzhugh]

Without rehashing the partially off-topic comment, responses to comment #5:

> A) there's no less work involved in just using the *.mozilla.org
 wildcard SSL certificate; 

Not true, the *.mozilla.org private key should not be on that box to start with, thus fixing an older problem.

> B) it adds a barrier-to-entry by requiring that users add the MoCo root certificate to access sites; 

Not sure if this is true, have heard the opposite from others, but would love opinions from someone other than Reed (think this is the third time I have said this in the bug)

> C) it makes Mozilla look bad by using self-signed certificates due to the  stigma surrounding them; 

Disagree - if you don't trust our CA, why trust our content or authentication.  Bogus.

> D) it hurts our outward pleas and discussions concerning the validity of SSL certificates by us not following the same standards we wish others to follow; 

There is a plea from mozilla for people not to use self-signed certs? Not sure why this would be and haven't seen it.

> E) MoCo isn't MoFo and should not be treated as such.
 
Er, MoCo is *part of* MoFo, owned by MoFo, so not sure what your point is here.

Would love to see if anyone else really cares about self-signed certs for build.mozilla.org other than Reed.  Suspect people don't, but it's open for comments :-)

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #5)
> In conclusion, there are several things that must be remembered when making a
> decision: A) there's no less work involved in just using the *.mozilla.org
> wildcard SSL certificate; B) it adds a barrier-to-entry by requiring that users
> add the MoCo root certificate to access sites; C) it makes Mozilla look bad by
> using self-signed certificates due to the stigma surrounding them; D) it hurts
> our outward pleas and discussions concerning the validity of SSL certificates
> by us not following the same standards we wish others to follow; E) MoCo isn't
> MoFo and should not be treated as such.

I can't speak to point A in this, but I'm in full agreement with Reed on the downsides of points B-E here.  It seems that this is a step towards undermining all the efforts of numerous developers in the Gecko 1.9 cycle to make security more meaningful.  As I understand the proposal in comment 1, to use or download a build from the try-server I (and anyone I point to said builds in a bug for testing) will get the "dead-stop" security error on the trunk, and will have to jump through hoops to get past the invalid certificate.  It sounds ridiculous reading/writing it now, and it sounds like mud in the face of Mozilla* if the proposed policy were to take effect and were the wider internet ever to get wind of it (simply by someone going to use a try-server build and encountering the invalid certificate error).

As for point E, there is already an undercurrent of concern among community projects and their supporters over "Mozilla Corp takeover of mozilla.org" (valid or not, the feeling is out there), and intermingling something as serious and authoritative as the SSL certificate would only further that concern.  mozilla.org predated MoCo, is a far larger entity than MoCo, and will long outlast MoCo, and to use mozilla.org services available to the entire mozilla.org community, we shouldn't have to accept a non-trusted CA or add an exception rule.

Comment 8

[Jesse Ruderman]

Certs are cheap -- even ignoring all the politics, they're cheaper than the time we'd waste when developers can't/don't use the try server or have to figure out how to install a certificate.

 If wildcard certs are expensive, there are plenty of alternative solutions that allow the use of normal certs: use separate boxes, or use multiple IPs on the same box, or use TLS SNI.  Requiring users to have up-to-date browsers (with support for TLS SNI) is much less of a burden than requiring users to install project-specific certs.

Comment 9

[matthew zeier [:mrz]]

(In reply to comment #8) 
> Requiring users to have up-to-date browsers
> (with support for TLS SNI) is much less of a burden than requiring users to
> install project-specific certs.

Larger burden is getting gear that supports SNI on the server side - Netscaler doesn't and Apache doesn't yet have it in a production version.  :)

Comment 10

[matthew zeier [:mrz]]

(In reply to comment #2)

These have been updated:

> * mail.mozilla.org (dm-mailman01)
> * ldap.mozilla.org (pm-ns01/pm-ns02)
> * despot.mozilla.org (recluse)
> * doctor.mozilla.org (recluse)
> * nagios.mozilla.org (dm-nagios01)
> * ftp.mozilla.org (dm-ftp01)
> * archive.mozilla.org (dm-ftp01)
> * hg.mozilla.org (dm-svn01/dm-svn02)
> * svn.mozilla.org (dm-svn01/dm-svn02)

This one is causing me Apache problems:
> * lists.mozilla.org (notorious)

Comment 11

[matthew zeier [:mrz]]

> This one is causing me Apache problems:
> > * lists.mozilla.org (notorious)

Fixed last night.

Comment 12

[matthew zeier [:mrz]]

Because I know it'll come up, build.mozilla.org is being handled in a seperate bug.

Comment 13

[Reed Loden [:reed]]

(In reply to comment #12)
> Because I know it'll come up, build.mozilla.org is being handled in a seperate
> bug.

Uh, what bug, as I originally filed this bug for that one host?

Comment 14

[Reed Loden [:reed]]

(In reply to comment #13)
> Uh, what bug, as I originally filed this bug for that one host?

Bug 408970, if anybody else cares.

My concerns have all been addressed, as self-signed certs were not used at all on any of these hosts, which was what I was trying to prevent. Thanks to all involved.