h.Connector的SSL属性实现

前面分析了Connector的配置，第一步，Digester已经将上述的属性设置到Connector和xxxEndpoint中了。

下面对于一些核心属性，看看Tomcat是如何使用的：

1.SSLEnabled属性实现

SSLEnabled属性的作用是开启SSL通道，从Tomcat的前端架构来看，并没有单独为SSL通道做一个专门的xxxEndpoint,而是将这个属性插入在NIO，BIO，APR等各个通道中。

以BIO为例：

bind方法是通道初始化的方法，无论哪个通道都有bind方法，对于BIO来讲，是通过socket进行通信的，但是对于SSL来讲，SUN封装和抽象出来个SSLServerSocket，而这个SSLEnabled属性的作用就是根据属性值，初始化SSLServerSocket。而SSLServerSocketFactory中设置了BIO的SSL通信的各种属性，例如下面的加密协议等等。

对于NIO通道的初始化的条件判断，也是在bind方法中进行:

基本就是设置SSLContext上下文等各种属性，相比之下，普通的NIO通道并没有执行这些操作。

除了初始化的判断，在NIO的Acceptor线程包装的过程中，如果是SSL通道的话，需要将NIOChannel包装成SecurityNioChannel，否则包装为普通的NioChannel：

其次，无论是NIO，还是BIO通道，需要设置SSL的Tomcat实现，也就是SSLImplementation。

总结一下，SSLEnabled属性的作用就是在NIO，BIO通道中进行条件判断的，当为启动SSL的时候，开启SSL的一些设置，如果没有开启这个属性的话，就走普通的socket，这个属性很灵活，节省了很多的代码，将SSL的逻辑插入在了普通的NIO，和BIO的通道中。

2.algorithm属性实现

algorithm属性，按理来说，第一直觉应该是SSL通道执行的加密和解密算法，你可以配置n个算法在这个属性中，如RSA，DES等等。
但是，这个属性却并不是这个意思，这个属性是指对应的JSSEProvider的算法。

对于JSSE来说，它仅仅提供了一个框架，这个框架可以做SSL交互，但需要JDK厂商或者自己去实现，SUN的JDK实现了，IBM的JDK也实现了，对于每一家自己实现的内容，都需要指定一个算法，以SUN为例：

SUNX509这套算法，是指示SUNJSSE实现提供X.509标准的验证算法，也就是在SSL交互的时候，遵循X.509的标准。

当然，SUNJSSE有很多其他标准的算法，你可以选择其中的一套而已。

所以，而我们前面了解到，Tomcat中的默认的一路配置是JSSE的，在Tomcat中提供了这一个开放的配置，配合将Tomcat运行在什么JSSE的实现上，这个算法需要进行修改，默认为SUN的实现，如果运行在IBM的JDK上，那就需要指定这个参数为；

我们可以看到初始化SSL配置的时候，如果Endpoint中配置了算法这一项：

传入到KeyManagerFactory.getInstance方法中。

3.sslprotocol属性实现

当使用JSSE的SSLContext的时候，需要将SSLContext支持的协议作为构造参数传入进去：

Tomcat定义的默认的protocol协议为TLS协议，当然如果你打算使用旧版本的SSLv1,V2等等协议，你可以给Connector定义这个sslprotocol属性。

4.sslEnabledProtocol属性实现

SSLEnabledProtocol属性定义与前面的sslprotocol属性的设置有冲突，都是设定SSL通道支持的哪些协议的，尽量这两个属性设置二选一。

sslprotocol属性是设置到SSLContext.getIntance方法中，而这个SSLEnabledProtocol是直接设置到由SSLContext获得的SSLSocket中，

如果采用BIO进行通信，那么SSLEnabledProtocol的作用会覆盖掉SSLContext的设置。

5.ciphers属性实现

从SSL/TLS协议所支持的各种算法列表中，有下面的格式：

这些算法当实例化SSLContext之后，默认会带有n个算法的实现，这些算法以密钥交换算法_加密解密算法_散列算法作为分隔。

可以通过：

来获得ciper的列表。

而这个ciphers的配置，是将默认的支持的算法列表数据进行过滤，将二者取一个交集。

我们来看看Tomcat中是怎么做的：

retainAll方法就是二者取一个交集，然后这个ciphers再设置到对应的socket中去。

6.keystoreFile/keystorePass属性实现

keystoreFile和keystorePass是服务器端的文件，以JSSE的编程来看，这个文件应该以流的方式装入到KeyStore中；

然后，这个Keystore的最终目的是需要装载到KeymanagerFactory中：

KeymanagerFactory的作用是产生Keymanager，Keymanager是作为参数传入SSLContext.init方法中的。

这个流程也是SSL初始化的整个流程。

7.truststoreFile/truststorePass属性实现

truststoreFile和truststorePass是双向认证的时候用到的，存储的是客户端的秘钥库，也就是远程认证的库。

truststore整体的流程和上面的keystore差不太多，虽然是truststore，但也是通过Keystore读取流。

然后，通过TrustManagerFactory装在进来，TrustManagerFactory产生TrustManager，并传入到SSLContext.init方法；

不同的是，TrustManager作为第二个参数，而keymanager是作为第一个参数。

8.crlFile属性实现

crlFile的作用是证书的过期吊销服务，通常这个路径是一个不断变化的文件，由CA中心发布，CA中心的实时进行更新。

对于crlFile的实现，在双向认证中的TrustManager的初始化中，需要进行指定，一旦有crlFile属性的参与，不能直接TrustManagerFactory中loadTrustStore了，我们可以看到下面的实现逻辑：

总共分成3个步骤：

1.首先，需要把CRL文件的路径读取出来，然后使用CertificateFactory产生CRL对象集合

2.将这个CRL集合作为参数传递给CertStore的实例中，并再次包装为ManageFactoryParameter；

3.将ManageFactoryParameter传递给TrustManagerFactory，通过这种方式进行初始化；

可以看到，上述的代码都是JSSE的代码，而真正的CRL的实现是在JDK中。

9.sessionCacheSize/sessionTimeout属性实现

这两个属性是配置SSLSession的超时时间和缓存大小的，当SSLContext初始化之后，会生成SSLSessionContext上下文：

可以看到，这两个属性最终是设置到SSLSessionContext中去，用以Tomcat所有产生的SSLSession；

10.clientAuth属性实现

对于BIO通道中，是通过SSLSocket进行通信的，clientAuth属性设置到SSLSocket中：

对于NIO的通道，因为JSSE主要提供的接口是SSLEngine，因此这个属性需要设置到SSLEngine中：

总结：

从Tomcat的配置的SSL属性可以发现，Tomcat其本身并没有实质的实现，例如SSL几次握手，各种协议，这些东西都是JDK中的实现；而得益于JSSE的框架抽象出来的接口，Tomcat的SSL实现仅仅起到了装配的作用，并且SSL实现没有单独的通道，而是插在了Tomcat的BIO，NIO通道中，通过SSLEnabled属性进行加入SSL的逻辑

来自为知笔记(Wiz)