我的遗留应用程序位于https(SSL)上。最重要的是,我可以看到一些用户被配置使用 我自己的CA使用OpenSSL创建的数字证书?有了这个我有CAcert.pem和CAkey.pem 用于为请求它的用户(通过CSR)创建数字证书。
我对此的理解 是每当用户(使用数字证书)尝试连接到服务器时,浏览器发送已安装的数字 自动证书到服务器(问题是浏览器如何知道这是启用数字的用户,它需要发送证书吗?) 和服务器验证(谁负责验证服务器端的证书信息?)
我的最后一个问题是数字证书如何在SSL之上提供额外的安全性?
更新: -
正如您所说,数字证书是ssl必不可少的一部分(与服务器发送数字证书) 到包含publick键的客户端和有关浏览器信任的CA的信息。现在浏览器将加密数据发送 使用公钥,将使用私钥在服务器端解密。同样,当服务器发送响应时,它将是 反向,即用公钥加密,并在浏览器端用公钥解密对吗?
布鲁诺,你说得对,我其实想获得有关客户证书的信息。 我还获得了带有客户端证书,提供额外的安全性becoz客户端受到来自服务器的相同强度的身份验证。所以即使密码被盗,但黑客也没有客户端证书。他不能继续。
但我不确定它是如何运作的。我有一些 你的答案的想法,但我在OP问的问题仍然困扰着我。我会告诉你我的配置。我相信你可以帮助我。
我正在使用Tomcat网络服务器。这是我添加的server.xml中的代码段
第1步: -
<Connector
SSLEnabled="true"
acceptCount="100"
connectionTimeout="20000"
executor="tomcatThreadPool"
keystoreFile="c/.keystore"
keystorePass="changeme"
maxKeepAliveRequests="15"
port="443"
protocol="HTTP/1.1"
redirectPort="443"
scheme="https"
secure="true"
/>
第2步
在tomcat-users.xml文件中添加了以下代码段
<role rolename="certrole"/>
<user username="ignoreAndCheckInWebApp" password="nopass" roles="certrole"/>
第3步 在web.xml中添加了下面的sniipet
<security-constraint>
<web-resource-collection>
<web-resource-name>Client Certificate Auth</web-resource-name>
<url-pattern>/MyClientAuthenticator.jsp</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>certrole</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>
将一个包含MySSlAuthentication.java的jar文件放入Tomcat的lib文件夹中。
第4步 然后在tomcat \ conf \ context.xml
下添加下面的valve元素 <Valve className="MySSlAuthentication"/>
所以它在http://twoguysarguing.wordpress.com/2009/11/03/mutual-authentication-with-client-cert-tomcat-6-and-httpclient/提到的或多或少的程序,但我无法理解步骤(为什么以及何时需要它们)以及它们如何相互联系?
现在我的问题是: -
我无法将步骤2,3和4联系起来。我想了解当浏览器尝试连接到MyClientAuthenticator.jsp时会发生什么?我理解当浏览器尝试调用MyClientAuthenticator.jsp时,服务器会从浏览器询问客户端证书。但那么第2步和第4步是如何/何时进入图片的?
答案 0 :(得分:2)
数字证书如何在SSL之上提供额外的安全性?
一般来说,我不会说数字证书提供额外的&#34; SSL / TLS之上的安全性。相反,它们是它的重要组成部分。虽然PKI详细信息以及如何验证证书不是TLS specification (RFC 5246)的一部分(还有一些额外的规范,例如RFC 5280和RFC 6125),但规范本身明显引用了很多证书以及如何使用它们。
您似乎在谈论客户端证书,但您可能已经了解服务器证书,这些证书更为常见。
在这两种情况下,SSL / TLS中证书的目的是对通信方进行身份验证,以便每一方都能确定它与预期的远程方通话。
您应始终至少拥有服务器证书(否则连接将容易受到MITM攻击)。这证明了服务器对客户端的身份。
除此之外,一些配置希望客户端提供证书。由于您正在谈论使用浏览器证书的用户,您似乎处于这种情况。
在这种情况下,额外的安全性是客户端受到来自服务器的相同的身份验证强度,因为服务器来自客户端。特别是,由于私钥在此过程中永远不会离开远程方,这有助于防止密码被盗(因为没有密码被传输)冒充。 this question on Security.SE中有更多详细信息。
请求客户端证书只能由服务器完成。如果您的服务器配置为执行此操作,它将在SSL / TLS握手期间向客户端(您的浏览器)发送消息,并且此消息通常包含它信任的CA证书列表,以指示哪些客户端证书它愿意接受。 (在这种特殊情况下,您的服务器很可能已配置为请求CA颁发的客户端证书。) 您的服务器已经过编码和配置(我不确定您是否使用Java Servlet容器或定制的Java服务器)。
证书的验证由Java中的信任管理器完成。这通常通过为应用程序提供信任存储并依赖于默认SSLContext
的默认行为(然后由默认SSLSocket
或SSLEngine
使用,具体取决于您的应用程序的使用方式)来透明地初始化编码)。假设您的服务器使用默认信任管理器并配置了包含您的CA证书的信任存储(并且还设置为请求证书),它会将该CA的名称发送到浏览器而不是连接到它,它将也可以使用该CA来验证浏览器随后发送的证书。
(某些应用程序也可能有自定义的信任管理器,但其行为完全取决于它的编写内容。)
Java提供了两种请求证书的方式:&#34;需要&#34;或者&#34;想要&#34; (见SSLSocket.setNeedClientAuth(...)
)。不同之处在于,如果客户没有提供用户证书,那么连接将停止,而在这种情况下,连接将在&#34;想要&#34;。
此后,服务器应用程序可以通过检查SSLSession
中的对等证书来检查用户的身份验证状态。 (如果客户端没有发送任何对等证书,并且服务器使用&#34;想要&#34;模式,它将无法获得任何对等证书。这可能适用于匿名访问。)
在此阶段(假设服务器应用程序使用正确的信任管理器编码,即不是虚拟信任管理器),将确保服务器代码确保远程用户确实是与该证书匹配的私钥的持有者。然后可以将证书的主题专有名称用作远程方的标识。 (如果需要,某些服务器允许您将其与不同的用户名集匹配。这取决于您使用的服务器及其配置方式。)
正如您所说,数字证书是ssl必不可少的一部分(数据证书从服务器发送到客户端,包含publick密钥和有关浏览器信任的CA的信息)。现在浏览器将发送使用公钥加密的数据,该公钥将在服务器端使用私钥进行解密。同样,当服务器发送响应时,它将被反向,即用公钥加密,并在浏览器端用公钥解密对吗?
不,无论您是否使用客户端证书,无论如何都会使用在握手期间协商的对称密钥在两个方向上加密连接。客户端证书与它无关。客户端证书仅用于在最后签署握手,以向服务器证明客户端具有此证书的私钥。
您的编辑中的详细信息似乎表明您使用的配置可能比平常更复杂。
首先,您的Connector
没有clientAuth
属性(因此其默认值为false)。这意味着在初始握手期间不会发生客户端证书,但是当您尝试访问受保护资源时(根据您的security-constraint
配置),将由第二次握手触发。这称为重新谈判,并不罕见。
(我还注意到它没有与信任库相关的设置,这意味着它使用默认的JRE信任库,这也意味着您的自定义CA证书必须已明确导入进入该信任库(一般为cacerts
)。如果您升级JRE,请记住这一点,因为您可能需要再次手动导入该证书。)
您的tomcat-users.xml
配置就是我之前谈到的(关于将主题DN与用户名或角色匹配)。这与您的定制阀门结合在您的设置中是不寻常的。
我的猜测是,这个阀门将任何有效证书映射到一个名为ignoreAndCheckInWebApp
的伪用户,只是为了能够传递该安全约束,尽管您的应用程序应该查看证书本身。 / p>
在更传统的情况下,tomcat-users.xml
中的用户名将是证书的主题DN,您可以通过这种方式将它们映射到角色。在这里,您的部署似乎并不关心此映射,但是稍后要在您的应用程序中进行检查。这可能意味着您的应用程序应该直接依赖HttpServletRequest.getRemoteUser()
(除非它以后也通过过滤器设置),但应该使用请求中的"javax.servlet.request.X509Certificate"
属性读取证书。
如果应用程序正确完成所有这些操作,这是有意义的。我在这里说的真的是猜测,因为它完全取决于Tomcat阀门的实施方式。这肯定会影响您获得的远程用户名和用户主体。
关于您对ActiveX和IE的评论,客户端证书身份验证也应该适用于Firefox或Chrome。我想到了两件事:
答案 1 :(得分:1)
问题是浏览器如何知道这是启用数字的用户并且需要发送证书? )
浏览器发送它是因为服务器要求它,因为服务器配置为这样做。
谁负责验证服务器端的证书信息?
SSL实施负责。
数字证书如何在SSL之上提供额外的安全性?
作为SSL的一部分,您的意思是。他们安全地识别所有者,这使应用程序有机会决定该用户是否有权使用该部分应用程序。
重新更新
现在,浏览器将发送使用公钥加密的数据,该公钥将在服务器端使用私钥进行解密。同样,当服务器发送响应时,它将被反向,即用公钥加密,并在浏览器端用公钥解密对吗?
错误。加密和解密过程并不仅仅因为客户端提供了证书。真正发生的是客户端和服务器协商对称的会话密钥。不使用公钥 - 私钥加密。
1)浏览器如何知道何时必须发送客户端证书(AS EJP指出服务器要求它,但我不确定它在上述配置中的位置)。
由于这个原因,它要求它:
<auth-method>CLIENT-CERT</auth-method>
2)Whoz在服务器端验证客户端证书?是MySSlAuthentication吗?
与Connector关联的SSL实现验证客户端证书。你没有告诉我们MySSlAuthentication
是什么,所以我不能告诉你它是做什么的。