Quick Start
下列说明将使用变量名 $CATALINA_BASE 来表示多数相对路径所基于的基本目录。如果没有为 Tomcat 多个实例设置 CATALINA_BASE 目录，则 $CATALINA_BASE 就会设定为 $CATALINA_HOME 的值，也就是你安装 Tomcat 的目录。
在 Tomcat 中安装并配置 SSL/TLS 支持，只需遵循下列几步即可。详细信息可参看文档后续介绍。
创建一个 keystore 文件保存服务器的私有密钥和自签名证书：
Windows：
"%JAVA_HOME%\bin\keytool" -genkey -alias tomcat -keyalg RSA
UNIX：
$JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA
指定密码为“changeit”。
取消对 $CATALINA_BASE/conf/server.xml 中 “SSL HTTP/1.1 Connector” 一项的注释状态。按照下文中配置一节所描述的方式进行修改。
SSL/TLS 简介
安全传输层协议（TLS）与其前辈加密套接字（SSL）都是用于保证 Web 浏览器与 Web 服务器通过安全连接进行通信的技术。利用这些技术，我们所要传送的数据会在一端进行加密，传输到另一端后再进行解密（在处理数据之前）。这是一种双向的操作，服务器和浏览器都能在发送数据前对它们进行加密处理。
SSL/TLS 协议的另一个重要方面是认证。当我们初始通过安全连接与 Web 服务器进行通信时，服务器将提供给 Web 浏览器一组“证书”形式的凭证，用来证明站点的归属方以及站点的具体声明。某些情况下，服务器也会请求浏览器出示证书，来证明作为操作者的“你”所宣称的身份是否属实。这种证书叫做“客户端证书”，但事实上它更多地用于 B2B（企业对企业电子商务）的交易中，而并非针对个人用户。大多数启用了 SSL 协议的 Web 服务器都不需要客户端认证。
SSL/TLS 与 Tomcat
一定要注意的是，通常只有当 Tomcat 是独立运行的 Web 服务器时，才有必要去配置 Tomcat 以便利用加密套接字。具体细节可参看 Security Considerations Document。当 Tomcat 以 Servlet/JSP 容器的形式在其他 Web 服务器（比如 Apache 或 Microsoft IIS）背后运行时，通常需要配置的是主 Web 服务器，用主服务器来处理与用户的 SSL 连接。主服务器一般会利用所有的 SSL 相关功能，将任何只有 Tomcat 才能处理的请求进行解密后再传给 Tomcat。同样，Tomcat 会返回明文形式的响应，这些响应在被传输到用户浏览器之前会被主服务器进行加密处理。在这种情境下，Tomcat 知道主服务器与客户端的所有通信都是通过安全连接进行的（因为应用要求），但 Tomcat 自身无法参与到加密与解密的过程中。
证书
为了实现 SSL，Web 服务器必须对每一个接受安全连接的外部接口（IP 地址）配备相应的证书。这种设计方式的理论在于，服务器必须提供某种可信的保证（尤其对于接收敏感信息而言），保证它的拥有者是你所认为的角色。限于本章篇幅，不再赘述关于证书的详细解释，只需要把它认为成是一种 IP 地址的“数字驾照”即可。它声明了与站点相关的组织，以及一些关于站点拥有者或管理者的基本联系信息。
这种“数字驾照”的持有者对其进行了加密签名，从而使得它极难伪造。对于参与电子商务的站点或者其他一些身份验证显得非常重要的商业交易来说，证书通常都是从一些比较权威公正的 CA （ Certificate Authority，认证机构）购买的，比较知名的 CA 有 VeriSign 、Thawte 等。这些证书可经电子验证。实际上，CA 会保证所颁发证书的真实性，所以你完全可以放心。
不过，在很多情况下，验证并不是问题的关键。管理员可能只想保证服务器所传输与接收的数据是秘密的，不会被某些人通过连接来窃取。幸运的是，Java 提供了一个简单的命令行工具：keytool。它能轻松创建一个“自签名”的证书，这种自签名证书是由用户生成的一种证书，未经任何知名 CA 给予官方保证，因此它的真实性也无法确定。再说一次，是否认证，完全根据你的需求。
运行 SSL 通常需要注意的一些内容
当用户首次访问你站点上的安全页面时，页面通常会提供给他一个对话框，包含证书相关细节（比如组织及联系方式等），并且询问他是否愿意承认该证书为有效证书，然后再进行下一步的事务。一些浏览器可能会提供一个选项，允许永远承认给出的证书的有效性，这样就不会在用户每次访问站点时打扰他们了。但有些浏览器不会提供这种选项。一旦用户承认了证书的有效性，那么在整个的浏览器会话期间，证书都被认为是有效的。
虽然 SSL 协议的意图是尽可能有助于提供安全且高效的连接，但从性能角度来考虑，加密与解密是非茶馆耗费计算资源的，因此将整个 Web 应用都运行在 SSL 协议下是完全没有必要的，开发者需要挑选需要安全连接的页面。对于一个相当繁忙的网站来说，通常只会在特定页面上使用 SSL 协议，也就是可能交换敏感信息的页面，比如：登录页面、个人信息页面、购物车结账页面（可能会输入信用卡信息），等等。应用中的任何一个页面都可以通过加密套接字来请求访问，只需将页面地址的前缀 http: 换成 https: 即可。绝对需要安全连接的页面应该检查该页面请求所关联的协议类型，如果发现没有指定 https:，则采取适当行为。
最后，在安全连接上使用基于名称的虚拟主机可能会造成一定的问题。这正是 SSL 协议的局限。SSL 握手过程，即客户端浏览器接收服务器证书，必须发生在 HTTP 请求被访问前。因此包含虚拟主机名称的请求信息不能先于认证而确定，也不可能为单个 IP 地址指定多个证书。如果单个 IP 地址的所有虚拟主机都需要利用同样证书来认证的话，那么多个虚拟主机不应该干涉服务器通常的 SSL 操作。但是要注意一点，多数客户端浏览器会将服务器域名与证书中的多个域名（如果存在的话，）进行对比，如果域名出现不匹配，则浏览器会向用户显示警告信息。一般来说，生产环境中，通常只有使用基于地址的虚拟主机利用 SSL。
未完待续...
感觉本站内容不错，读后有收获？小额赞助,鼓励网站分享出更好的教程