If an attacker has access only to the "live" database (most commonly via SQL injection), then encrypting the fields using some secret not stored in the database is enough - even some hard-coded secret key in the application code or configuration file. There's no need to use per-client keys.
If you're worried an attacker could somehow access the data at your web root, but not the rest of the filesystem (common if your server is misconfigured to allow browsing its web root contents), nothing changes - afterall, your server code or configuration file should be outside the web root, right? (I have little experience with PHP, so I might be wrong about this)
If your concern is an attacker getting hold of the whole filesystem, then you should ensure the key only exists in RAM. One way of doing that would be requiring a password to be entered at server (re)start, and keeping the derived key in a globally accessed variable (again, I dunno if it's possible with PHP). There might be other options, but any I can think of would introduce other points of failure.
I was thinking of generating the certificates on registration and use part of the footprint of a certificate to encrypt the user's data. so the SHA1 or MD5 footprint could do as key and IV.
Using anything from the certificate is a bad idea, since certificates are by definition public (the private parts never leave the user machine). If you could somehow have the user decrypt some data using his private key (something that AFAIK is not widely supported right now, but could be in the future), client-side, then you might be up to something... But the way things are now, you could simply create a random key for each user and have your application code read it (from a secure place) and apply it to the user data before inputting/outputting it.
This, of course, assumes you need to isolate one user's data from the other users. If that's not the case, a single global key might suffice, as described in the first part of this answer.
(one last note: you haven't mentioned the method you plan to use to encrypt data. If you're using a stream cipher, for instance, having a single IV for each user is not enough - you need to have a different one for each datum you want to protect. It doesn't matter though how you store them, since they're not supposed to be confidential, just unique. There are ways to make a single IV useable for encrypting a lot of data, but that's beyond my current knowledge, so I won't opinate on them.)
: Just to name one, you could derive an encryption key from the user password, store it in a (secure) session cookie, and pass it back-and-forth from server to client. Since it's not stored anywhere, an attacker won't gain access to it even if he got hold of the whole server (assuming of course your site properly salts and hashes passwords and the authentication key and encryption key are independent of each other). For some defense-in-depth, you could even combine that key with one stored only in the server. The obvious downside is that part of your system security now depends on the user browser, and also the way session cookies are handled both in the server and the client.