利用SSL/TLS中的SNI同一ip不同域名的F5vs配置解决方案

简介:

前言:

在搭建支持HTTPS的前端代理服务器时候,通常会遇到让人头痛的证书问题。根据HTTPS的工作原理,浏览器在访问一个HTTPS站点时,先与服务器建立SSL连接,建立连接的第一步就是请求服务器的证书。而服务器在发送证书的时候,是不知道浏览器访问的是哪个域名的,所以不能根据不同域名发送不同的证书。用过GoAgent的人都知道需要给浏览器导入证书才能使用HTTPS正常登录Twitter等网站。

SNI(Server Name Indication)是为了解决一个服务器使用多个域名和证书的SSL/TLS扩展。一句话简述它的工作原理就是,在连接到服务器建立SSL链接之前先发送要访问站点的域名(Hostname),这样服务器根据这个域名返回一个合适的证书。目前,大多数操作系统和浏览器都已经很好地支持SNI扩展,OpenSSL 0.9.8已经内置这一功能,据说新版的nginx也支持SNI。

HTTPS与SNI扩展,一个IP绑定多个SSL证书

早期的SSLv2根据经典的公钥基础设施PKI(Public Key Infrastructure)设计,它默认认为:一台服务器(或者说一个IP)只会提供一个服务,所以在SSL握手时,服务器端可以确信客户端申请的是哪张证书。

但是让人万万没有想到的是,虚拟主机大力发展起来了,这就造成了一个IP会对应多个域名的情况。解决办法有一些,例如申请泛域名证书,对所有*.yourdomain.com的域名都可以认证,但如果你还有一个yourdomain.net的域名,那就不行了。

在HTTP协议中,请求的域名作为主机头(Host)放在HTTP Header中,所以服务器端知道应该把请求引向哪个域名,但是早期的SSL做不到这一点,因为在SSL握手的过程中,根本不会有Host的信息,所以服务器端通常返回的是配置中的第一个可用证书。因而一些较老的环境,可能会产生多域名分别配好了证书,但返回的始终是同一个。

既然问题的原因是在SSL握手时缺少主机头信息,那么补上就是了。

SNI(Server Name Indication)定义在RFC 4366,是一项用于改善SSL/TLS的技术,在SSLv3/TLSv1中被启用。它允许客户端在发起SSL握手请求时(具体说来,是客户端发出SSL请求中的ClientHello阶段),就提交请求的Host信息,使得服务器能够切换到正确的域并返回相应的证书。

[warning]要使用SNI,需要客户端和服务器端同时满足条件,幸好对于现代浏览器来说,大部分都支持SSLv3/TLSv1,所以都可以享受SNI带来的便利。[/warning]

二. nginx / apache 服务器端实现
nginx和apache服务端支持SNI参见:
《nginx 同一个IP上配置多个HTTPS主机》
《apache mod_gnutls实现多HTTPS虚拟主机》

三. 支持SNI的浏览器、服务器、库
Internet Explorer 7 or later, on Windows Vista or higher. Does not work on Windows XP, even Internet Explorer 8.
Mozilla Firefox 2.0 or later
Opera 8.0 or later (the TLS 1.1 protocol must be enabled)
Opera Mobile at least version 10.1 beta on Android[citation needed]
Google Chrome (Vista or higher. XP on Chrome 6 or newer. OS X 10.5.7 or higher on Chrome 5.0.342.1 or newer)
Safari 2.1 or later (Mac OS X 10.5.6 or higher and Windows Vista or higher)
Konqueror/KDE 4.7 or later
MobileSafari in Apple iOS 4.0 or later
Android default browser on Honeycomb or newer
Windows Phone 7[citation needed]
MicroB on Maemo

四. 支持SNI的服务器
Apache 2.2.12 or later using mod_ssl(or alternatively with experimental mod_gnutls)
Cherokee if compiled with TLS support
Versions of lighttpd 1.4.x and 1.5.x with patch, or 1.4.24+ without patch
Nginx with an accompanying OpenSSL built with SNI support
LiteSpeed 4.1 or later
Pound 2.6 or later
Apache Tomcat on Java 7 or later
Microsoft Internet Information Server IIS 8

五. 支持SNI的库
Mozilla NSS 3.11.1 client-side only
OpenSSL
0.9.8f (released 11 Oct 2007) – not compiled in by default, can be compiled in with config option ‘–enable-tlsext’
0.9.8j (released 07 Jan 2009) through 1.0.0 (released 29 March 2010) – compiled in by default
GNU TLS
libcurl / cURL since 7.18.1 (released 30 Mar 2008) when compiled against an SSL/TLS toolkit with SNI support
Python 3.2 (ssl, urllib and httplib modules)
Qt 4.8
Oracle Java 7 JSSE


-------------------------------F5-----------------------

K13452: Configuring a virtual server to serve multiple HTTPS sites using the TLS Server Name Indication feature

Non-Diagnostic

   

Original Publication Date
Updated Date:

Applies to (see versions):

Topic

Purpose

You should consider using this procedure under the following condition:

  • You want to configure a single virtual server to serve multiple HTTPS sites using the Transport Layer Security (TLS) Server Name Indication (SNI) feature.

Prerequisites

You must meet the following prerequisite to use this procedure:

  • The certificate and key pairs for each of the HTTPS sites must be hosted on the virtual server.

Description

Prior to the introduction of TLS SNI as part of the TLS extensions, a single virtual server could not host multiple secure websites. This was the case because the destination server name can be decoded from the HTTP request header only after the Secure Sockets Layer (SSL) connection has been established.

With the introduction of TLS SNI, the client that supports TLS SNI can indicate the name of the server to which the client is attempting to connect, in the ClientHello packet, during the SSL handshake process. The server that supports TLS SNI can use this information to select the appropriate SSL certificate to return to the client in the ServerHello packet during the SSL handshake. As a result, the client can establish secure connections to the desired secure website from the list of multiple secure websites that are hosted on a single virtual server.

To support the TLS SNI feature, a virtual server must be assigned a default SSL profile for fallback and one SSL profile per HTTPS site. The fallback SSL profile is used when the server name does not match or when the client does not support the TLS SNI extensions. The following list is an example of the sequence of events that may occur when two clients, clientA (which supports the TLS SNI extension) and clientB (which does not support the TLS SNI extension), attempt to establish secure connections with the HTTPS site my.site1.com that is hosted on the TLS SNI virtual server:

  1. clientA establishes a TCP connection to the TLS SNI virtual server.

  2. clientA indicates the server name my.site1.com in its ClientHello packet and forwards the ClientHello packet to the TLS SNI virtual server.

  3. The TLS SNI virtual server observes that the server name my.site1.com is indicated in the received ClientHello packet.

  4. The TLS SNI virtual server checks its list of assigned SSL profiles and selects the SSL profile mysite1profile that has the server name my.site1.comconfigured.

  5. The TLS SNI virtual server returns mysite1profile's SSL certificate in its ServerHello packet to clientA.

  6. clientA establishes a secure connection to the TLS SNI virtual server after it successfully negotiates the remaining SSL options during the SSL handshake.

  7. clientB establishes a TCP connection to the TLS SNI virtual server.

  8. clientB does not support TLS SNI extension, hence there is no server name indicated in its ClientHello packet to the TLS SNI virtual server.

  9. The TLS SNI virtual server observes no SNI extension in the received ClientHello packet and selects the fallback SSL profile mydefaultprofile.

  10. The TLS SNI virtual server returns mydefaultprofile's SSL certificate (with CN my.default.com) in its ServerHello packet to clientB.

  11. clientB warns of a possible certificate mismatch when it receives the SSL certificate (with CN my.default.com) from the ServerHello packet.

For security purposes, F5 recommends that you configure the following settings with the same values for all of the SSL/TLS SNI profiles associated with the same virtual server:

  • Ciphers

  • Client Authentication

    • Client Certificate

    • Frequency

    • Certificate Chain Traversal Depth

    • Advertised Certificate Authorities

    • Certificate Revocation List (CRL)

In BIG-IP 11.2.0 and later, the BIG-IP system will display an error message that appears similar to the following example if any of the settings are non-matching:

0107157c:3: Selected client SSL profiles do not match security policies for Virtual Server /Common/<virtual server>

Additionally, the BIG-IP system displays this error message if you attempt to reconfigure the previously mentioned settings in any of the SSL/TLS SNI profiles associated with the same virtual server. To avoid this error message in subsequent attempts to reconfigure the previously mentioned settings, F5 recommends that you configure a base SSL/TLS SNI profile and use this base profile as the parent profile for the SSL/TLS SNI profiles associated to the same virtual server.

Procedures

To configure multiple HTTPS sites using TLS SNI, you must perform the following procedures:

Importing the SSL certificate and key pairs for each server name

Before you begin configuring the BIG-IP objects for TLS SNI, you must import, to the BIG-IP system, all of the SSL certificate and key pairs that belong to the multiple HTTPS sites. To do so, perform the following procedure:

Impact of procedure: Performing the following procedure should not have a negative impact on your system.

  1. Log in to the Configuration utility.

  2. Click System.

  3. Click File Management.

  4. Click SSL Certificate List.

  5. Click Import.

  6. From the Import Type menu, select Key.

  7. In the Key Name box, type a name for the certificate and key pair.

  8. To locate the key file, click Browse.

  9. To upload the key file to the BIG-IP system, click Import.

  10. Click the name of the certificate and key pair from the SSL Certificate List.

  11. Click Import.

  12. To locate the certificate file, click Browse.

  13. To upload the certificate file to the BIG-IP system, click Import.

  14. To import each SSL certificate and key pair, repeat steps 5 through 13.

Configuring the base client SSL profile

To facilitate subsequent reconfiguration of the Cipher and/or Client Authentication settings described in the earlier part of this article, you should create a base client SSL profile to serve as the parent profile of the SSL/TLS SNI profiles associated with the same virtual server. To do so, perform the following procedure:

Impact of procedure: Performing the following procedure should not have a negative impact on your system.

  1. If you have not done so, log in to the Configuration utility.

  2. Click Local Traffic.

  3. Click Profiles.

  4. Click SSL.

  5. Click Client.

  6. Click Create.

  7. In the Name box, type a name for the base client SSL profile.

  8. Optional: Configure the remaining client SSL profile options, as desired.

  9. Click Finished.

Configuring the fallback (default) client SSL profile

The system uses the fallback client SSL profile as the default SSL profile when there is no match to the server name, or when the client provides no SNI extension support. You can assign only one fallback SSL profile to each TLS SNI virtual server. To configure the fallback client SSL profile, perform the following procedure:

Note: For clients that do not support TLS SNI, if the requested server name does not match the certificate and key pair for the fallback profile, clients receive certificate warnings.

Impact of procedure: Performing the following procedure should not have a negative impact on your system.

  1. If you have not done so, log in to the Configuration utility.

  2. Click Local Traffic.

  3. Click Profiles.

  4. Click SSL.

  5. Click Client.

  6. Click Create.

  7. In the Name box, type a name for the fallback client SSL profile.

  8. For the Parent Profile setting, select the base client SSL profile you have created in the Configuring the base client SSL profile procedure.

  9. From the Configuration menu, select Advanced.

  10. Select the Certificate Key Chain check box, select the desired certificate and key for fallback, and click Add.

    Note: For BIG-IP versions earlier than 11.5.0, select the individual Certificate and Key checkboxes, and then select the desired certificates and keys for fallback.

  11. Check both the boxes for Default SSL Profile for SNI.

  12. Optional: Configure the remaining client SSL profile options, as desired.

  13. Click Finished.

Configuring the client SSL profiles for TLS SNI

To support TLS SNI, you must configure one client SSL profile per HTTPS site. To do so, perform the following procedure:

Note: Beginning in BIG-IP 11.6.0, if you leave the Server Name field blank, the BIG-IP system reads the Subject Alternative Name (SAN) from the certificate. You can skip steps 10 and 11 of this section if Hostname is used for SAN.

Impact of procedure: Performing the following procedure should not have a negative impact on your system.

  1. Log in to the Configuration utility.

  2. Click Local Traffic.

  3. Click Profiles.

  4. Click SSL.

  5. Click Client.

  6. Click Create.

  7. In the Name box, type a name for a HTTPS site’s client SSL profile.

  8. For the Parent Profile setting, select the base client SSL profile you have created in the Configuring the base client SSL profile procedure.

  9. From the Configuration menu, select Advanced.

  10. Select the Certificate Key Chain check box, select the desired certificate and key for the HTTPS site, and click Add.

    Note: For BIG-IP versions earlier than 11.5.0, select the individual Certificate and Key check boxes, and then select the desired certificate and key for the HTTPS site.

  11. Select the Server Name check box.

  12. Type the name of the HTTPS site in the Server Name box.

    Note: Beginning in BIG-IP 11.6.0, if you leave the Server Name box blank, the BIG-IP system reads the Subject Alternative Name (SAN) from the certificate. For versions prior to BIG-IP 11.6.0, if you leave the Server Name box blank, the BIG-IP system reads the Common Name (CN) from the certificate.

  13. Optional: Configure the remaining client SSL profile options, as desired.

  14. Click Finished.

  15. Repeat steps 7 through 13 for each HTTPS site.

Configuring the virtual server for TLS SNI

To configure a virtual server for TLS SNI, you must assign the related client SSL profiles to the virtual server. To do so, perform the following procedure:

Impact of procedure: Performing the following procedure should not have a negative impact on your system.

  1. Log in to the Configuration utility.

  2. Click Local Traffic.

  3. Click Virtual Servers.

  4. Click Virtual Server List.

  5. Click Create.

  6. In the Name box, type the name of the virtual server.

  7. In the Address box, type the IP address of the virtual server.

  8. In the Service Port box, type the listening port number of the virtual server.

  9. From the HTTP Profile menu, select the appropriate HTTP profile.

  10. Select the backup client SSL profile created in the previous procedure from the Available box for SSL Profile (Client), and click the << button.

  11. Select the HTTPS site’s client SSL profile created in the previous procedure from the Available box for SSL Profile (Client), and click the << button.

  12. Repeat the previous step for each HTTPS site.

  13. Optional: Configure the remaining virtual server options, as desired.

  14. Click Finished.

Supplemental Information










本文转自 河北李晓东  51CTO博客,原文链接:http://blog.51cto.com/lixiaodong2016/1958740,如需转载请自行联系原作者
相关实践学习
基于函数计算快速搭建Hexo博客系统
本场景介绍如何使用阿里云函数计算服务命令行工具快速搭建一个Hexo博客。
目录
相关文章
|
27天前
|
域名解析 缓存 网络协议
【域名解析DNS专栏】IPv6与DNS:兼容性挑战与解决方案
【5月更文挑战第29天】随着IPv6逐渐成为互联网主流,DNS面临兼容性挑战,包括解析机制差异、资源记录类型扩展和查询流程优化。为解决这些问题,可采取升级DNS系统以支持IPv6、部署双栈DNS服务和优化DNS缓存策略。通过这些措施,可确保IPv6环境下的域名解析顺利进行。
|
1月前
|
域名解析 缓存 运维
【域名解析DNS专栏】域名解析故障排查手册:常见问题与解决方案
【5月更文挑战第22天】【DNS故障排查手册】解决域名无法解析、速度慢、污染劫持及配置错误问题。检查网络、清理缓存、更换DNS服务器、使用HTTPS、DNSSEC及CDN。示例:使用nslookup查询域名解析。定期检查优化DNS服务器,确保稳定安全。
【域名解析DNS专栏】域名解析故障排查手册:常见问题与解决方案
|
1月前
|
域名解析 存储 缓存
【域名解析DNS专栏】动手实践:手动配置DNS解析记录
【5月更文挑战第22天】本文介绍了DNS解析记录的概念及其手动配置步骤。DNS解析记录是将域名映射到IP地址的数据,常见类型包括A(IPv4)、AAAA(IPv6)和CNAME(别名)。配置步骤包括登录DNS管理平台,添加记录,选择记录类型,填写主机记录和记录值,设置TTL值,并保存。以阿里云为例的A记录配置示例也提供了具体操作。了解这些有助于更好地管理域名。
【域名解析DNS专栏】动手实践:手动配置DNS解析记录
|
15天前
|
消息中间件 Serverless Go
Serverless 应用引擎操作报错合集之通过自定义域名配置jwt认证,始终报错:"Code": "JWTTokenIsInvalid",是什么导致的
Serverless 应用引擎(SAE)是阿里云提供的Serverless PaaS平台,支持Spring Cloud、Dubbo、HSF等主流微服务框架,简化应用的部署、运维和弹性伸缩。在使用SAE过程中,可能会遇到各种操作报错。以下是一些常见的报错情况及其可能的原因和解决方法。
|
15天前
|
存储 运维 Serverless
Serverless 应用引擎产品使用合集之为SD函数配置域名并添加路径/sd后无法正常访问,如何配置自定义域名
阿里云Serverless 应用引擎(SAE)提供了完整的微服务应用生命周期管理能力,包括应用部署、服务治理、开发运维、资源管理等功能,并通过扩展功能支持多环境管理、API Gateway、事件驱动等高级应用场景,帮助企业快速构建、部署、运维和扩展微服务架构,实现Serverless化的应用部署与运维模式。以下是对SAE产品使用合集的概述,包括应用管理、服务治理、开发运维、资源管理等方面。
|
23天前
|
网络安全 安全 Java
Java一分钟之-SSL/TLS:安全套接字层与传输层安全
【6月更文挑战第2天】本文介绍了SSL/TLS协议在保护数据传输中的作用,以及Java中使用JSSE实现SSL/TLS的基础。内容涵盖SSL/TLS工作流程、版本、常见问题及解决办法。通过`SSLSocket`和`SSLServerSocket`示例展示了服务器和客户端的实现,并强调证书管理、配置检查和依赖更新的最佳实践,以确保安全的通信。
50 4
|
28天前
|
域名解析 缓存 监控
【域名解析 DNS 专栏】解析失败的 DNS 重试策略与配置优化
【5月更文挑战第28天】DNS解析在数字化时代关键但常遇失败,可能由网络、服务器或域名错误引起。实施智能重试策略(如指数级增长的重试间隔)和配置优化(如选用可靠DNS服务器、设置缓存、监控预警)能提高成功率和系统稳定性。示例代码展示基本DNS重试函数,强调需按业务需求调整策略并配合监控以保证高效稳定的DNS解析。
|
1月前
|
安全 算法 应用服务中间件
SSL/TLS协议信息泄露漏洞(CVE-2016-2183)【原理扫描】
SSL/TLS协议信息泄露漏洞(CVE-2016-2183)【原理扫描】 【可验证】 详细描述TLS是安全传输层协议,用于在两个通信应用程序之间提供保密性和数据完整性。
388 2
|
19天前
|
前端开发 Java 网络安全
基于Java Socket实现的SMTP邮件客户端 - 全面支持SSL, TLS
基于Java Socket实现的SMTP邮件客户端 - 全面支持SSL, TLS
19 0
|
21天前
微信登陆报错:redirect_uri域名与后台配置不一致,错误码:10003 微信支付报错 微信登录报错 微信开发
微信登陆报错:redirect_uri域名与后台配置不一致,错误码:10003 微信支付报错 微信登录报错 微信开发
21 0

热门文章

最新文章