The issue is that the SSL certificate is used to encrypt the session key and transmit it to the server. That means that the corresponding key can recover the session key (which is a requirement, since the server has to know the session key to talk to the browser).
If you capture the entire SSL session and later recover the key from the webserver you could go back and decrypt the session.
Note that a CA breach doesn't help with this - the key is stored on the webserver and is used to generate a CSR - it never leaves the server in a good implementation. Apache at least lets you store it encrypted on-disk as well (which requires providing the password when you start the web server).
I'm not certain this would work, but I'd think the way that you could prevent this attack would be to have the webserver not actually give the client its certificate, but instead generate and sign a new certificate for each connection, and then give that certificate to the browser. It would still have a valid trust chain so it would be usable, but it would have a different private key. The webserver would then discard that private key after the session is complete so that nobody could go back and decrypt the session. Right now server certificates cannot be used to sign additional certificates, so that would need to change to make this work.