前面分析了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的逻辑