数字证书如何在SSL之上提供额外的安全性 [英] How Digital certificates provides extra security on top of SSL

问题描述

我的旧版应用程序位于https（SSL）上。最重要的是，我可以看到一些用户配置为使用由我自己的CA使用OpenSSL创建的
数字证书？有了这个，我得到了CAcert.pem和CAkey.pem，其中
用于为请求它的用户（通过CSR）创建数字证书。

My legacy Application is on https(SSL). On top of that i can see some users are configured to use digital certificates which are created by my own CA using OpenSSL? With this i have got CAcert.pem and CAkey.pem which are used to create digital certificates for user who requests for it(thru CSR).

我对
的理解是，每当用户（使用数字证书）尝试连接到服务器时，浏览器都会将已安装的数字
证书发送到服务器自动（问题是浏览器如何知道这是启用数字的用户，并且需要发送证书？）
并由服务器验证（谁负责验证服务器端的证书信息？）

我的最后一个问题是数字证书如何在SSL之上提供额外的安全性？

更新：-

正如您所说，数字证书是ssl必不可少的部分，与它不同证书从服务器
发送到客户端，其中包含公钥和有关浏览器信任的CA的信息。现在浏览器将发送带有公共密钥的加密数据
，并在服务器端使用私有密钥将其解密。同样，当服务器发送响应时，它将反向
，即在浏览器端用公钥加密并用公钥解密对吗？

As you said Digital certificates are essential part of ssl not different from it(where digital certificates are sent from server to client containing the publick key and information about the CA whom browser trusts). Now browser will send the data encrypted with public key which will be decrypted at server side with private key. Similarly when server send the response it will be reverse i.e encrypted with public key and decrypted with public key at browser side Right?

布鲁诺，您是对的，我实际上是想获取有关客户端证书的信息。
我也获得了带有客户端证书的证书，可以提供额外的安全性，因为becoz客户端必须接受来自服务器的相同身份验证强度。因此，即使密码被盗，但黑客也没有客户端证书。他不能继续。

Bruno, You are right i actually wanted to get the information about client certificates. I also got the with client certificate, extra security is provided becoz client is subjected to the same strength of authentication from the server. So even if the password is stolen, but hacker does not have client certificate. he can not proceed.

但是我不确定它是如何工作的。我对您的答案有一些
的想法，但我在OP中提出的问题仍然让我感到困惑。我会告诉你我的配置。我确定您可以帮助我。

But i am not sure how it works. I have got some idea with your answer but still questions i asked in OP still puzzles me. I will tell you my configuration. I am sure you can help me then.

我正在使用Tomcat Web服务器。这是我添加的server.xml中的代码段

I am using Tomcat webserver. Here is the snippet in server.xml i added

第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文件中的摘要下面添加了

Added below snippet in tomcat-users.xml file

<role rolename="certrole"/>
<user username="ignoreAndCheckInWebApp" password="nopass" roles="certrole"/>

步骤3
在web.xml的sniipet下面添加了

Step 3 Added below sniipet in web.xml

 <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文件夹中。

placed a jar file conatining MySSlAuthentication.java into the lib folder of Tomcat.

第4步
然后在tomcat\conftextcontext.xml下的Valve元素下方添加

Step 4 Then added below valve element under tomcat\conf\context.xml

 <Valve className="MySSlAuthentication"/>

所以它在 http://twoguysarguing.wordpress.com/2009/11/03/与客户端相互认证证书tomcat-6和httpclient / ，但是我无法理解步骤（为什么以及何时需要它们）以及它们如何相互链接？

So its more or less th eprocedure mentioned at http://twoguysarguing.wordpress.com/2009/11/03/mutual-authentication-with-client-cert-tomcat-6-and-httpclient/ but i am unable to understand the steps(why and when they are required) and how they are linked to each other ?

现在我的问题是：-

我无法关联步骤2、3和4。我想理解浏览器尝试连接到MyClientAuthenticator.jsp时会发生什么？我的理解是，当浏览器尝试调用MyClientAuthenticator.jsp时，服务器从浏览器询问客户端证书。但是第二步和第四步如何/何时出现？

I am not able to relate steps 2,3 and 4. I want to understand what happens when browser tries to connect to MyClientAuthenticator.jsp? My understanding when browser tries to call the MyClientAuthenticator.jsp, server asks the client certificate from browser. But then how/when step 2 and step 4 comes in to picture?

推荐答案

数字证书的方式在SSL之上提供额外的安全性？

How Digital certificates provides extra security on top of SSL?

通常，我不会说数字证书在SSL之上提供额外的安全性/ TLS。相反，它们是其中的重要组成部分。尽管PKI详细信息以及如何验证证书不是 TLS规范（RFC 5246）的一部分（为此还有一些其他规范，例如RFC 5280和RFC 6125），该规范本身明确地引用了大量证书以及应如何使用它们。

In general, I wouldn't say digital certificates provide "extra" security on top of SSL/TLS. Rather, they're an essential part of it. Although the PKI details and how to verify the certificates isn't part of the TLS specification (RFC 5246) (there are a couple of additional specifications for this, such as RFC 5280 and RFC 6125), the specification itself clearly references quite heavily certificates and how they should be used.

您似乎在谈论客户端证书，但您可能已经了解服务器证书，而服务器证书更为常见。

You seem to be talking about client certificates, but you probably already know about server certificates, which are far more common.

在两种情况下，证书的目的SSL / TLS用于对通信方进行身份验证，以便各方可以确保它正在与期望的远程方进行通信。

In both cases, the purpose of certificates in SSL/TLS is to authenticate the communicating parties, so that each party can be sure it's talking with the remote party it expects.

您应该始终至少拥有服务器证书（否则，该连接容易受到MITM攻击）。

You should always at least have a server certificate (otherwise the connection would be vulnerable to MITM attacks). This proves the identity of the server to the client.

除此之外，某些配置还希望客户端提供证书。由于您是在谈论用户使用其浏览器中的证书的情况，因此您似乎处于这种情况。

In addition to this, some configurations expect the client to provide a certificate. Since you're talking about users using their certificates from their browser, you seem to be in this situation.

在这种情况下，额外的安全性是使客户端受到保护与服务器来自客户端的身份验证强度相同。特别是，由于私钥在此过程中永远不会离开远程方，因此有助于防止因密码盗用而冒充他人（因为未传输密码）。在有关Security.SE的问题中有更多详细信息。

In this case, the extra security is that the client is subjected to the same strength of authentication from the server, as the server is from the client. In particular, since the private key never leaves the remote party in this process, this helps prevents impersonation by password theft (since no password is transmitted). There are more details in this question on Security.SE.

请求客户端证书是只能由服务器完成的事情。如果您的服务器被配置为这样做，它将在SSL / TLS握手期间向客户端（您的浏览器）发送一条消息，并且该消息通常将包含其信任的CA证书列表，以指示哪些客户端证书它愿意接受。 （在这种情况下，您的服务器很可能已配置为请求由CA颁发的客户端证书。）
您的服务器已被编码并配置为这样做（从您的问题中我不确定您是否正在使用Java Servlet容器或定制的Java服务器。）

Requesting a client certificate is something that can only be done by the server. If your server is configured to do so, it will send a message to the client (your browser) during the SSL/TLS handshake, and this message will normally contain a list of CA certificates it trusts, to give an indication of which client certificates it is willing to accept. (In this particular case, your server will most likely have been configured to request client certificates issued by your CA.) Your server will have been coded and configured to do so (I'm not sure from your question whether you're using a Java Servlet container or a bespoke Java server).

证书的验证由Java中的信任管理器完成。通常通过为应用程序提供信任存储并依赖默认 SSLContext 的默认行为（然后由默认 SSLSocket 或 SSLEngine 取决于您的应用程序的编码方式）。假设您的服务器使用默认的信任管理器，并且配置了包含您的CA证书的信任存储（并且还设置为请求证书），它将把该CA的名称发送到浏览器，而不是连接到它，它将还可以使用该CA来验证浏览器随后发送的证书。
（某些应用程序可能还具有自定义的信任管理器，但是其行为完全取决于编写的内容。）

The validation of the certificate is done by the trust manager in Java. This is often initialised transparently by providing the application with a trust store and relying on the default behaviour of the default SSLContext (then used by the default SSLSocket or SSLEngine depending on how your application is coded). Assuming your server uses the default trust manager and is configured with a trust store containing your CA certificate (and is also set up to request a certificate), it will send the name of that CA to the browsers than connect to it, and it will also use that CA to verify the certificate then sent by the browser. (Some applications may also have a customised trust manager, but then its behaviour depends entirely on what it was written to do.)

Java提供了两种方法申请证书：需要或想要（请参阅​​ SSLSocket.setNeedClientAuth（...） ）。区别在于，使用需要，如果客户端未出示用户证书，连接将停止，而在这种情况下，使用想要将继续连接。

Java provides two way of requesting a certificate: "need" or "want" (see SSLSocket.setNeedClientAuth(...)). The difference is that with "need", the connection will stop if the client didn't present a user certificate, whereas it will continue in this case with "want".

此后，服务器应用程序可以通过从 SSLSession 检查对等证书来检查用户的身份验证状态。 （如果客户端不发送证书，并且服务器使用了 want模式，它将不会获得任何对等证书。对于匿名访问，这可能很好。）
在此阶段（假设服务器应用程序已编码）如果使用正确的信任管理器（即不是虚拟的），则将确保服务器代码确保远程用户确实是与该证书匹配的私钥的持有者。然后，可以将证书的主题专有名称用作远程方的身份。 （某些服务器允许您根据需要将其与一组不同的用户名进行匹配。这取决于您使用的是哪个确切的服务器以及其配置方式。）

After this, the server application can check the authentication status of the user by checking the peer certificate from the SSLSession. (It won't get any peer certificate if the client didn't send one and the server used the "want" mode. This may be fine for anonymous access.) At this stage (provided the server application was coded with the correct trust manager, i.e. not a dummy one), the server code will be ensured that the remote user is indeed the holder of the private key matching that certificate. The Subject Distinguished Name of the certificate can then be used as the identity of the remote party. (Some servers allow you to match this to a different set of user names if necessary. This will depend on which exact server you're using and how it's configured.)

正如您所说，数字证书是ssl不可或缺的部分（数字证书是从服务器发送到客户端的，包含公钥和有关浏览器信任的CA）。现在，浏览器将发送使用公钥加密的数据，该数据将在服务器端使用私钥解密。类似地，当服务器发送响应时，它将反向执行，即在浏览器侧使用公钥加密并使用公钥解密对吗？

As you said Digital certificates are essential part of ssl not different from it(where digital certificates are sent from server to client containing the publick key and information about the CA whom browser trusts). Now browser will send the data encrypted with public key which will be decrypted at server side with private key. Similarly when server send the response it will be reverse i.e encrypted with public key and decrypted with public key at browser side Right?

否，无论是否使用客户端证书，都将使用握手期间协商的对称密钥在两个方向上对连接进行加密。客户证书与它无关。客户端证书仅在最后使用握手签名，以向服务器证明客户端具有此证书的私钥。

No, whether you use client certificates or not, the connection will be encrypted in both directions anyway, using a symmetric key negotiated during the handshake. Client certificate have nothing to do with it. The client certificate is only used to sign the handshake at the end, to prove to the server that the client has the private key for this certificate.

编辑中的详细信息似乎表明您使用的配置可能比平常复杂一些。

The details in your edit seem to indicate you're using a configuration that's probably a bit more complex than usual.

首先，您的 Connector 没有 clientAuth 属性（因此其默认值为false）。这意味着客户端证书不会在初次握手期间发生，而是在您尝试访问受保护资源时由第二次握手触发（根据您的 security-constraint 组态）。这称为重新协商，这并不稀奇。

Firstly, your Connector doesn't have a clientAuth attribute (so its default value is false). This implies that the client certificate will not happen during the initial handshake, but will be triggered by a second handshake when you try to access the protected resource (according to your security-constraint configuration). This is called re-negotiation, and it's not unusual.

（我还注意到它没有与信任库相关的设置，这意味着它使用的是默认设置JRE信任库，这也意味着您的自定义CA证书必须已明确导入到该信任库中（通常为 cacerts ）。如果升级JRE，请记住这一点，因为

(I've also noticed that it doesn't have truststore-related settings, which implies it's using the default JRE truststore, which also implies that your custom CA certificate must have been imported explicitly into that truststore (cacerts in general). Keep this in mind if you upgrade your JRE, since you're probably have to import that cert there manually again.)

您的 tomcat-users.xml 配置是什么？我之前在谈论（关于将主题DN与用户名或角色进行匹配）。结合您的自定义阀门，这是您设置中的不寻常之处。

Your tomcat-users.xml configuration is what I was talking about earlier (about matching Subject DNs to user names or roles). This, combined with your custom valve is what's unusual in your settings.

我的猜测是该阀门会将任何有效证书映射到名为<$ c $的伪用户。 c> ignoreAndCheckInWebApp ，只是为了能够通过该安全性约束，尽管您的应用程序应该查看证书本身。

My guess would be that this valve maps any valid certificate to a pseudo-user called ignoreAndCheckInWebApp, just to be able to pass that security constraint, although your application would be expected to look at the certificate itself.

在更传统的情况下， tomcat-users.xml 中的用户名将是证书的主题DN，您可以通过这种方式将它们映射到角色。在这里，看来您的部署当时并不关心此映射，但是打算稍后在应用程序中进行检查。这可能意味着您的应用程序应直接依赖于 HttpServletRequest.getRemoteUser（）（除非稍后还要由过滤器进行设置），但应使用<$ c读取证书$ c> javax.servlet.request.X509Certificate 属性。

In a more traditional case, the usernames in tomcat-users.xml would be the Subject DNs of your certificates, and you would map them to roles this way. Here, it seems your deployment doesn't care about this mapping at that point, but is meant to check this within your application later. This probably means that your application should directly rely on HttpServletRequest.getRemoteUser() (unless it's also set up by a filter later), but should read the certificate using the "javax.servlet.request.X509Certificate" attribute from the request.

如果应用程序执行了所有这些操作，这将很有意义正确地。我在这里所说的确实是一个猜测，因为这完全取决于Tomcat阀门的实现方式。这肯定会影响您获得的远程用户名和用户主体。

This can make sense if the application does all of this correctly. What I'm saying here is really a guess, since it depends entirely on how the Tomcat valve is implemented. This will certainly affect the remote user name and user principals that you get.

关于您对ActiveX和IE的评论，客户端-certificate身份验证也可以在Firefox或Chrome上正常运行。我想到两件事：

Regarding your comments about ActiveX and IE, client-certificate authentication should also work fine with Firefox or Chrome. Two things come to mind:

• 该ActiveX代码可能与客户端证书无关，但是可能是应用程序的一部分


• 该ActiveX代码是您自己的CA的一部分，是一种让您的用户从其浏览器内申请证书的方式（如果他们还没有的话） 。也许这只是为IE实现的，尽管也可以在Firefox或其他浏览器上完成。

• That ActiveX code may simply have nothing to do with client certificates, but may be part of the what the application is meant to do.
• That ActiveX code is part of your own CA, as a means to let your users apply for certificates from within their browsers (when they don't already have one). Perhaps this was only implemented for IE, although it could be done for Firefox or other browsers too.

这篇关于数字证书如何在SSL之上提供额外的安全性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！