结合日志,我们来看一下SSL双向认证的全过程: 

 

第一步: 客户端发送ClientHello消息,发起SSL连接请求,告诉服务器自己支持的SSL选项(加密方式等)。 

Bash代码  收藏代码
  1. *** ClientHello, TLSv1  



第二步: 服务器响应请求,回复ServerHello消息,和客户端确认SSL加密方式: 

Bash代码  收藏代码
  1. *** ServerHello, TLSv1  



第三步: 服务端向客户端发布自己的公钥。 

第四步: 客户端与服务端的协通沟通完毕,服务端发送ServerHelloDone消息: 

Bash代码  收藏代码
  1. *** ServerHelloDone  



第五步: 客户端使用服务端给予的公钥,创建会话用密钥(SSL证书认证完成后,为了提高性能,所有的信息交互就可能会使用对称加密算法),并通过ClientKeyExchange消息发给服务器: 

Bash代码  收藏代码
  1. *** ClientKeyExchange, RSA PreMasterSecret, TLSv1  



第六步: 客户端通知服务器改变加密算法,通过ChangeCipherSpec消息发给服务端: 

Bash代码  收藏代码
  1. main, WRITE: TLSv1 Change Cipher Spec, length = 1  



第七步: 客户端发送Finished消息,告知服务器请检查加密算法的变更请求: 

Bash代码  收藏代码
  1. *** Finished  



第八步:服务端确认算法变更,返回ChangeCipherSpec消息 

Bash代码  收藏代码
  1. main, READ: TLSv1 Change Cipher Spec, length = 1  



第九步:服务端发送Finished消息,加密算法生效: 

Bash代码  收藏代码
  1. *** Finished  



那么如何让服务端也认证客户端的身份,即双向握手呢?其实很简单,在服务端代码中,把这一行: 

Java代码  收藏代码
  1. ((SSLServerSocket) _socket).setNeedClientAuth(false);  



改成: 

Java代码  收藏代码
  1. ((SSLServerSocket) _socket).setNeedClientAuth(true);  


通过比对单向认证的日志输出,我们可以发现双向认证时,多出了服务端认证客户端证书的步骤: 

Bash代码  收藏代码
  1. *** CertificateRequest  
  2. Cert Types: RSA, DSS  
  3. Cert Authorities:  
  4. <CN=localhost, OU=cn, O=cn, L=cn, ST=cn, C=cn>  
  5. <CN=localhost, OU=cn, O=cn, L=cn, ST=cn, C=cn>  
  6. *** ServerHelloDone  



Bash代码  收藏代码
  1. *** CertificateVerify  
  2. main, WRITE: TLSv1 Handshake, length = 134  
  3. main, WRITE: TLSv1 Change Cipher Spec, length = 1  



在 @*** [email protected] 之前,服务端向客户端发起了需要证书的请求 @*** [email protected] 。 

在客户端向服务端发出 @Change Cipher [email protected] 请求之前,多了一步客户端证书认证的过程 @*** [email protected] 。 

客户端与服务端互相认证证书的情景,可参考下图: