图片 1

至于启用 HTTPS 的有的经历共享(二)

2015/12/24 · 基本功技术 ·
HTTP,
HTTPS

初稿出处:
imququ(@屈光宇)   

小说目录

  • SSL 版本选取
  • 加密套件采纳
  • SNI 扩展
  • 评释选拔

几天前,一人相爱的人问作者:都说推荐用 Qualys SSL
Labs 这几个工具测验 SSL
安全性,为何有个别安全实力很强的大厂商评分也比较低?笔者觉着这几个主题素材应该从双方面来看:1)本国顾客终端景况复杂,非常多时候降落
SSL 安全配置是为着同盟越来越多顾客;2)确实有一对大商家的 SSL
配置很不专门的学问,特别是布署了部分显然不应当使用的 CipherSuite。

本人在此之前写的《至于启用 HTTPS
的局地经历分享(一)》,首要介绍 HTTPS
怎么着与局地新出的景德镇专门的学问合营使用,面向的是今世浏览器。而明日那篇文章,更加多的是介绍启用
HTTPS 进度中在老旧浏览器下只怕遇见的难题,以及哪些抉择。

SSL 版本选用

TLS(传输层安全(Transport Layer Security))的前身是
SSL(安全套接字层(Secure Sockets Layer)),它最先的多少个版本(SSL
1.0、SSL 2.0、SSL 3.0)由网景公司开荒,从 3.1 伊始被 IETF
标准化并更名,发展到现在已经有 TLS 1.0、TLS 1.1、TLS 1.2 四个本子。TLS 1.3
退换会十分的大,这两天还在草案阶段。

SSL 1.0 从未公开过,而 SSL 2.0 和 SSL 3.0
都设有安全难点,不引入应用。Nginx 从 1.9.1 开头默许只援救 TLS
的多个本子,以下是
Nginx 合英文书档案中对 ssl_protocols 配置的认证:

Syntax: ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1]
[TLSv1.2];
Default: ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Context: http, server
Enables the specified protocols. The TLSv1.1 and TLSv1.2 parameters
work only when the OpenSSL library of version 1.0.1 or higher is used.

但不幸的是,IE 6 只帮助 SSLv2 和
SSLv3(来源),也正是说
HTTPS 网址要支持 IE 6,就亟须启用 SSLv3。仅这一项就能够形成 SSL Labs
给出的评分降为 C。

 

SNI 扩展

作者们掌握,在 Nginx
中能够透过点名区别的 server_name 来配置八个站点。HTTP/1.1
公约央求头中的 Host 字段能够标志出当下恳请属于哪个站点。可是对于 HTTPS
网址来讲,要想发送 HTTP 数据,必得等待 SSL
握手完结,而在拉手阶段服务端就必需提供网址证书。对于在同贰个 IP 计划不相同HTTPS 站点,並且还选择了差异证书的景况下,服务端怎么了解该发送哪个证书?

Server Name Indication,简称为 SNI,是 TLS
的三个扩大,为消除这么些主题材料出现。有了
SNI,服务端能够因此 Client Hello 中的 SNI 增添得到用户要拜候网址的
Server Name,进而发送与之协作的证书,顺遂完结 SSL 握手。

Nginx 在很早在此以前就援救了
SNI,能够因此 nginx -V 来验证。以下是本身的验证结果:

  1. ./nginx -V
  2. nginx version: nginx/1.9.9
  3. built by gcc4.8.4(Ubuntu4.8.4-2ubuntu1~14.04)
  4. built withOpenSSL1.0.2e-dev xx XXX xxxx
  5. TLS SNI support enabled
  6. configure arguments:--with-openssl=../openssl --with-http_ssl_module --with-http_v2_module

只是,并非负有浏览器都帮忙 SNI,以下是大面积浏览器支持 SNI 的最低版本:

浏览器 最低版本
Chrome Vista+ 全支持;XP 需要 Chrome 6+;OSX 10.5.7+ 且 Chrome 5+
Firefox 2.0+
Internet Explorer 7+ (需要 Vista+)
Safari 3+ (需要 OS X 10.5.6+)
Mobile Safari iOS 4.0+
Android Webview 3.0+

能够见见,今后还也许有一定顾客量的 Windows XP IE6~8、Android 2.x Webview
都不帮助 SNI。纵然要幸免在那一个浏览器中冒出证书错误,只好将选择分裂证书的
HTTPS 站点布局在分裂 IP 上,最简便的做法是分开布置到差异机器上。

 

报名 Let’s Encrypt 证书时,平昔不可能印证通过

那类难点一般是因为 Let’s Encrypt
不可能访问你的服务器,推荐尝试 acme.sh 的 DNS
验证方式,一般都能化解。

SNI 扩展

大家通晓,在 Nginx 中得以经过点名不一致的 server_name
来配置多少个站点。HTTP/1.1 合同要求头中的 Host
字段能够标志出近日央求属于哪个站点。但是对于 HTTPS 网址来讲,要想发送
HTTP 数据,必须等待 SSL
握手完毕,而在握手阶段服务端就非得提供网址证书。对于在同一个 IP 安排差异HTTPS 站点,并且还接纳了不一致证书的场合下,服务端怎么通晓该发送哪个证书?

Server Name Indication,简称为 SNI,是 TLS
的叁个扩大,为化解那几个题材应时而生。有了 SNI,服务端能够经过
Client Hello 中的 SNI 扩大得到客户要拜谒网址的 Server
Name,进而发送与之相称的证件,顺利落成 SSL 握手。

Nginx 在很早从前就补助了 SNI,能够透过 nginx -V
来验证。以下是自身的申明结果:

./nginx -V nginx version: nginx/1.9.9 built by gcc 4.8.4 (Ubuntu
4.8.4-2ubuntu1~14.04) built with OpenSSL 1.0.2e-dev xx XXX xxxx TLS SNI
support enabled configure arguments: –with-openssl=../openssl
–with-http_ssl_module –with-http_v2_module

1
2
3
4
5
6
./nginx -V
nginx version: nginx/1.9.9
built by gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)
built with OpenSSL 1.0.2e-dev xx XXX xxxx
TLS SNI support enabled
configure arguments: –with-openssl=../openssl –with-http_ssl_module –with-http_v2_module

只是,实际不是享有浏览器都协助 SNI,以下是周围浏览器协助 SNI 的最低版本:

浏览器 最低版本
Chrome Vista+ 全支持;XP 需要 Chrome 6+;OSX 10.5.7+ 且 Chrome 5+
Firefox 2.0+
Internet Explorer 7+ (需要 Vista+)
Safari 3+ (需要 OS X 10.5.6+)
Mobile Safari iOS 4.0+
Android Webview 3.0+

一旦要防止在不协理 SNI 的浏览器中冒出证书错误,只可以将应用分裂证书的
HTTPS 站点布局在差别 IP 上,最轻松易行的做法是分别布置到区别机器上。

 

加密套件选择

加密套件(CipherSuite),是在 SSL
握手中需求交涉的很首要的三个参数。客商端会在 Client Hello 中带上它所帮衬的
CipherSuite
列表,服务端会从中选定多少个并由此 Server Hello 重回。要是客商端扶助的
CipherSuite 列表与服务端配置的 CipherSuite
列表未有交集,会导致无法达成商业事务,握手退步。

CipherSuite
包涵多样技术,例如认证算法(Authentication)、加密算法(Encryption)、音信认证码算法(Message
Authentication Code)(MAC)、密钥调换算法(Key
Exchange)和密钥衍生算法(Key Derivation Function)。

SSL 的 CipherSuite 协商业机械制具备非凡的扩大性,每一种 CipherSuite 都亟需在
IANA 注册,并被分配四个字节的标记。全体 CipherSuite 能够在 IANA 的 TLS
Cipher Suite Registry 页面查看。

OpenSSL 库协理的全套 CipherSuite 可以透过以下命令查看:

  1. openssl ciphers -V | column -t
  2. 0xCC,0x14- ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2Kx=ECDH Au=ECDSA Enc=ChaCha20-Poly1305Mac=AEAD
  3. ......

0xCC,0x14 是 CipherSuite 的号子,在 SSL
握手中会用到。ECDHE-ECDSA-CHACHA20-POLY1305 是它的名号,之后几某个各自表示:用于
TLSv1.2,使用 ECDH 做密钥交流,使用 ECDSA 做验证,使用 ChaCha20-Poly1305
做对称加密,由于 ChaCha20-Poly1305 是一种 AEAD 情势,没有供给 MAC
算法,所以 MAC 列展现为 AEAD。

要了然 CipherSuite 的更加多内容,能够阅读那篇长文《TLS 共同商议深入分析 与
今世加密通讯公约设计》。综上说述,在铺排 CipherSuite
时,请必须参谋权威文档,如:Mozilla 的推荐介绍配置、CloudFlare 使用的配备。

如上 Mozilla 文书档案中的「Old backward compatibility」配置,以及 CloudFlare
的配置,都可以很好的相配老旧浏览器,富含 Windows XP / IE6。

事先看到有些大商家乃至协理满含 EXPORT 的
CipherSuite,那些套件在上世纪由于花旗国出口限制而被弱化过,已被占领,实在未有理由再利用。

 

实质上,碰到别的关于陈设 HTTPS 或 HTTP/2 的难题,都推荐先用 Qualys SSL
Labs’s SSL Server
Test 跑个测量试验,大多数难题都能被会诊出来。

加密套件选取

加密套件(CipherSuite),是在 SSL
握手中必要构和的相当的重大的一个参数。顾客端会在 Client Hello
中带上它所支撑的 CipherSuite 列表,服务端会从中选定三个并通过
Server Hello 重临。假诺客商端援助的 CipherSuite 列表与服务端配置的
CipherSuite 列表未有交集,会招致无计可施到位协商,握手失利。

CipherSuite
包罗多样技术,比方认证算法(Authentication)、加密算法(Encryption)、音讯认证码算法(Message
Authentication Code,简称为 MAC)、密钥沟通算法(Key
Exchange)和密钥衍生算法(Key Derivation Function)。

SSL 的 CipherSuite 协商业机械制具有地利人和的扩展性,每种 CipherSuite 都急需在
IANA 注册,并被分配五个字节的注解。全体 CipherSuite 能够在 IANA 的 TLS
Cipher Suite
Registry
页面查看。

OpenSSL 库援助的漫天 CipherSuite 能够通过以下命令查看:

openssl ciphers -V | column -t 0xCC,0x14 – ECDHE-ECDSA-CHACHA20-POLY1305
TLSv1.2 Kx=ECDH Au=ECDSA Enc=ChaCha20-Poly1305 Mac=AEAD … …

1
2
3
openssl ciphers -V | column -t
0xCC,0x14  –  ECDHE-ECDSA-CHACHA20-POLY1305  TLSv1.2  Kx=ECDH        Au=ECDSA   Enc=ChaCha20-Poly1305  Mac=AEAD
… …

0xCC,0x14 是 CipherSuite 的编号,在 SSL
握手中会用到。ECDHE-ECDSA-CHACHA20-POLY1305
是它的名目,之后几片段各自表示:用于 TLSv1.2,使用 ECDH 做密钥沟通,使用
ECDSA 做阐明,使用 ChaCha20-Poly1305 做对称加密,由于 ChaCha20-Poly1305
是一种 AEAD 格局,不要求 MAC 算法,所以 MAC 列展现为 AEAD。

要打听 CipherSuite 的愈来愈多内容,能够阅读那篇长文《TLS 切磋深入分析 与
当代加密通信合同设计》。同理可得,在配备
CipherSuite 时,请必得参谋权威文书档案,如:Mozilla
的引荐配置、CloudFlare
使用的配置。

上述 Mozilla 文书档案中的「Old backward compatibility」配置,以及 CloudFlare
的安顿,都得以很好的协作老旧浏览器,包含 Windows XP / IE6。

事先看到有些大厂商乃至援救包涵 EXPORT
CipherSuite,那几个套件在上世纪由于美利坚联邦合众国讲话限制而被弱化过,已被打下,实在未有理由再利用。

SNI 扩展

咱俩通晓,在 Nginx
中得以因而点名差异的 server_name 来配置五个站点。HTTP/1.1
左券央浼头中的 Host 字段能够标记出这几天恳请属于哪个站点。可是对于 HTTPS
网站来讲,要想发送 HTTP 数据,必需等待 SSL
握手实现,而在握手阶段服务端就务须提供网站证书。对于在同三个 IP 布置分化HTTPS 站点,况且还接纳了不一致证书的气象下,服务端怎么知道该发送哪个证书?

Server Name Indication,简称为 SNI,是 TLS
的一个恢弘,为化解那个主题材料应运而生。有了
SNI,服务端能够通过 Client Hello 中的 SNI 扩展获得顾客要拜候网址的
Server Name,进而发送与之相称的证书,顺遂完成 SSL 握手。

Nginx 在很早在此以前就支持了
SNI,能够经过 nginx -V 来验证。以下是小编的注明结果:

  1. ./nginx -V
  2. nginx version: nginx/1.9.9
  3. built by gcc4.8.4(Ubuntu4.8.4-2ubuntu1~14.04)
  4. built withOpenSSL1.0.2e-dev xx XXX xxxx
  5. TLS SNI support enabled
  6. configure arguments:--with-openssl=../openssl --with-http_ssl_module --with-http_v2_module

但是,并不是有所浏览器都支持 SNI,以下是布满浏览器支持 SNI 的最低版本:

浏览器 最低版本
Chrome Vista+ 全支持;XP 需要 Chrome 6+;OSX 10.5.7+ 且 Chrome 5+
Firefox 2.0+
Internet Explorer 7+ (需要 Vista+)
Safari 3+ (需要 OS X 10.5.6+)
Mobile Safari iOS 4.0+
Android Webview 3.0+

可以看出,以往还应该有一定用户量的 Windows XP IE6~8、Android 2.x Webview
都不援救 SNI。假如要防止在那些浏览器中冒出证书错误,只可以将应用不一致证书的
HTTPS 站点布局在不相同 IP 上,最轻巧易行的做法是分手布置到不相同机器上。

 

评释采取

HTTPS 网址需求经过 CA
获得合法证件,证书通过数字具名本事有限支撑第三方无法伪造。证书的粗略原理如下:

  • 听别人讲版本号、系列号、具名算法标记、发行者名称、有效期、证书主体名、证书主体公钥新闻、发行商独一标志、主体独一标记、扩张生成
    TBSCertificate( 待签字证书(To Be Signed Certificate))音信;
  • 签发数字签名:使用 HASH 函数对 TBSCertificate 总计获得新闻摘要,用
    CA 的私钥对新闻摘要举行加密,获得签名;
  • 校验数字具名:使用同一的 HASH 函数对 TBSCertificate
    计算得到新闻摘要,与运用 CA 公钥解密签字获得内容相相比较;

使��� SHA-1 做为 HASH 函数的证件被喻为 SHA-1 证书,由于当下一度找到
SHA-1 的碰撞标准,将注明换来采用更安全的 SHA-2 做为 HASH 函数的 SHA-2
证书被提上日程。

实质上,微软已经宣示自 2017 年 1 月 1 日起,将通盘终止对 SHA-1
证书的支撑。届时在风行版本的 Windows 系统中,SHA-1 证书将不被信任。

而据说 Chrome 官方博客的篇章,使用 SHA-1 证书且证书保藏期在 二〇一六 年 1 月
1 号至 二〇一五 年 12 月 31
号之间的站点会被赋予「安全的,但存在纰漏」的提醒,也正是地址栏的小锁不再是藕荷色的,况且会有多个色情小三角。而利用
SHA-1 证书且证书保藏期当先 2017 年 1 月 1
号的站点会被赋予「不安全」的新民主主义革命警戒,小锁上一贯展现贰个革命的叉。

不过,实际不是负有的终端都辅助 SHA-2
证书,服务端不匡助辛亏办,浏览器只好依靠于顾客进级了。上面是广泛浏览器支持SHA-2 证书的最低版本:

浏览器 支持 SHA-2 证书的最低版本
Chrome 26+
Firefox 1.5+
Internet Explorer 6+ (需要 XP SP3+)
Safari 3+ (需要 OS X 10.5+)
Android Webview 2.3+

可以看出,假如要照拂未有打 XP SP3 补丁的 IE6 客户,只好继续运用 SHA-1
证书。

在自己事先的篇章中,还关系过 ECC
证书,这种新型的证件支持度更差,这里略过不提,有野趣的校友可以点这里查看。

是还是不是能够针对区别浏览器启用不相同证书吗?理论上服务端能够依赖顾客端 Client Hello 中的
Cipher Suites 特征以及是还是不是协理 SNI
的表征来分配不一致证书,但是本身从来不实际验证过。

本文先写那样多,很多战略都亟需基于本身网址的客商来支配,举个例子作者的博客基本未有IE8- 客户,理之当然能够禁止使用SSLv3。倘令你的产品还应该有众多选拔老旧浏览器的客商,那就必得为那个顾客做合作方案了。一种方案是:只把主域安全品级配低,将
XP 上 IE 客商的 HTTPS 央求直接重定向到 HTTP
版本,那样任何域名能够行使高安全品级的布局,运维起来比较有利。

正文恒久更新链接地址:

HTTPS 计谋几天前,一位相爱的人问小编:都说推荐用Qualys SSL Labs这一个工具测验 SSL
安全性,为何某些安全实力很强的大…

在近年几年里,小编写了成都百货上千关于 HTTPS 和 HTTP/2
的篇章,包涵了注解申请、Nginx
编写翻译及布署、质量优化等任何。在那一个作品的褒贬中,相当的多读者提出了有滋有味的题目,作者的信箱也常常接到类似的邮件。本文用来罗列当中有代表性、且自身晓得实施方案的标题。

证明选择

HTTPS 网址要求通过 CA
获得合法证件,证书通过数字签字本事保障第三方不能伪造。证书的简约原理如下:

  • 遵照版本号、连串号、具名算法标志、发行者名称、保质期、证书主体名、证书主体公钥消息、发行商独一标记、主体独一标志、扩展生成
    TBSCertificate(To Be Signed Certificate, 待签字证书)新闻;
  • 签发数字具名:使用 HASH 函数对 TBSCertificate 总计获得新闻摘要,用
    CA 的私钥对音讯摘要实行加密,获得签字;
  • 校验数字具名:使用同样的 HASH 函数对 TBSCertificate
    总计拿到消息摘要,与运用 CA 公钥解密签字获得内容绝相比;

选拔 SHA-1 做为 HASH 函数的表明被誉为 SHA-1 证书,由于近些日子一度找到
SHA-1 的撞击标准,将证书换到选用更安全的 SHA-2 做为 HASH 函数的 SHA-2
证书被提上日程。

实在,微软曾经宣示自 2017 年 1 月 1 日起,将健全甘休对 SHA-1
证书的支持。届时在风靡版本的 Windows 系统中,SHA-1 证书将不被信任。

而依据 Chrome
官方博客的文章,使用
SHA-1 证书且证书保藏期在 二零一六 年 1 月 1 号至 二〇一六 年 12 月 31
号之间的站点会被给予「安全的,但存在纰漏」的唤醒,约等于地址栏的小锁不再是棕色类的,并且会有叁个艳情小三角。而接纳SHA-1 证书且证书保质期超越 2017 年 1 月 1
号的站点会被授予「不安全」的浅深灰蓝警戒,小锁上直接突显贰个革命的叉。

然而,并不是享有的极端都接济 SHA-2
证书,服务端不协助幸亏办,浏览器只好正视于客商进级了。上边是大范围浏览器辅助SHA-2 证书的最低版本:

浏览器 支持 SHA-2 证书的最低版本
Chrome 26+
Firefox 1.5+
Internet Explorer 6+ (需要 XP SP3+)
Safari 3+ (需要 OS X 10.5+)
Android Webview 2.3+

能够看出,借使要照管未有打 XP SP3 补丁的 IE6 顾客,只好继续运用 SHA-1
证书。

在自己前面包车型客车文章中,还关系过 ECC
证书,这种新颖的证件帮忙度更差,这里略过不提,有意思味的校友能够点这里查看。

是不是足以本着差别浏览器启用不一致证书吗?理论上服务端能够依据顾客端
Client Hello 中的 Cipher Suites 特征以及是不是协助 SNI
的风味来分配区别证书,但是笔者从未实际验证过。

正文先写这么多,比很多国策都急需依附本身网址的顾客来调整,举例小编的博客基本未有IE8- 客户,道理当然是那样的能够禁止使用SSLv3。借使您的出品还只怕有许多应用老旧浏览器的客户,那就必需为这么些顾客做同盟方案了。一种方案是:只把主域安全等级配低,将
XP 上 IE 客户的 HTTPS 央求直接重定向到 HTTP
版本,那样任何域名能够利用高安全级其余计划,运营起来相比有利。

1 赞 1 收藏
评论

图片 1

注明选取

HTTPS 网址要求经过 CA
获得合法注明,证书通过数字签名技能保障第三方不能够伪造。证书的简易原理如下:

  • 趣事版本号、系列号、签名算法标记、发行者名称、保藏期、证书主体名、证书主体公钥消息、发行商独一标志、主体独一标志、扩充生成
    TBSCertificate( 待签名证书(To Be Signed Certificate))新闻;
  • 签发数字具名:使用 HASH 函数对 TBSCertificate 总括得到音信摘要,用
    CA 的私钥对新闻摘要举办加密,获得具名;
  • 校验数字具名:使用同一的 HASH 函数对 TBSCertificate
    总计得到消息摘要,与应用 CA 公钥解密签字获得内容绝相比较;

应用 SHA-1 做为 HASH 函数的证件被称为 SHA-1 证书,由于当下早就找到
SHA-1 的磕碰标准,将注脚换到选用更安全的 SHA-2 做为 HASH 函数的 SHA-2
证书被提���日程。

实则,微软一度宣示自 2017 年 1 月 1 日起,将完美结束对 SHA-1
证书的支撑。届时在新式版本的 Windows 系统中,SHA-1 证书将不被信任。

而有趣的事 Chrome
官方博客的文章,使用
SHA-1 证书且证书保藏期在 二零一四 年 1 月 1 号至 2015 年 12 月 31
号之间的站点会被予以「安全的,但存在漏洞」的晋升,也正是地址栏的小锁不再是肉桂色的,何况会有四个风骚小三角。而采取SHA-1 证书且证书保质期超越 2017 年 1 月 1
号的站点会被予以「不安全」的革命警戒,小锁上直接体现二个栗褐的叉。

不过,实际不是兼备的极限都协助 SHA-2
证书,服务端不援助幸亏办,浏览器只可以依据于顾客升高了。上边是相近浏览器支持SHA-2 证书的最低版本:

浏览器 支持 SHA-2 证书的最低版本
Chrome 26+
Firefox 1.5+
Internet Explorer 6+ (需要 XP SP3+)
Safari 3+ (需要 OS X 10.5+)
Android Webview 2.3+

能够观看,假若要照拂未有打 XP SP3 补丁的 IE6 客商,只可以继续应用 SHA-1
证书。

在本身事先的篇章中,还论及过 ECC
证书,这种新型的证件帮忙度更差,这里略过不提,有意思味的同窗能够点这里查看。

是或不是足以针对分裂浏览器启用差异证书吗?理论上服务端能够依靠客商端 Client Hello 中的
Cipher Suites 特征以及是不是帮助 SNI
的本性来分配不相同证书,可是本人从不实际验证过。

正文先写这么多,比较多计谋都急需依据本人网址的客商来决定,例如小编的博客基本没有IE8- 客户,理所必然能够禁用SSLv3。如若你的出品还会有比比较多行使老旧浏览器的客商,那就亟须为那个顾客做合作方案了。一种方案是:只把主域安全等第配低,将
XP 上 IE 客商的 HTTPS 乞求直接重定向到 HTTP
版本,那样任何域名能够利用高安全等级的布置,运营起来相比较便于。

本文永世更新链接地址:http://www.linuxidc.com/Linux/2016-01/127503.htm

图片 2

SSL 版本采用

TLS(传输层安全(Transport Layer Security))的前身是
SSL(避孕套接字层(Secure Sockets Layer)),它最早的多少个本子(SSL
1.0、SSL 2.0、SSL 3.0)由网景公司开垦,从 3.1 初阶被 IETF
标准化并更名,发展到现在已经有 TLS 1.0、TLS 1.1、TLS 1.2 多个本子。TLS 1.3
更改会相当的大,如今还在草案阶段。

SSL 1.0 从未公开过,而 SSL 2.0 和 SSL 3.0
都设有安全主题素材,不引进应用。Nginx 从 1.9.1 开端暗许只帮助 TLS
的多个版本,以下是 Nginx 官方文书档案中对 ssl_protocols 配置的认证:

Syntax: ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2];
Default: ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Context: http, server
Enables the specified protocols. The TLSv1.1 and TLSv1.2 parameters work only when the OpenSSL library of version 1.0.1 or higher is used.

但不幸的是,IE 6 只帮忙 SSLv2 和 SSLv3(来源),也等于说 HTTPS
网址要支持 IE 6,就不能不启用 SSLv3。仅这一项就能促成 SSL Labs
给出的评分降为 C。

 

反省浏览器是还是不是帮助 SNI

假若独有老旧浏览器(比如 IE8 on Windows
XP)提醒这么些错误,多半是因为您的服务器同偶尔间配备了选拔分歧证书的多少个 HTTPS
站点,那样,不补助 SNI(Server Name
Indication)的浏览器平时会博得错误的注脚,进而不可能访问。

要消除浏览器不援助 SNI 带来的题目,能够将选用分歧证书的 HTTPS
站点布局在分歧服务器上;仍是能够行使 SAN(Subject Alternative
Name)机制将多个域名放入同一张证书;当然你也足以间接无视那一个老旧浏览器。极度地,使用不扶助SNI 的浏览器访谈商业 HTTPS CDN,基本都会因为证书错误而高不可攀利用。

关于 SNI 的越来越多表达,请看「至于启用 HTTPS
的部分经历分享(二)」。

admin

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注