Ecrivez-vous les certificats (et avez-vous la possibilité de définir certains champs du certificat)? Est-ce que ces certificats doivent être intégrés à un environnement PKI à plus grande échelle comme la signature d'email (je veux dire vous avez le cauchemar d'interopérabilité X.509)?
Si vous pouvez créer une autorité de certification pour les utilisateurs et que vous ne devez pas vous soucier des systèmes étrangers, vous pouvez attribuer à chaque certificat client un attribut de nom commun qui correspond directement à votre compte d'utilisateur. Ainsi, vous pouvez vérifier si le certificat client est signé par l'autorité de certification utilisateur, puis correspondre à l'attribut CN du certificat. Lorsque le nombre de certificats de signature est limité et bien connu, je recommande de stocker ces certificats et de vérifier les certificats clients et de les accepter uniquement s'ils sont signés par l'un des certificats de signature. Ensuite, vous utilisez un champ du certificat que l'autorité de certification émet pour chaque utilisateur (qui reste identique lorsque le certificat utilisateur est renouvelé, de nombreuses coopérations permettent aux certificats utilisateur d'expirer après environ un an) pour connecter ce champ à votre base de données utilisateur.
Si vous ne pouvez pas émettre les certificats, vous pouvez stocker le haché du certificat dans la base de données, mais cela présente l'inconvénient que lorsqu'un certificat est obsolète, vous devez mettre à jour la base de données. Le hachage est unique à chaque certificat, tandis que la plupart des champs d'un certificat peuvent être usurpés. Vous pouvez également vérifier les listes de révocation de certificats pour les autorités de certification de signature, de sorte qu'aucun utilisateur ne peut accéder à votre service avec un certificat volé.