https应用总结
程序员文章站
2022-03-07 11:07:12
...
https调研
一、 https简介：
1、 http: 超文本传送协议 (HTTP) 是一种通信协议，它允许将超文本标记语言 (HTML) 文档从 Web 服务器传送到 Web 浏览器。HTML 是一种用于创建文档的标记语言，这些文档包含到相关信息的链接。您可以单击一个链接来访问其它文档、图像或多媒体对象，并获得关于链接项的附加信息。
2、 https: 它是一个安全通信通道，它基于HTTP开发，用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换。是http的安全版
(HTTPS报文中的任何东西都被加密，包括所有报头和荷载。除了可能的CCA（参见限制小节）之外，一个攻击者所能知道的只有在两者之间有一连接这一事实。)
3、SSL：或者Secure Socket Layer，是一种允许web浏览器和web服务器通过一个安全的连接进行交流的技术。这意味着将被发送的数据在一端被翻译成密码，传送出去，然后在另一端解开密码，再进行处理。这是一个双向的过程，也就是浏览器和服务器都需要在发送数据之前对它们进行加密。SSL协定的另一个重要方面是认证(Authentication)。这就是说，在你开始试图通过一个安全连接与一个web服务器交流的时候，这个服务器会要求你的浏览器出示一组证件，通过“鉴定”的方式来证明这就是你所声明的网站
二、SSL协议的工作流程(几个关键点)：
1、一旦配置好你的服务器，任何浏览器只要简单地将 URL 地址中的协议指定成 HTTPS ，就能够在你的服务器上安全地进行信息查询
2、要使一网络服务器准备好接受HTTPS连接，管理员必须创建一数字证书，并交由证书颁发机构签名以使浏览器接受。证书颁发机构会验证数字证书持有人和其声明的为同一人。浏览器通常都预装了证书颁发机构的证书，所以他们可以验证该签名。
3、当连接到一提供无效证书的网站时，较旧的浏览器会使用一对话框询问用户是否继续，而较新的浏览器会在整个窗口中显示警告；较新的浏览器也会在地址栏中凸显网站的安全信息（如，Extended validation证书通常会使地址栏变绿）。
三、https解决的问题：
1 . 信任主机的问题. 采用https 的server 必须从CA 申请一个用于证明服务器用途类型的证书. 改证书只有用于对应的server 的时候,客户度才信任次主机. 所以目前所有的银行系统网站,关键部分应
用都是https 的. 客户通过信任该证书,从而信任了该主机. 其实这样做效率很低,但是银行更侧重安全. 这一点对我们没有任何意义,我们的server ,采用的证书不管自己issue 还是从公众的地方issue,
客户端都是自己人,所以我们也就肯定信任该server.
2 . 通讯过程中的数据的泄密和被窜改
1. 一般意义上的https, 就是 server 有一个证书.
a) 主要目的是保证server 就是他声称的server. 这个跟第一点一样.
b) 服务端和客户端之间的所有通讯,都是加密的.
i. 具体讲,是客户端产生一个对称的**,通过server 的证书来交换**. 一般意义上的握手过程.
ii. 加下来所有的信息往来就都是加密的. 第三方即使截获,也没有任何意义.因为他没有**. 当然窜改也就没有什么意义了.
2. 少许对客户端有要求的情况下,会要求客户端也必须有一个证书.
a) 这里客户端证书,其实就类似表示个人信息的时候,除了用户名/密码, 还有一个CA 认证过的身份. 应为个人证书一般来说上别人无法模拟的,所有这样能够更深的确认自己的身份.
b) 目前少数个人银行的专业版是这种做法,具体证书可能是拿U盘作为一个备份的载体.
HTTPS 一定是繁琐的.
a) 本来简单的http协议,一个get一个response. 由于https 要还**和确认加密算法的需要.单握手就需要6/7 个往返.
i. 任何应用中,过多的round trip 肯定影响性能.
b) 接下来才是具体的http协议,每一次响应或者请求, 都要求客户端和服务端对会话的内容做加密/解密.
i. 尽管对称加密/解密效率比较高,可是仍然要消耗过多的CPU,为此有专门的SSL 芯片. 如果CPU 信能比较低的话,肯定会降低性能,从而不能serve 更多的请求.
ii. 加密后数据量的影响. 所以，才会出现那么多的安全认证提示
四、**协商、握手过程(重点)：
SSL 的握手协议非常有效的让客户和服务器之间完成相互之间的身份认证，其主要过程如下：
①客户端的浏览器向服务器传送客户端 SSL 协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。
②服务器向客户端传送 SSL 协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。
③客户利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的 CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开；如果合法性验证通过，将继续进行第四步。
④用户端随机产生一个用于后面通讯的“对称密码”，然后用服务器的公钥（服务器的公钥从步骤②中的服务器的证书中获得）对其加密，然后将加密后的“预主密码”传给服务器。
⑤如果服务器要求客户的身份认证（在握手过程中为可选），用户可以建立一个随机数然后对其进行数据签名，将这个含有签名的随机数和客户自己的证书以及加密过的“预主密码”一起传给服务器。
⑥如果服务器要求客户的身份认证，服务器必须检验客户证书和签名随机数的合法性，具体的合法性验证过程包括：客户的证书使用日期是否有效，为客户提供证书的CA 是否可靠，发行CA 的公钥能否正确解开客户证书的发行 CA 的数字签名，检查客户的证书是否在证书废止列表（CRL）中。检验如果没有通过，通讯立刻中断；如果验证通过，服务器将用自己的私钥解开加密的“预主密码 ”，然后执行一系列步骤来产生主通讯密码（客户端也将通过同样的方法产生相同的主通讯密码）。
⑦服务器和客户端用相同的主密码即“通话密码”，一个对称**用于 SSL 协议的安全数据通讯的加解密通讯。同时在 SSL 通讯过程中还要完成数据通讯的完整性，防止数据通讯中的任何变化。
⑧客户端向服务器端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称**，同时通知服务器客户端的握手过程结束。
⑨服务器向客户端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称**，同时通知客户端服务器端的握手过程结束。
⑩SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户和服务器开始使用相同的对称**进行数据通讯，同时进行通讯完整性的检验。
如果上面的说明不够清晰，这里我们用个形象的比喻，我们假设A与B通信，A是SSL客户端，B是SSL服务器端，加密后的消息放在方括号[]里，以突出明文消息的区别。双方的处理动作的说明用圆括号（）括起。
A：我想和你安全的通话，我这里的对称加密算法有DES,RC5,**交换算法有RSA和DH，摘要算法有MD5和SHA。
B：我们用DES－RSA－SHA这对组合好了。
这是我的证书，里面有我的名字和公钥，你拿去验证一下我的身份（把证书发给A）。
目前没有别的可说的了。
A：（查看证书上B的名字是否无误，并通过手头早已有的CA的证书验证了B的证书的真实性，如果其中一项有误，发出警告并断开连接，这一步保证了B的公钥的真实性）
（产生一份秘密消息，这份秘密消息处理后将用作加***，加密初始化向量和hmac的**。将这份秘密消息-协议中称为per_master_secret-用B的公钥加密，封装成称作ClientKeyExchange的消息。由于用了B的公钥，保证了第三方无法qie听）
我生成了一份秘密消息，并用你的公钥加密了，给你（把ClientKeyExchange发给B）
注意，下面我就要用加密的办法给你发消息了！
（将秘密消息进行处理，生成加***，加密初始化向量和hmac的**）
[我说完了]
B：（用自己的私钥将ClientKeyExchange中的秘密消息解密出来，然后将秘密消息进行处理，生成加***，加密初始化向量和hmac的**，这时双方已经安全的协商出一套加密办法了）
注意，我也要开始用加密的办法给你发消息了！
[我说完了]
A: [我的秘密是...]
B: [其它人不会听到的...]
五、关于证书：
注意，如果对于一般的应用，管理员只需生成“证书请求”（后缀大多为.csr），它包含你的名字和公钥，然后把这份请求交给诸如verisign等有CA服务公司（当然，连同几百美金），你的证书请求经验证后，CA用它的私钥签名，形成正式的证书发还给你。管理员再在web server上导入这个证书就行了。如果你不想花那笔钱，或者想了解一下原理，可以自己做CA。
从ca的角度讲，你需要CA的私钥和公钥。从想要证书的服务器角度讲，需要把服务器的证书请求交给CA。
如果你要自己做CA，别忘了客户端需要导入CA的证书（CA的证书是自签名的，导入它意味着你“信任”这个CA签署的证书）。
在许多情况下，如果你信任发出认证书的认证权威单位的话，你就可以相信这个认证书是有
效的。认证并不是真正使人担忧的事。系统管理员或许只想要保证被服务器传送和接收的数
据是秘密的，不会被连接线上的偷窃者偷到。庆幸的是，Java提供相对简单的被称为keytool
的命令行工具，可以简单地产生“自己签名”的证书。自己签名的证书只是用户产生的证书，
没有正式在大家所熟知的认证权威那里注册过，因此不能确保它的真实性。但却能保证数据
传输的安全性。
六、https和http的区别及联系及区别：
1、https协议需要到ca申请证书，一般免费证书很少，需要交费。
2、http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议
3、http和https使用的是完全不同的连接方式用的端口也不一样,前者是80,后者是443。
4、http的连接很简单,是无状态的
5、HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议 要比http协议安全
七、配置https过程：
1、生成证书命令：
命令行进到tomcat安装目录执行：
keytool -genkey -alias tomcat -keyalg RSA -keypass changeit -storepass changeit -keystore server.keystore -validity 3600
1）、这个命令会在用户的home directory产生一个叫做" .keystore " 的新文件。在执行后，
你首先被要求出示keystore密码。Tomcat使用的默认密码是" changeit "(全都是小写字母)，
如果你愿意，你可以指定你自己的密码。你还需要在server.xml配置文件里指定自己的
密码。 2）、 你会被要求出示关于这个认证书的一般性信息，如公司，
联系人名称，等等。这些信息会显示给那些试图访问你程序里安全网页的用户，以确保这里
提供的信息与他们期望的相对应。 3）、 你会被要求出示**(key)密码，也就是这个认
证书所特有的密码(与其它的储存在同一个keystore文件里的认证书不同)。你必须在这里使
用与keystore密码相同的密码。(目前，keytool会提示你按ENTER键会自动帮你做这些)。
现在就拥有了一个可以被你的服务器使用的有认证书的keystore文件。
2、配置tomcat(server.xml):
把tomcat安装目录里的server.xml文件里的<!-- Define an SSL HTTP/1.1 Connector on port 8443 -->; 替换为
【keystoreFile是生成的证书路径，保存了服务器端的证书库，用于客户端认证。】
3、 配置web.xml:
【表示链接以/test1开头的应用会被强制指定使用https】
Connector元素本身，其默认形式是被注释掉的(commented out)，所以需要把它周围的注释标志删除掉。然后，可以根据需要客户化(自己设置)特定的属性。一般需要增加一下keystoreFile和keystorePass两个属性，指定你存放证书的路径（如：keystoreFile="C:/.keystore"）和刚才设置的密码（如：keystorePass="123456"）。关于其它各种选项的详细信息，可查阅Server Configuration Reference。
在完成这些配置更改后，必须象重新启动Tomcat，然后你就可以通过SSL访问Tomcat支持的任何web应用程序。配置完成后可以用https://localhost:8443进行测试
八、常见命令：
常用的配置属性(server.xml)：
1、clientAuth
如果想要Tomcat为了使用这个socket而要求所有SSL客户出示一个客户证书，置该值为true。
2、keystoreFile
如果创建的keystore文件不在Tomcat认为的缺省位置（一个在Tomcat运行的home目录下的叫.keystore的文件），则加上该属性。可以指定一个绝对路径或依赖$CATALINA_BASE环境变量的相对路径。
3、keystorePass
如果使用了一个与Tomcat预期不同的keystore（和证书）密码，则加入该属性。
4、keystoreType
如果使用了一个PKCS12 keystore，加入该属性。有效值是JKS和PKCS12。
5、sslProtocol
socket使用的加密/解密协议。如果使用的是Sun的JVM，则不建议改变这个值。据说IBM的1.4.1版的TLS协议的实现和一些流行的浏览器不兼容。这种情况下，使用SSL。
6、ciphers
此socket允许使用的被逗号分隔的密码列表。缺省情况下，可以使用任何可用的密码。
7、algorithm
使用的X509算法。缺省为Sun的实现（SunX509）。对于IBM JVMS应该使用ibmX509。对于其它JVM，参考JVM文档取正确的值。
8、truststoreFile
用来验证客户证书的TrustStore文件。
9、truststorePass
访问TrustStore使用的密码。缺省值是keystorePass。
10、truststoreType
如果使用一个不同于正在使用的KeyStore的TrustStore格式，加入该属性。有效值是JKS和PKCS12。
Keytool常用命令(在tomcat安装目录下执行)：
1、keytool -export -trustcacerts -alias tomcat -file server.cer -keystore server.keystore -storepass changeit将证书导出
2、keytool -list -v -keystore D:/sdks/jdk1.5.0_11/jre/lib/security/cacerts(列出信任证书库中所有已有证书)
3、keytool -delete -trustcacerts -alias tomcat -keystore D:/sdks/jdk1.5.0_11/jre/lib/security/cacerts -storepass changeit(删除库中某个证书)
一、 https简介：
1、 http: 超文本传送协议 (HTTP) 是一种通信协议，它允许将超文本标记语言 (HTML) 文档从 Web 服务器传送到 Web 浏览器。HTML 是一种用于创建文档的标记语言，这些文档包含到相关信息的链接。您可以单击一个链接来访问其它文档、图像或多媒体对象，并获得关于链接项的附加信息。
2、 https: 它是一个安全通信通道，它基于HTTP开发，用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换。是http的安全版
(HTTPS报文中的任何东西都被加密，包括所有报头和荷载。除了可能的CCA（参见限制小节）之外，一个攻击者所能知道的只有在两者之间有一连接这一事实。)
3、SSL：或者Secure Socket Layer，是一种允许web浏览器和web服务器通过一个安全的连接进行交流的技术。这意味着将被发送的数据在一端被翻译成密码，传送出去，然后在另一端解开密码，再进行处理。这是一个双向的过程，也就是浏览器和服务器都需要在发送数据之前对它们进行加密。SSL协定的另一个重要方面是认证(Authentication)。这就是说，在你开始试图通过一个安全连接与一个web服务器交流的时候，这个服务器会要求你的浏览器出示一组证件，通过“鉴定”的方式来证明这就是你所声明的网站
二、SSL协议的工作流程(几个关键点)：
1、一旦配置好你的服务器，任何浏览器只要简单地将 URL 地址中的协议指定成 HTTPS ，就能够在你的服务器上安全地进行信息查询
2、要使一网络服务器准备好接受HTTPS连接，管理员必须创建一数字证书，并交由证书颁发机构签名以使浏览器接受。证书颁发机构会验证数字证书持有人和其声明的为同一人。浏览器通常都预装了证书颁发机构的证书，所以他们可以验证该签名。
3、当连接到一提供无效证书的网站时，较旧的浏览器会使用一对话框询问用户是否继续，而较新的浏览器会在整个窗口中显示警告；较新的浏览器也会在地址栏中凸显网站的安全信息（如，Extended validation证书通常会使地址栏变绿）。
三、https解决的问题：
1 . 信任主机的问题. 采用https 的server 必须从CA 申请一个用于证明服务器用途类型的证书. 改证书只有用于对应的server 的时候,客户度才信任次主机. 所以目前所有的银行系统网站,关键部分应
用都是https 的. 客户通过信任该证书,从而信任了该主机. 其实这样做效率很低,但是银行更侧重安全. 这一点对我们没有任何意义,我们的server ,采用的证书不管自己issue 还是从公众的地方issue,
客户端都是自己人,所以我们也就肯定信任该server.
2 . 通讯过程中的数据的泄密和被窜改
1. 一般意义上的https, 就是 server 有一个证书.
a) 主要目的是保证server 就是他声称的server. 这个跟第一点一样.
b) 服务端和客户端之间的所有通讯,都是加密的.
i. 具体讲,是客户端产生一个对称的**,通过server 的证书来交换**. 一般意义上的握手过程.
ii. 加下来所有的信息往来就都是加密的. 第三方即使截获,也没有任何意义.因为他没有**. 当然窜改也就没有什么意义了.
2. 少许对客户端有要求的情况下,会要求客户端也必须有一个证书.
a) 这里客户端证书,其实就类似表示个人信息的时候,除了用户名/密码, 还有一个CA 认证过的身份. 应为个人证书一般来说上别人无法模拟的,所有这样能够更深的确认自己的身份.
b) 目前少数个人银行的专业版是这种做法,具体证书可能是拿U盘作为一个备份的载体.
HTTPS 一定是繁琐的.
a) 本来简单的http协议,一个get一个response. 由于https 要还**和确认加密算法的需要.单握手就需要6/7 个往返.
i. 任何应用中,过多的round trip 肯定影响性能.
b) 接下来才是具体的http协议,每一次响应或者请求, 都要求客户端和服务端对会话的内容做加密/解密.
i. 尽管对称加密/解密效率比较高,可是仍然要消耗过多的CPU,为此有专门的SSL 芯片. 如果CPU 信能比较低的话,肯定会降低性能,从而不能serve 更多的请求.
ii. 加密后数据量的影响. 所以，才会出现那么多的安全认证提示
四、**协商、握手过程(重点)：
SSL 的握手协议非常有效的让客户和服务器之间完成相互之间的身份认证，其主要过程如下：
①客户端的浏览器向服务器传送客户端 SSL 协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。
②服务器向客户端传送 SSL 协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。
③客户利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的 CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开；如果合法性验证通过，将继续进行第四步。
④用户端随机产生一个用于后面通讯的“对称密码”，然后用服务器的公钥（服务器的公钥从步骤②中的服务器的证书中获得）对其加密，然后将加密后的“预主密码”传给服务器。
⑤如果服务器要求客户的身份认证（在握手过程中为可选），用户可以建立一个随机数然后对其进行数据签名，将这个含有签名的随机数和客户自己的证书以及加密过的“预主密码”一起传给服务器。
⑥如果服务器要求客户的身份认证，服务器必须检验客户证书和签名随机数的合法性，具体的合法性验证过程包括：客户的证书使用日期是否有效，为客户提供证书的CA 是否可靠，发行CA 的公钥能否正确解开客户证书的发行 CA 的数字签名，检查客户的证书是否在证书废止列表（CRL）中。检验如果没有通过，通讯立刻中断；如果验证通过，服务器将用自己的私钥解开加密的“预主密码 ”，然后执行一系列步骤来产生主通讯密码（客户端也将通过同样的方法产生相同的主通讯密码）。
⑦服务器和客户端用相同的主密码即“通话密码”，一个对称**用于 SSL 协议的安全数据通讯的加解密通讯。同时在 SSL 通讯过程中还要完成数据通讯的完整性，防止数据通讯中的任何变化。
⑧客户端向服务器端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称**，同时通知服务器客户端的握手过程结束。
⑨服务器向客户端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称**，同时通知客户端服务器端的握手过程结束。
⑩SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户和服务器开始使用相同的对称**进行数据通讯，同时进行通讯完整性的检验。
如果上面的说明不够清晰，这里我们用个形象的比喻，我们假设A与B通信，A是SSL客户端，B是SSL服务器端，加密后的消息放在方括号[]里，以突出明文消息的区别。双方的处理动作的说明用圆括号（）括起。
A：我想和你安全的通话，我这里的对称加密算法有DES,RC5,**交换算法有RSA和DH，摘要算法有MD5和SHA。
B：我们用DES－RSA－SHA这对组合好了。
这是我的证书，里面有我的名字和公钥，你拿去验证一下我的身份（把证书发给A）。
目前没有别的可说的了。
A：（查看证书上B的名字是否无误，并通过手头早已有的CA的证书验证了B的证书的真实性，如果其中一项有误，发出警告并断开连接，这一步保证了B的公钥的真实性）
（产生一份秘密消息，这份秘密消息处理后将用作加***，加密初始化向量和hmac的**。将这份秘密消息-协议中称为per_master_secret-用B的公钥加密，封装成称作ClientKeyExchange的消息。由于用了B的公钥，保证了第三方无法qie听）
我生成了一份秘密消息，并用你的公钥加密了，给你（把ClientKeyExchange发给B）
注意，下面我就要用加密的办法给你发消息了！
（将秘密消息进行处理，生成加***，加密初始化向量和hmac的**）
[我说完了]
B：（用自己的私钥将ClientKeyExchange中的秘密消息解密出来，然后将秘密消息进行处理，生成加***，加密初始化向量和hmac的**，这时双方已经安全的协商出一套加密办法了）
注意，我也要开始用加密的办法给你发消息了！
[我说完了]
A: [我的秘密是...]
B: [其它人不会听到的...]
五、关于证书：
注意，如果对于一般的应用，管理员只需生成“证书请求”（后缀大多为.csr），它包含你的名字和公钥，然后把这份请求交给诸如verisign等有CA服务公司（当然，连同几百美金），你的证书请求经验证后，CA用它的私钥签名，形成正式的证书发还给你。管理员再在web server上导入这个证书就行了。如果你不想花那笔钱，或者想了解一下原理，可以自己做CA。
从ca的角度讲，你需要CA的私钥和公钥。从想要证书的服务器角度讲，需要把服务器的证书请求交给CA。
如果你要自己做CA，别忘了客户端需要导入CA的证书（CA的证书是自签名的，导入它意味着你“信任”这个CA签署的证书）。
在许多情况下，如果你信任发出认证书的认证权威单位的话，你就可以相信这个认证书是有
效的。认证并不是真正使人担忧的事。系统管理员或许只想要保证被服务器传送和接收的数
据是秘密的，不会被连接线上的偷窃者偷到。庆幸的是，Java提供相对简单的被称为keytool
的命令行工具，可以简单地产生“自己签名”的证书。自己签名的证书只是用户产生的证书，
没有正式在大家所熟知的认证权威那里注册过，因此不能确保它的真实性。但却能保证数据
传输的安全性。
六、https和http的区别及联系及区别：
1、https协议需要到ca申请证书，一般免费证书很少，需要交费。
2、http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议
3、http和https使用的是完全不同的连接方式用的端口也不一样,前者是80,后者是443。
4、http的连接很简单,是无状态的
5、HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议 要比http协议安全
七、配置https过程：
1、生成证书命令：
命令行进到tomcat安装目录执行：
keytool -genkey -alias tomcat -keyalg RSA -keypass changeit -storepass changeit -keystore server.keystore -validity 3600
1）、这个命令会在用户的home directory产生一个叫做" .keystore " 的新文件。在执行后，
你首先被要求出示keystore密码。Tomcat使用的默认密码是" changeit "(全都是小写字母)，
如果你愿意，你可以指定你自己的密码。你还需要在server.xml配置文件里指定自己的
密码。 2）、 你会被要求出示关于这个认证书的一般性信息，如公司，
联系人名称，等等。这些信息会显示给那些试图访问你程序里安全网页的用户，以确保这里
提供的信息与他们期望的相对应。 3）、 你会被要求出示**(key)密码，也就是这个认
证书所特有的密码(与其它的储存在同一个keystore文件里的认证书不同)。你必须在这里使
用与keystore密码相同的密码。(目前，keytool会提示你按ENTER键会自动帮你做这些)。
现在就拥有了一个可以被你的服务器使用的有认证书的keystore文件。
2、配置tomcat(server.xml):
把tomcat安装目录里的server.xml文件里的<!-- Define an SSL HTTP/1.1 Connector on port 8443 -->; 替换为
<Connector port="8443" protocol="HTTP/1.1"
maxThreads="150"
scheme="https" secure="true" SSLEnabled="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="C:/Program Files/Apache Software Foundation/Tomcat 6.0/server.keystore" keystorePass="changeit" />【keystoreFile是生成的证书路径，保存了服务器端的证书库，用于客户端认证。】
3、 配置web.xml:
<security-constraint>
<web-resource-collection>
<web-resource-name>must https</web-resource-name>
<url-pattern>/test1/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>【表示链接以/test1开头的应用会被强制指定使用https】
Connector元素本身，其默认形式是被注释掉的(commented out)，所以需要把它周围的注释标志删除掉。然后，可以根据需要客户化(自己设置)特定的属性。一般需要增加一下keystoreFile和keystorePass两个属性，指定你存放证书的路径（如：keystoreFile="C:/.keystore"）和刚才设置的密码（如：keystorePass="123456"）。关于其它各种选项的详细信息，可查阅Server Configuration Reference。
在完成这些配置更改后，必须象重新启动Tomcat，然后你就可以通过SSL访问Tomcat支持的任何web应用程序。配置完成后可以用https://localhost:8443进行测试
八、常见命令：
常用的配置属性(server.xml)：
1、clientAuth
如果想要Tomcat为了使用这个socket而要求所有SSL客户出示一个客户证书，置该值为true。
2、keystoreFile
如果创建的keystore文件不在Tomcat认为的缺省位置（一个在Tomcat运行的home目录下的叫.keystore的文件），则加上该属性。可以指定一个绝对路径或依赖$CATALINA_BASE环境变量的相对路径。
3、keystorePass
如果使用了一个与Tomcat预期不同的keystore（和证书）密码，则加入该属性。
4、keystoreType
如果使用了一个PKCS12 keystore，加入该属性。有效值是JKS和PKCS12。
5、sslProtocol
socket使用的加密/解密协议。如果使用的是Sun的JVM，则不建议改变这个值。据说IBM的1.4.1版的TLS协议的实现和一些流行的浏览器不兼容。这种情况下，使用SSL。
6、ciphers
此socket允许使用的被逗号分隔的密码列表。缺省情况下，可以使用任何可用的密码。
7、algorithm
使用的X509算法。缺省为Sun的实现（SunX509）。对于IBM JVMS应该使用ibmX509。对于其它JVM，参考JVM文档取正确的值。
8、truststoreFile
用来验证客户证书的TrustStore文件。
9、truststorePass
访问TrustStore使用的密码。缺省值是keystorePass。
10、truststoreType
如果使用一个不同于正在使用的KeyStore的TrustStore格式，加入该属性。有效值是JKS和PKCS12。
Keytool常用命令(在tomcat安装目录下执行)：
1、keytool -export -trustcacerts -alias tomcat -file server.cer -keystore server.keystore -storepass changeit将证书导出
2、keytool -list -v -keystore D:/sdks/jdk1.5.0_11/jre/lib/security/cacerts(列出信任证书库中所有已有证书)
3、keytool -delete -trustcacerts -alias tomcat -keystore D:/sdks/jdk1.5.0_11/jre/lib/security/cacerts -storepass changeit(删除库中某个证书)