第一步：为服务器生成证书

使用 keytool 为 Tomcat 生成证书，假定目标机器的域名是 “localhost ” ， keystore 文件存放在“E:\tomcat.keystore ” ，口令为 “password ” ，使用如下命令生成：
 
>keytool -genkey -v -alias tomcat -keyalg RSA -keystore E:\tomcat.keystore -dname "CN=localhost,OU=cn,O=cn,L=cn,ST=cn,C=cn" -storepass password

如果 Tomcat 所在服务器的域名不是 “ localhost ”，应改为对应的域名，如 “ www.sina.com.cn ” ，否则浏览器会弹出警告窗口，提示用户证书与所在域不匹配。在本地做开发测试时，应填入“localhost ”

第二步：为客户端生成证书
 
下一步是为浏览器生成证书，以便让服务器来验证它。为了能将证书顺利导入至 IE 和 Firefo x ，证书格式应该是 PKCS12 ，因此，使用如下命令生成：
 
>keytool -genkey -v -alias myCert -keyalg RSA -storetype  PKCS12 -keystore E:\myCert.p12  -dname "CN=MyCert,OU=cn,O=cn,L=cn,ST=cn,C=cn" -storepass password

正在为以下对象生成 1,024 位 RSA 密钥对和自签名证书 (SHA1withRSA)（有效期为 90 天）:
         CN=MyCert, OU=cn, O=cn, L=cn, ST=cn, C=cn
[正在存储 E:\myCert.p12]
 
第三步：让服务器信任客户端证书
 
由于是双向 SSL 认证，服务器必须要信任客户端证书，因此，必须把客户端证书添加为服务器的信任认证。由于不能直接将 PKCS12 格式的证书库导入，我们必须先把客户端证书导出为一个单独的 CER 文件，使用如下命令：
 
>keytool -export -alias myCert -keystore e:\myCert.p12 -storetype PKCS12 -storepass password -rfc -file e:\myCert.cer

保存在文件中的认证 <e:\myCert.cer>
 
通过以上命令，客户端证书就被我们导出到 “ E:\myCert.cer ” 文件了。下一步，是将该文件导入到服务器的证书库，添加为一个信任证书：
 
>keytool -import -v -file e:\myCert.cer -keystore e:\tomcat.keystore -storepass password

所有者:CN=MyCert, OU=cn, O=cn, L=cn, ST=cn, C=cn
签发人:CN=MyCert, OU=cn, O=cn, L=cn, ST=cn, C=cn
序列号:4eb4e4dd
有效期: Sat Nov 05 15:25:17 CST 2011 至Fri Feb 03 15:25:17 CST 2012
证书指纹:
         MD5:07:C4:89:16:BE:B4:1D:1C:9B:2F:62:2D:DD:68:E6:12
         SHA1:07:D3:00:7D:08:04:E6:FC:D6:D0:37:A0:02:E5:11:13:A3:EE:DA:33
         签名算法名称:SHA1withRSA
         版本: 3
信任这个认证？ [否]：  y
认证已添加至keystore中
[正在存储 e:\tomcat.keystore]
 
导入证书
 
>keytool -import -file e:\myCert.cer -storepass password  -keystore e:\tomcat.truststore -alias serverkey -noprompt

认证已添加至keystore中
 
将所访问的https站点的证书加入jre的信任证书中 
 
>keytool -import -alias tomcat -keystore "%JAVA_HOME%/jre/lib/security/cacerts" -trustcacerts -file e:\myCert.cer -storepass password
 
如果出现 keytool错误： java.io.IOException: Keystore was tampered with, or password was incorrect 则把%JAVA_HOME%/jre/lib/security的cacerts文件删除就可以了。
 
通过 list 命令查看服务器的证书库，我们可以看到两个输入，一个是服务器证书，一个是受信任的客户端证书：
 
>keytool -list -keystore e:\tomcat.keystore -storepass password
 
Keystore 类型： JKS
Keystore 提供者： SUN
您的 keystore 包含 2 输入
tomcat, 2011-11-5, PrivateKeyEntry,
认证指纹 (MD5)： 2B:0F:01:A1:E2:98:AA:0B:08:48:44:5D:BC:7D:09:77
mykey, 2011-11-5, trustedCertEntry,
认证指纹 (MD5)： 07:C4:89:16:BE:B4:1D:1C:9B:2F:62:2D:DD:68:E6:12

第 四 步：配置 Tomcat 服务器

打开 Tomcat 根目录下的 /conf/server.xml ，找到如下配置段，修改如下：
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
            maxThreads="150" scheme="https" secure="true"
            clientAuth=" true " sslProtocol="TLS"
            keystoreFile=" E:/tomcat.keystore " keystorePass=" password "
            truststoreFile=" E:/tomcat.truststore" truststorePass="password "
/>
其中， clientAuth 指定是否需要验证客户端证书，如果该设置为 “ false ” ，则为单向 SSL 验证，SSL 配置可到此结束。如果 clientAuth 设置为 “ true ” ，表示强制双向 SSL 验证，必须验证客户端证书。如果 clientAuth 设置为 “ want ” ，则表示可以验证客户端证书，但如果客户端没有有效证书，也不强制验证。
 
第五步：导入客户端证书

如果设置了 clientAuth="true" ，则需要强制验证客户端证书。双击 “ E:\myCert.p12 ” 即可将证书导入至 IE ：
 
导入证书后，即可启动 Tomcat ，用 IE 进行访问。如果需要用 FireFox 访问，则需将证书导入至 FireFox ：
 
如果启动Tomcat服务器后，在Catalina.log中出现
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'clientAuth' to 'false' did not find a matching property.
的警告，并且访问 https://localhost:8443一直无响应
 
那么修改server.xml中的配置HTTPS的那部分Connector代码
<Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol" SSLEnabled="true"
                   maxThreads="150" scheme="https" secure="true"
                   clientAuth=" true " sslProtocol="TLS"
                   keystoreFile=" E:/tomcat.keystore " keystorePass=" password "
                   truststoreFile=" E:/tomcat.truststore" truststorePass="password "
/>
将protocol参数由"HTTP/1.1"改成"org.apache.coyote.http11.Http11Protocol"，重新启动Tomcat
 
属性说明：
  port：     这个port属性(默认值是8443)是 TCP/IP端口数码，Tomcat在其上监听安全连接。你可以把它更改成任何你愿意要的数值(如默认的https通信，数目是443)。不过 ，在许多操 作系统中，要想在比1024小的端口数码上运行Tomcat，需要特殊的设置(它超出了这个文档资料的范围)。
 
redirectPort： 如 果你在这里更改端口数值，你还必须更改在non-SSL连接器上的redirectPort 这个属性特定的值。这允许Tomcat自动地redirect那些试图访问有安全限制 页面的用户，指明根据 Servlet 2.4 Specification要求，SSL是必需的。
 
clientAuth： 如果你想要Tomcat要求所有的SSL客户在使用这个socket时出示用户认证书，把这个值设定为 true 。如果你想要Tomcat要求出示用户认证书，但是如果没有认 证书也可以， 就把这个值设定为want 。
 
keystoreFile： 如 果你产生的keystore文件不在Tomcat期望的默认地方(一个叫做.keystore 的文件在Tomcat运行的主目录)，就添加这个属性。你可以指定一个绝对路径名 称， 或者一个由$CATALINA_BASE环境变量而派生的相对路径名称。
 
keystorePass： 如果你使用一个不同的keystore(以及认证书)密码，而不是Tomcat期望的密码 (就是changeit)，添加这个元素。
 
keystoreType： 如果使用一个PKCS12 keystore的话，就添加这个element。 有效的值是JKS 和 PKCS12。
 
sslProtocol： 要在这个socket上被使用的加密／解密协定。如果你在使用Sun的JVM，我们不提倡更改 这个值。据报道，TLS协定的IBM's 1.4.1 实现与一些通用的浏览器不 兼容。 如果是这样，就使用value SSL。
 
ciphers： 这个socket允许使用的由逗号分隔开的加密密码列单。默认的情况下，任何可用的密码都允许被使用。
 
algorithm： 可用的X509算法。默认是Sun的实现( SunX509 )。 对于IBM JVMs，你应该使用值 IbmX509。对于其他卖主，查阅JVM文档资料来 找正确的值。
 
truststoreFile： 用来验证用户认证书的TrustStore文件。
 
truststorePass： 访问TrustStore的密码。默认值就是keystorePass的值。
 
truststoreType： 如果你在使用与KeyStore不同格式的TrustStore，添加这个元素。 合法的值是JKS和PKCS12
 
keyAlias： 如果 keystore 里面有多个 key，你可以为用这个选项为加入的 key 起一个名字。 如果没有指定名字，使用时 keystore 内的第一个 key 将会被使用。

----------------------------------------------------------------------------------------------------------------
 ( 附)SSL 工作原理
SSL协议使用不对称加密技术实现会话双方之间信息的安全传递。可以实现信息传递的保密性、完整性，并且会话双方能鉴别对方身份。不同于常用的http协议，我们在与网站建立SSL安全连接时使用https协议，即采用 https://ip:port/ 的方式来访问。
当我们与一个网站建立https连接时，我们的浏览器与Web Server之间要经过一个握手的过程来完成身份鉴定与密钥交换，从而建立安全连接。具体过程如下： 
1. 用户浏览器将其SSL版本号、加密设置参数、与session有关的数据以及其它一些必要信息发送到服务器。 
2. 服务器将其SSL版本号、加密设置参数、与session有关的数据以及其它一些必要信息发送给浏览器，同时发给浏览器的还有服务器的证书。如果配置服务器的SSL需要验证用户身份，还要发出请求要求浏览器提供用户证书。 
3. 客户端检查服务器证书，如果检查失败，提示不能建立SSL连接。如果成功，那么继续。 
4. 客户端浏览器为本次会话生成pre-master secret，并将其用服务器公钥加密后发送给服务器。 
5. 如果服务器要求鉴别客户身份，客户端还要再对另外一些数据签名后并将其与客户端证书一起发送给服务器。 
6. 如果服务器要求鉴别客户身份，则检查签署客户证书的CA是否可信。如果不在信任列表中，结束本次会话。如果检查通过，服务器用自己的私钥解密收到的pre-master secret，并用它通过某些算法生成本次会话的master secret。 
7. 客户端与服务器均使用此master secret生成本次会话的会话密钥(对称密钥)。在双方SSL握手结束后传递任何消息均使用此会话密钥。这样做的主要原因是对称加密比非对称加密的运算量低一个数量级以上，能够显著提高双方会话时的运算速度。 
8. 客户端通知服务器此后发送的消息都使用这个会话密钥进行加密。并通知服务器客户端已经完成本次SSL握手。 
9. 服务器通知客户端此后发送的消息都使用这个会话密钥进行加密。并通知客户端服务器已经完成本次SSL握手。 
10. 本次握手过程结束，会话已经建立。双方使用同一个会话密钥分别对发送以及接受的信息进行加、解密。