Brief bits from the evolving ipsCA failure

January 1, 2010

Some bits on various aspects of the ipsCA root certificate failure.

First, I've seen comments that the new ipsCA CA root certificate should be included in the next update of Firefox. However, I've now found the Mozilla bug about this (via Jeff Ballard), and it makes it seem very unlikely that the root certificate is going to be included in the near future (especially as ipsCA apparently had problems even before this). Interested people can watch Mozilla's CA:Schedule wiki page.

(Here I pause to admire the very long list of CAs asking for inclusion in Firefox et al. I admit that it makes me vaguely nervous. Also, since I just looked this up, it appears that the certificate list for Firefox is in security/nss/lib/ckfw/builtins/certdata.txt in the Firefox source tree. When built, it is embedded in the NSS shared library or DLL.)

Due to this I now have a useful pointer to a bunch of SSL resources. Looking at the complicated procedure for verifying SSL certificate chains makes me wish for a simple utility that read all bundled SSL certificates including in a SSL handshake and then reported any surprise in the Not After expiry dates (chained certificates should never expire in the wrong order, where a certificate 'up' the chain expires before your SSL certificate).

(Then you'd want to configure all of your machines to include the full certificate chain for your CA in their SSL responses.)

So far I am somewhat surprised by how little turmoil and noise there has been about this. If there's going to be much, it may start on January 4th when a lot of universities start up again after the Christmas break. (After all, it was entirely coincidence and luck that I found out about this when I did.)

(Interestingly, Twitter is much more active about this than than the bits of the blogosphere that I can easily search. This may mean something.)


Comments on this page:

By Dan.Astoorian at 2010-01-01 12:48:56:

(chained certificates should never expire in the wrong order, where a certificate 'up' the chain expires before your SSL certificate).

I'm not completely certain that this is true.

As you've noted previously, certificates expire, but keys do not, and certificates are signed using keys. As far as I know, this means that if there is a certificate chain

   C_0 -> C_1 -> C_2

where C_n is signed by the key K_(n-1) contained in C_(n-1) , there is no reason why a new certificate C'_n containing the same key as C_n but with a later expiration date could not be issued.

Thus, if my website has a certificate C_2, signed by K_1 contained in C_1, and C_2 expires in 2020, but C_1 expires in 2012, then (unless I've missed something) my certificate C_2 is fine if a new C'_1, containing the same key as C'_1, is issued by 2012 and installed in my website's certificate bundle.

This means that in theory, existing ipsCA certificates could be made valid again by re-issuing a new CA certificate to replace the one that just expired; I don't specifically know why this isn't being done, but I can think of some good reasons why it wouldn't be. (For one thing, extending the lifetime of an SSL key gives attackers more time to break it.)

I'm not claiming it's normal or even necessarily ever a good idea to issue certificates that expire after the issuing certificate; I'm just saying that I'm not convinced that it's never valid to do so.

I agree that it would make a lot of sense, however, if SSL utilities reported the "effective" expiry time of a certificate based on the expiry of certificates in the chain as well as the certificate's own Not After timestamp, if they are not the same.

--Dan

By cks at 2010-01-02 00:18:05:

An administrative note: after thinking about the issue, I've decided that I don't want to carry comments suggesting specific alternative SSL vendors on these entries, and I will quietly remove any such comments that are posted. No offense is intended to well-meaning (would-be) commentators.

Written on 01 January 2010.
« Why free things are so attractive in universities
Proper disclosure, or how not to be a comment spammer »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Fri Jan 1 02:58:34 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.