对 SSL 配置和 Tomcat 感到困惑答案

【问题标题】：Confused with SSL configuration and Tomcat对 SSL 配置和 Tomcat 感到困惑
【发布时间】：2010-06-25 16:42:31
【问题描述】：

我们的应用程序在两个框架中运行。一个使用https，一个不使用。我正在尝试配置 tomcat 连接器以使其工作，但是当我让它在一个框架中工作时，它在另一个框架中不起作用。

有人告诉我，我们不需要完全“处理” SSL，因为这是由我们的负载平衡器处理的。不确定这些是什么意思。

例如：在一个框架中，我们会得到权限被拒绝的错误，而另一个框架会起作用。如果我们改变相反的情况，但我们会得到无效证书错误而不是权限错误。

关于连接器的 tomcat 文档没有很好地描述这些选项。知道我们做错了什么吗？

<Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000"/>

<Connector port="443" protocol="HTTP/1.1" SSLEnabled="false" maxThreads="150" scheme="https" secure="false" clientAuth="false" sslProtocol="TLS"/>

上述连接器适用于 http 框架，但在 IE 中给了我“混合内容警告”，因为一些请求是 http 和一些 https。

任何帮助将不胜感激。

【问题讨论】：

标签： tomcat ssl tomcat6

【解决方案1】：

如果你有一个监听端口 443 的连接器，它应该启用 SSL，因为那是 HTTPS 端口，浏览器将在连接后立即发送 SSL ClientHello 消息——除非服务器不理解这一点已启用 SSL。

可能是您的负载平衡器正在终止 SSL 连接，并通过纯 HTTP 将请求转发到 Tomcat。在这种情况下，您不需要端口 443 上的连接器。

但是，听起来您的某个应用程序可能正在使用客户端证书来执行身份验证。查看 web.xml 文件中的 login-config 元素。使用了哪些身份验证方法？

如果您需要客户端证书，但 SSL 在负载平衡器处终止，则无法进行身份验证，因为客户端证书永远不会到达 Tomcat。

【讨论】：

这里看起来不需要客户端证书，但您实际上可以通过使用 mod_headers 和类似 mod_proxy 的东西将客户端证书传递给 Tomcat（也可以在没有 mod_headers 和 mod_jk 的情况下使用）：SSLOptions +StdEnvVars +ExportCertData RequestHeader 设置 SSL_CLIENT_CERT %{SSL_CLIENT_CERT}e

【解决方案2】：

如果您使用负载均衡器，例如带有 mod_proxy 的 Apache Httpd（反向模式），SSL 连接将从浏览器连接到负载均衡器（正如“erickson”所说）。您确实可以在 web.xml 文件中检查 login-config（以检查您是否使用 CLIENT-CERT）。

您可能遇到的另一个问题是 web.xml 中的transport-guarantee 元素：

<security-constraint>
   <user-data-constraint>
      <transport-guarantee>CONFIDENTIAL</transport-guarantee>
   </user-data-constraint>
</security-constraint>

当您确定自己是一个安全的负载平衡器时，似乎有一种方法可以通过自定义阀门强制执行此操作。这里是an article on the subject (translated from French)。

混合内容最可能的原因是加载的图片不是托管在 SSL 上的。您可能会发现模板中某处有一个用http:// 硬编码的公司徽标，或者某些Location 标头返回http:// URL。后者可以使用类似 Apache Httpd 的配置来修复（假设它是您的负载均衡器），当然您需要用正确的地址替换它：

Header edit Location ^http://www.example.com/test/ https://www.example.com/test/

许多网站（甚至来自大公司的网站）都混合了内容。这实际上是一件坏事，因为：

如果不查看所有请求，可能还需要查看页面来源，用户无法真正知道页面的哪些部分是安全的，哪些不安全。
一些从 HTTPS 请求到普通 HTTP 请求的 cookie 和信息泄漏。如果有人通过纯 HTTP 捕获该 cookie，他们可能会通过 HTTPS 将其用作冒名顶替者。（尤其是在使用没有安全标志的 cookie 时。）

【讨论】：