将客户端证书映射到用户帐户的最佳实践是什么？
我们有一个专有的框架，现在我们希望通过客户端 ssl 证书集成身份验证。 将客户端证书映射到专有用户帐户（例如数据库中的简单用户表）的最佳实践是什么？
- 保存到证书的公钥？
- 保存发行者和序列号？
或者还有其他的可能性吗？
We have a proprietary framework and now we want to integrate the authentication by client side ssl certificates.
What are the best practices to map a client certificate to a proprietary user account (for example a simple user table in the database)?
- Save to public key of the certificate?
- Save issuer and serialnumber?
Or are there other possibilities?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您是否正在颁发证书（并且可以设置证书的某些字段）？这些证书是否必须与更大规模的 PKI 环境（如电子邮件签名）集成（我的意思是，您是否面临 X.509 互操作性噩梦）？
如果您可以为用户创建证书颁发机构，并且不必关心外部系统，则可以为每个客户端证书提供一个直接映射到您的用户帐户的通用名称属性。因此可以检查客户端证书是否由用户证书颁发机构签名，然后匹配证书 CN 属性。
当只有有限且众所周知的签名证书数量时，我建议存储此证书并检查客户端证书，并且仅当它们由其中一个签名证书签名时才接受它们。然后，您使用颁发 CA 为每个用户唯一设置的证书字段（在更新用户证书时保持不变，许多合作允许用户证书在大约一年后超时）将此字段连接到您的用户数据库。
如果您无法颁发证书，您可以将证书的哈希存储在数据库中，但这有一个缺点，即当证书过期时，您需要更新数据库。每个证书的哈希值都是唯一的，而证书的大多数字段都可以被欺骗。
您可能还需要检查签名证书颁发机构的证书吊销列表，以便任何用户都无法使用被盗的证书访问您的服务。
Are you issuing the certificates (and have a possibility to set some fields of the certificate)? Does these certificates have to be integrated with a larger scale PKI environment like email-signing (I mean have you the X.509 interoperability nightmare)?
If you can create a certificate authority for the users, and have not to care about foreign systems, you can give each client certificate a common name attribute which maps directly to your user account. So you can check if the client certificate is signed by the user certificate authority and then match the certificate CN attribute.
When there is only a limited and well known number of signing certificates then I recommend to store this certificates and check the client certificates and accept them only if they are signed by one of the signing certificates. Then you use a field of the certificate which the issuing CA sets uniquely for each user (which stays equal when the user certificate gets renewed, many cooperations let user certificates time out after about one year) to connect this field with your user database.
If you can't issue the certificates you can store the hash of the certificate in the database, but this has the drawback that when a certificate runs out of date you need to update the database. The hash is unique to each certificate, while the most fields of a certificate can be spoofed.
You may also want to check the certificate revocation lists for the signing certificate authorities, so no user can access your service with a stolen certificate.
我们存储客户端证书的序列号和颁发者 DN 并进行匹配。根据 http://www.tectia.com/manuals/server -admin/60/userauth-cert.html，这足以唯一标识证书。
We store the client certificate's serial and issuer DN and match it. According to http://www.tectia.com/manuals/server-admin/60/userauth-cert.html, this is enough to uniquely identify the certificate.