David Garcia Asked: 2016-02-13 03:05:48 +0800 CST2016-02-13 03:05:48 +0800 CST 2016-02-13 03:05:48 +0800 CST 负载均衡器或服务器上的 SSL 证书 772 我有一个负载均衡器在两台服务器之间分配流量,面向公众的 url 都是以 https 为前缀的。 我想生成一个通配符 ssl 证书,但我不确定将它放在负载均衡器中还是放在两台服务器中更好?有什么建议?有什么好处和区别。 谢谢 windows-server-2008 3 个回答 Voted Best Answer Castaglia 2016-02-13T21:14:28+08:002016-02-13T21:14:28+08:00 一种非常常见的做法(我不会说standard)是将证书放置/配置在负载均衡器中,而不是在后端服务器中。为什么?这使负载均衡器能够处理 TLS 握手/终止开销(即TLS 消息的内存/CPU),而不是让后端应用程序服务器使用它们的CPU 进行加密,除了提供应用程序行为。因此,将 TLS 终止置于应用程序服务器之前通常是“专业人士”。 这也允许在到您的服务器的单一路由上缓存 TLS 会话(即通过负载平衡器),这意味着使用缓存的 TLS 会话的机会更大。另一方面,如果您在每个后端服务器上配置了证书,那么这些服务器将(可能)拥有自己独立的TLS 会话缓存;负载均衡器可能(也可能不会)将客户端定向到缓存了其TLS 会话的后端服务器。 所以简短的版本是:在负载均衡器中配置证书是通常推荐的方法。 希望这可以帮助! HBruijn 2016-02-14T15:01:25+08:002016-02-14T15:01:25+08:00 如果您不将证书加载到负载平衡器上,则只能对 TCP/IP 连接进行负载平衡,因为流量本身是加密的。 通过在负载均衡器上加载证书,您可以在那里做各种更有趣的事情,具体取决于负载均衡器的能力: 创建会话持久性/粘性会话,这样来自特定用户的后续请求将始终路由到相同的后端服务器(例如基于会话 cookie),这比使用源 IP 地址作为基础更可靠亲和性,当您在 LB 上没有证书时,这是唯一的选择。 将不同的 URL 路由到不同的后端服务器池,即直接example.com/app-1到不同的应用程序服务器而不是那些用于example.com/app-2 等等 很多时候,您会终止 LB 上的 TLS/SSL 连接,并且在 LB 和后端服务器之间有未加密的流量,但如果您的安全要求是这样的话,没有什么能阻止您在那里建立第二个 TLS/SSL 连接。 rosey85uk 2016-02-14T09:00:14+08:002016-02-14T09:00:14+08:00 正如 TJ 提到的,在负载均衡器上安装 SSL CERTS,这可以处理工作并将用户卸载到后端服务器。 在 Digital Ocean 中有一个很好的示例/教程,在 CentOS 7 HA 代理服务器上安装 Lets Encrypt 证书?
一种非常常见的做法(我不会说standard)是将证书放置/配置在负载均衡器中,而不是在后端服务器中。为什么?这使负载均衡器能够处理 TLS 握手/终止开销(即TLS 消息的内存/CPU),而不是让后端应用程序服务器使用它们的CPU 进行加密,除了提供应用程序行为。因此,将 TLS 终止置于应用程序服务器之前通常是“专业人士”。
这也允许在到您的服务器的单一路由上缓存 TLS 会话(即通过负载平衡器),这意味着使用缓存的 TLS 会话的机会更大。另一方面,如果您在每个后端服务器上配置了证书,那么这些服务器将(可能)拥有自己独立的TLS 会话缓存;负载均衡器可能(也可能不会)将客户端定向到缓存了其TLS 会话的后端服务器。
所以简短的版本是:在负载均衡器中配置证书是通常推荐的方法。
希望这可以帮助!
如果您不将证书加载到负载平衡器上,则只能对 TCP/IP 连接进行负载平衡,因为流量本身是加密的。
通过在负载均衡器上加载证书,您可以在那里做各种更有趣的事情,具体取决于负载均衡器的能力:
example.com/app-1
到不同的应用程序服务器而不是那些用于example.com/app-2
很多时候,您会终止 LB 上的 TLS/SSL 连接,并且在 LB 和后端服务器之间有未加密的流量,但如果您的安全要求是这样的话,没有什么能阻止您在那里建立第二个 TLS/SSL 连接。
正如 TJ 提到的,在负载均衡器上安装 SSL CERTS,这可以处理工作并将用户卸载到后端服务器。
在 Digital Ocean 中有一个很好的示例/教程,在 CentOS 7 HA 代理服务器上安装 Lets Encrypt 证书?