网站 PKSC #11 智能卡身份验证和 SSL 客户端证书 [英] Website PKSC #11 smart card authentication and SSL client certificates

查看:39
本文介绍了网站 PKSC #11 智能卡身份验证和 SSL 客户端证书的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

由于一个斯堪的纳维亚国家/地区的法律要求,我们正在为网站创建三因素身份验证.客户正在使用 NetID 品牌浏览器插件在浏览器中执行 PKCS #11 证书身份验证.智能卡由客户的合作伙伴集中提供.

We are creating a three-factor authentication for a website due to a legal requirements in one Scandinavian country. The customer is using NetID branded browser plug-ins to do a PKCS #11 certificate authentication in the browser. The smartcards are supplied centrally by a partner on the customer.

该主题没有太多可用的在线资源或教程.有人会提供有关如何在 Web 浏览器中进行 PKCS11 身份验证的示例实现或教程的任何指示吗?

This subject does not have much on-line resources or tutorials available. Would someone have any pointers to example implementations or tutorials how to do PKCS11 authentication in a web browser?

发现 SSL 客户端证书

Found about SSL client certificates

  • 貌似认证方式是 SSL Client Certificate

  • Looks like the authentication method is SSL Client Certificate

我们如何管理用户与其智能卡之间的关系?

How do we manage relationship between users and their smartcards?

用户是否向我们提供了他们的公钥并且我们对他们进行了身份验证?

Do users deliver us their public keys and we authenticate against them?

我们是否需要使用我们自己的证书单独签署/提供每个用户?

Do we need to sign / provision each user individually using our own certicate?

是否所有用户智能卡都包含我们针对提供商证书进行测试的通用"密钥?

Do all user smartcards contain a "generic" key which we test against a provider certificate?

http://www.garex.net/apache/

http://www.impetus.us/~rjmooney/projects/杂项/clientcertauth.html

https://en.wikipedia.org/wiki/PKCS11

https://service.secmaker.com/examples/plugin.aspx

推荐答案

不要使用 JavaScript.JavaScript 密码学有很多问题,我认为很多浏览器都不会让你访问 PKCS#11 直接从 JavaScript(在页面内运行)轻松.

Don't do it with JavaScript. JavaScript cryptography has a number of problems, and I don't think many browsers will let you access the PKCS#11 directly from JavaScript (running from within the page) easily.

许多浏览器支持 PKCS#11 进行 HTTPS 身份验证,即使用 PKCS#11 作为 SSL/TLS 连接的一部分(作为 HTTPS 的一部分)进行客户端证书身份验证.

A number of browsers support PKCS#11 for HTTPS authentication, that is, using PKCS#11 for client-certificate authentication as part of the SSL/TLS connection (as part of HTTPS).

假设您已经有一个可用的 PKCS#11 库(比如 /usr/lib/opensc.so 中的 OpenSC),您可以配置 Firefox 来使用它:

Assuming you already have a PKCS#11 library available (let's say OpenSC in /usr/lib/opensc.so), you can configure Firefox to use it:

  • 首选项 -> 高级 -> 加密,进入安全设备"
  • 点击加载"
  • 选择一个模块名称(供您在列表中参考)并指向 /usr/lib/opensc.so 文件(或任何适合您的 PKCS#11 模块).
  • Preferences -> Advanced -> Encryption, go in "Security Devices"
  • Click on 'Load'
  • Choose a module name (for your own reference in the list) and point to the /usr/lib/opensc.so file (or whatever the appropriate PKCS#11 module is in your case).

然后,当您连接到请求客户端证书的网站时,浏览器应让您从支持 PKCS#11 的设备中选择一个证书.

Then, when you connect to a website that requests a client certificate, the browser should offer you to choose a certificate from the PKCS#11-enabled device.

PKCS#11 配置机制会因浏览器而异,但通常是设置 PKCS#11 模块的路径.

The PKCS#11 configuration mechanism will vary from one browser to another, but it's usually a matter of setting the path of the PKCS#11 module.

据我所知,Internet Explorer 不使用 PKCS#11(至少在没有额外支持的情况下不会),而是应该依赖 MS CryptoAPI 和 InfoCards.

As far as I know, Internet Explorer doesn't use PKCS#11 (at least not without extra support), but should rely on MS CryptoAPI and InfoCards instead.

在服务器端,您需要配置客户端证书身份验证的要求.没有特定于 PKCS#11 的内容.

On the server side, you will need to configure the requirement for client-certificate authentication. Nothing specific to PKCS#11 there.

在编辑之后,您应该阅读有关证书颁发机构 (CA) 和公钥基础设施 (PKI) 的内容.您可以部署自己的内部 PKI,但听起来您的要求是与现有 PKI 集成.这主要是一个管理问题,因此请与提出此要求的人核对一下,看看他们想要依赖哪个 CA(可能是他们的).

Following your edit, you should read about Certification Authorities (CAs) and Public Key Infrastructures (PKIs). You could deploy your own internal PKI, but it sounds like your requirements are to integrate with an existing PKI. This is an administrative problem mainly, so check with those making this requirement to see on which CA they want to rely (probably theirs).

在使用客户端证书认证时,客户端将出示其证书(其中包含用户的公钥和其他属性,包括一个标识符:主题识别名)并且 SSL/TLS 握手将确保客户端拥有私有证书此公钥证书的密钥.然后,服务器根据它信任的 CA 验证此证书(这也是服务器端的 SSL 设置).

When using client-certificate authentication, the client will present its certificate (which contains the user's public key and other attributes, including an identifier: the Subject Distinguished Name) and the SSL/TLS handshake will ensure that the client has the private key for this public key certificate. Then, the server verifies this certificate against CAs it trusts (that's also an SSL setting on the server side).

一旦您配置了您想要信任的 CA,如果需要,通常会使用证书的主题 DN 来完成映射到内部用户名.对此没有硬性规定,因为这取决于您的内部用户命名方案.话虽如此,使用完整的主题 DN 作为用户名通常是明智的.

Once you've configured which CAs you want to trust, the mapping is usually done using the certificate's Subject DN to an internal user name if needed. There is no hard rule for this, since it depends on your internal user naming scheme. This being said, it's often sensible to use the full Subject DN as the user name.

这篇关于网站 PKSC #11 智能卡身份验证和 SSL 客户端证书的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆