MIT CA certificate should be managed by update-ca-certificates

[andersk]

The current debathena-ca-certificates package links mitCA.pem directly into /etc/ssl/certs and runs c_rehash. However, many applications miss the new CA because they only look at /etc/ssl/certs/ca-certificates.crt, which is a bundle of certificates managed by update-ca-certificates.

A better way to install the CA is to package it as /usr/share/ca-certificates/mit.edu/mitCA.crt, and run dpkg-reconfigure ca-certificates. This will prompt the user to trust the new CA, upon which it will be linked into /etc/ssl/certs and added to /etc/ssl/certs/ca-certificates.crt.

We should figure out how to make this happen without prompting the user, while still preserving other changes to ca-certificates and allowing clean uninstallation.

[andersk]

We should also include the new CRL from  http://ca.mit.edu/mitca.crl. It can be installed in the same way; it ends up getting symlinked to /etc/ssl/certs/f066f19f.r0. Then we’ll want a cron job to check for CRL updates so we can update the package.

From: Jeffrey I. Schiller <jis@MIT.EDU>
To: Anders Kaseorg <andersk@MIT.EDU>
Cc: scripts-moira@MIT.EDU
Subject: Re: One of your Certificates is Compromised [help.mit.edu #629346]
Date: Sun, 18 May 2008 17:15:39 -0400

Thanks. I didn't check to see if a new certificate had been issued. I
have published a CRL at http://ca.mit.edu/mitca.crl (I believe it can
be references via https as well, but it is a signed object so this
isn't necessary).

Of course if people don't import this CRL into their browser, it
doesn't do much good (though once imported into Firefox, it will be
automatically updated if the user sets it that way).

                        -Jeff

[broder]

It looks like this was fixed in mid-February, modulo the CRL, which has special issues of its own. Let's track those under a separate bug.