Patrick, How do you expect to get the fingerprint from the client, after the first time you've recieved the certificate & validated it?
If the client has to send you the certificate, and all you do is just extract the fingerprint without the cryptographic checks, then I can pretty much send you any certificate blob with the right fingerprint and gain access. If you do attempt to verify the certificate again, then why bother with checking the fingerprint? If you just accept the fingerprint from the client without a certificate, how do you know it is from an authentic client? I think a goal of the fingerprint was to allow human beings to check the ownership of a certificate, out of band; to substitute regular cryptographic checks with something like just comparing fingerprints would defeat the purpose of the certificate in the first place; wouldn't you agree? Arshad Noor Patrick wrote: > > This may be a repeat: > > I'm a server app and after I authenticate a client the standard NSS way > (i.e., check issuer is trusted + check cert is signed by issuer + check > cert's validity period + check CRL?), I record the client cert's fingerprint > (20 bytes if using SHA-1 on digital signature). How safe is it to then use > this > fingerprint for subsequent authentication, or positive id of the client for > access control? I understand that the standard way has you look at the CN > for this but I want to make sure that the client presents the same *same > cert* everytime, and the fingerprint seems to be the best way to id a > *specific* cert... > > -- P
