Your problem boils down to the following:
- Client shows $v$ (his certificate).
- Server wants to know whether $v$ is the same one as previously. He may store $v$ itself, but $v$ is somewhat bulky, so the server would like to store $h(v)$ only, for a hash function $h$.
So can an attacker show up with a value $v'$, distinct from $v$, such that $h(v') = h(v)$ ? If the attacker can, he wins. If he cannot, then storing $h(v)$ is sufficient.
If the hash function is second preimage resistant, then, by definition, the attacker cannot. SHA-256 is believed to be second preimage resistant.
I must also insist that the certificate is only the public part; the server must still extract the public key from the certificate sent by the client, and use it to verify the signature sent by the client as part of the
ClientKeyExchange handshake message. Normally, the SSL implementation takes care of that point.
An edge case happens with DSA public keys. A DSA public key contains some parameters (modulus $p$, subgroup order $q$, generator $g$) and the actual user-specific public value ($y$). It is allowed, as per X.509, to omit the parameters from the certificate, keeping only $y$, if the certificate is signed by a CA which also uses DSA with the same parameters. This is parameter's inheritance. This is not compatible with your idea, because the client's public key cannot then be extracted from the user's public key alone; you still need X.509 path validation. But, in practice, this won't happen: nobody really uses DSA certificates, let alone DSA with parameter inheritance.