SSL双向认证和单向认证的区别是啥？

Posted 2023-04-26

您好！
1、单向认证只要求站点部署了ssl证书就行，任何用户都可以去访问（IP被限制除外等），只是服务端提供了身份认证。而双向认证则是需要是服务端需要客户端提供身份认证，只能是服务端允许的客户能去访问，安全性相对于要高一些。
2、双向认证SSL 协议的具体通讯过程，这种情况要求服务器和客户端双方都有证书。
3、单向认证SSL 协议不需要客户端拥有CA证书，以及在协商对称密码方案，对称通话密钥时，服务器发送给客户端的是没有加过密的（这并不影响SSL过程的安全性）密码方案。
4、如果有第三方攻击，获得的只是加密的数据，第三方要获得有用的信息，就需要对加密的数据进行解密，这时候的安全就依赖于密码方案的安全。而幸运的是，目前所用的密码方案，只要通讯密钥长度足够的长，就足够的安全。这也是我们强调要求使用128位加密通讯的原因。
5、一般Web应用都是采用单向认证的，原因很简单，用户数目广泛，且无需做在通讯层做用户身份验证，一般都在应用逻辑层来保证用户的合法登入。但如果是企业应用对接，情况就不一样，可能会要求对客户端（相对而言）做身份验证。这时就需要做双向认证。 参考技术A

SSL单向认证具体过程图解：

SSL双向认证具体过程图解：

双向认证SSL协议要求服务器和用户双方都有证书。单向认证SSL协议不需要客户拥有CA证书，具体的过程相对于上面的步骤，只需将服务器端验证客户证书的过程去掉，以及在协商对称密码方案，对称通话密钥时，服务器发送给客户的是没有加过密的(这并不影响SSL过程的安全性)密码方案。这样，双方具体的通讯内容，就是加过密的数据，如果有第三方攻击，获得的只是加密的数据，第三方要获得有用的信息，就需要对加密的数据进行解密，这时候的安全就依赖于密码方案的安全。而幸运的是，目前所用的密码方案，只要通讯密钥长度足够的长，就足够的安全。这也是我们强调要求使用128位加密通讯的原因。

一般Web应用都是采用SSL单向认证的，原因很简单，用户数目广泛，且无需在通讯层对用户身份进行验证，一般都在应用逻辑层来保证用户的合法登入。但如果是企业应用对接，情况就不一样，可能会要求对客户端(相对而言)做身份验证。这时就需要做SSL双向认证。

参考技术B 单向认证只要求站点部署了ssl证书就行，任何用户都可以去访问（IP被限制除外等），只是服务端提供了身份认证。而双向认证则是需要是服务端需要客户端提供身份认证，只能是服务端允许的客户能去访问，安全性相对于要高一些
双向认证SSL 协议的具体通讯过程，这种情况要求服务器和客户端双方都有证书。 单向认证SSL 协议不需要客户端拥有CA证书，以及在协商对称密码方案，对称通话密钥时，服务器发送给客户端的是没有加过密的（这并不影响SSL过程的安全性）密码方案。这样，双方具体的通讯内容，就是加密过的数据。如果有第三方攻击，获得的只是加密的数据，第三方要获得有用的信息，就需要对加密的数据进行解密，这时候的安全就依赖于密码方案的安全。而幸运的是，目前所用的密码方案，只要通讯密钥长度足够的长，就足够的安全。这也是我们强调要求使用128位加密通讯的原因。
一般Web应用都是采用单向认证的，原因很简单，用户数目广泛，且无需做在通讯层做用户身份验证，一般都在应用逻辑层来保证用户的合法登入。但如果是企业应用对接，情况就不一样，可能会要求对客户端（相对而言）做身份验证。这时就需要做双向认证。 参考技术C SSL单向认证只要求站点部署了ssl证书就行，任何用户都可以去访问(IP被限制除外等)，只是服务端提供了身份认证。
双向认证则是需要服务端与客户端提供身份认证，只能是服务端允许的客户能去访问，安全性相对于要高一些。本回答被提问者采纳 参考技术D SSL单向认证只要求站点部署了ssl证书就行，任何用户都可以去访问(IP被限制除外等)，只是服务端提供了身份认证。
双向认证则是需要服务端与客户端提供身份认证，只能是服务端允许的客户能去访问，安全性相对于要高一些。

https 单向认证和双向认证配置

HTTPS 是我们开发中经常用到的通信加密技术，能有效保护我们网络访问中的安全，本文主要讲解单向 和 双向 https 的配置。关于https 的实现原理在这里我就不赘述了，附上阮一峰老师的关于https介绍几篇博客，有兴趣的童鞋可以看一看：图解SSL/TLS协议   数字签名是什么？

本文目录：

1、单向https配置

2、双向https配置

3、常见名词说明(转载)

 

1.单向https 配置 

• 生成https证书命令：

  sudo keytool -genkey -keyalg RSA -dname "cn=localhost,ou=none,o=none,l=shanghai,st=shanghai,c=cn" -alias server -keypass 123456 -keystore server.keystore -storepass 123456 -validity 3650                                        

• 生成CSR文件 

  本文只是生成自签名的https证书，如果需要申请CA证书，就需要生成CSR文件，并将此文件提交给相应CA机构申请CA证书。
  

  sudo keytool -certReq -alias server -keystore server.keystore -file ca.csr -storepass 123456

• 生成CER文件
  

  因为我们生成的证书使用keytool生成的，没有经过操作系统可信任的CA机构颁发，所以当用浏览器访问时，会出现不信任证书警告，我们手工将cer文件（服务端公钥）导入浏览器的证书列表，让其信任。
  

  sudo keytool -export -alias server -keystore server.keystore -file ca.cer -storepass 123456

  
  

• 在Tomcat中配置Https证书

　　　在serve.xml 中添加如下配置，即可访问https的站点了。

<Connector SSLEnabled="true" clientAuth="false"
            keystoreFile="/Users/beiyan/Documents/test/server.keystore"
            keystorePass="123456" maxThreads="150" port="8443"
            protocol="org.apache.coyote.http11.Http11NioProtocol" scheme="https"
            secure="true" sslProtocol="TLS" />

　　　其中keystoreFile 为证书的地址，keystorePass 为证书的密码。

        访问界面如下:

          

• 导入CER文件，让浏览器信任此证书

  双击 ca.cer 即可导入，再设置为 始终信任 ，再次访问
  

• 应用程序访问

  如果使用HttpClient 等工具访问该Https连接时,需要讲ca.cer 导入jre中；
  命令如下：keytool -import -alias tomcatsso -file "ca.cer" -keystore "/Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre/lib/security/cacerts" -storepass 123456
  其中 /Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre 是jre目录 123456 是jre默认的密码
  

  2.双向https配置

• 生成Server端证书：

  sudo keytool -genkey -keyalg RSA -dname "cn=localhost,ou=none,o=none,l=shanghai,st=shanghai,c=cn" -alias server -keypass 123456 -keystore server.keystore -storepass 123456 -validity 3650

• 生成客户端证书:

  这里的客户端为浏览器，浏览器支持的证书格式为PKCS12，这里生成PKCS12格式的证书:
  

  sudo keytool -genkey -v -alias client -keyalg RSA -storetype PKCS12 -dname "cn=localhost,ou=none,o=none,l=shanghai,st=shanghai,c=cn"  -keypass 123456 -storepass 123456 -keystore client.p12 -validity 3650

• 让服务端信任客户端的证书

  由于是双向认证，服务端必须验证客户端的身份，所以需要将客户端的公钥导入到服务端的信任列表，但是这里生成的PKCS12文件不能直接导入，所以先导出成CER文件，再将CER文件导入服务端的证书库。
  1、将客户端证书导出为一个单独的CER文件
  

  sudo keytool -export -alias client -keystore client.p12 -storetype PKCS12 -storepass 123456 -rfc -file client.cer

  
  2、将CER文件导入服务端的证书库
  

  sudo keytool -import -v -file client.cer -keystore server.keystore

  
  3、查看server.keystore 里面的证书列表:
  

  sudo keytool -list -keystore server.keystore

  
  

  上图可以看到，证书库中包含两个证书，一个是服务端的私钥，一个是客户端的可信任公钥

• 让客户端信任服务端证书

  客户端也需要验证服务端的证书是否可靠，所以也需要将服务端证书的公钥导入客户端的信任列表。通用的做法是将服务器证书导出为一个单独的CER文件，然后双击安装到浏览器的证书列表即可。
  

  sudo keytool -keystore server.keystore -export -alias server -file server.cer -validity 36500

• 所有生成的证书列表如下:

  
  

  client.cer：客户端证书的公钥
  client.p12：客户端证书的私钥
  server.cer：服务端证书的公钥
  server.keystore：服务端证书库，既包含服务端私钥，又包含客户端公钥

• 修改Tomcat 配置：

       在serve.xml 中添加如下配置

•  

  <Connector SSLEnabled="true" clientAuth="true"
              keystoreFile="/Users/beiyan/Documents/test/keytool/server.keystore"
              truststoreFile="/Users/beiyan/Documents/test/keytool/server.keystore"
              truststorePass="123456" keystorePass="123456" maxThreads="150" port="8443"
              protocol="org.apache.coyote.http11.Http11NioProtocol" scheme="https"
              secure="true" sslProtocol="TLS" />

  clientAuth="true"表示双向认证

• 客户端安装私钥

  双击client.p12即可安装
  
  

  备注（这里是mac下面的设置方式，window 与此类似，双击进入安装界面） 

• 客户端安装服务端的公钥

  双击server.cer文件，设置同上
  
  

• 成功访问：

       弹出客户端证书选择界面,选择客户端证书，即可正常访问
       
                                              选择证书界面


         

                                       
3、jks,keystore,trustore,cer,pfx等名词说明zhuan(转自网络)

备注:此处转自网络，网络地点太多不确定源地址

密钥:
公钥+私钥的统称。

密钥对：
公钥(证书)和私钥成对存在。通信双方各持有自己的私钥和对方的公钥。自己的私钥需密切保护，而公钥是公开给对方的。在windows下，单独存在的公钥一般是后缀为.cer的文件

A用自己的私钥对数据加密，发给B，B用A提供的公钥解密。同理B用自己的私钥对数据加密，发送给A后，A用B的公钥解开。

公钥的两个用途：
1。验证对方身份：防止其他人假冒对方发送数据给你。
2。解密。
私钥的两个用途：
1。表明自己身份：除非第三方有你私钥，否则无法假冒你发送数据数据给对方。
2。加密。

 

jks(Java key store)：
Java用的存储密钥的容器。可以同时容纳n个公钥或私钥，后缀一般是.jks或者.keystore或.truststore等，千奇百怪。不管什么后缀，它就是一个容器，各个公司或机构叫法不同而已。比如把只包含"受信任的公钥"的容器存成.truststore文件等。
用jdk\\bin目录下的keytool.exe对其进行查看，导入，导出，删除，修改密码等各种操作。可以对jks容器加密码，输入正确才可以操作此容器中密钥。还有一个密码的概念与上者不同，是jks中存储着的私钥的密码，通常是绝密的。

 

pfx：
和jks功能相同但文件格式不同，pfx是浏览器用的。
可以用一些工具程序把pfx转化成jks格式供java程序使用(如银行只提供了pfx，但是我们想用httpclient模拟浏览器自动访问时)。据说IE导出的pfx格式不标准，转化jks时往往报错，可以尝试用Netscape Navigator导入再导出，然后再转化。碰到过这样的情况。

常见的几种https系统的访问。经https协议的数据经过加密传输，防止第三方监听，冒充和篡改。
1.不需要用户做任何操作，比如https://www.verisign.com/
这是因为此公钥是合法的(公钥是可信任的机构颁发，和实际域名吻合，而且没有到期)。用IE访问时空白处点右键可以查看公钥信息。
2.https的页面会弹出公钥确认提示
公钥不合法(不是可信任的机构颁发，和实际域名不吻合，已到期)，但用户点“是”即表示忽略危险，继续访问。
3.需要往浏览器倒入一个文件才可访问的
一般是银行在线交易等特别需要安全的场合，站方(银行)需要验证访客身份(如要确认必须是已注册的网银商户)，需要在浏览器中导入含有访客私钥的pfx文件。

 

生成jks：
在银行没有提供jks文件的情况下对帐，需要自己生成jks
对于1，2类https网站，如果java程序访问此地址时在jre默认的信任库中找不到对方证书的颁发机构，则会抛出安全方面的异常。所以要将站方公钥存进一个jks，并在环境变量中设定，表明信任此库中的公钥，才可以正常访问。
我是用现成的make_jks的工具类在程序中读取https://xxxx地址，程序自动抓取出银行公钥并存进一个jks文件。
在浏览器中查看站方公钥时，把公钥导出(一般是cer后缀)，然后用keytool.exe手工将此cer导入一个jks或许也可以?没试过。
以上1，2类https网站，仅仅是用到了公钥的“验证对方身份”功能。对于第3种https网站，也可以找到现成的程序把pfx直接转成jks。既然动用了pfx，一般是把公钥的两个用途和私钥的两个用途都用起来