@ryd994 我们学校 DIS 实验室里一大堆 XP 还没到报废年限，不过也快了

@ryd994
@moyaka
以目前算力实际上破不了，但是我也理解什么意思了……安全性的确有问题

@moyaka 3DES 是 WinXP 平台上唯一可用的最安全 TLS 算法

nginx mode 是怎样一个原理啊？

@ivmm 不过有 ghost.io

@Tony2ee 人家和谋智类似，是一家基金会公司一家商业公司的模式，商业公司得挣钱的😂

@skylancer 你说的是 DigiNotar 吧，这事情很严重……
不用 CNNIC 的理由是劣迹及没有优势，但是在技术上来说，暂时可以视作可信赖的。

@402645707 国产的用 USTC 或者 HUST 带宽更大，我想不出用 CNNIC 的理由来。

@quericy
这个剧集本来就就仅限大陆的说，目测是因为版权原因禁止缓存

根据 RFC 6797 章节 8.5 ，无解。

几个月了，你可能比较火星。
不过点击问题页面时有一定几率出现旧页面，首页的 UI 也没太大变化。。

@fourstring 证书已经同一，那么 sct 必然是同一组啊。

@fourstring 你是否知道,每签发一次证书,必须重新获取一次 SCT?

@fourstring 我可能表达不清楚，就是分别签发 ECDSA 和 RSA 这两张证书，这两张证书要把四个域名都填上。就是备用名称。

@fourstring 我目前部署下来只发现两个解决方案：
1.放弃给每个站点单独设双证书
2.统一使用 SAN 来部署双证书

@fourstring 按照我的个人理解，这个问题还是在于 Nginx 在实现的时候把所有的 ECDSA 证书全返回去了。
我的 SAN 证书的 CSR 就是按照 @qgy18 的方式生成的

@fourstring 这是双证书本身的缺点。
你的 cipher 是这样的：
EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+ECDSA+AES128:EECDH+aRSA+AES128:RSA+AES128:EECDH+ECDSA+AES256:EECDH+aRSA+AES256:RSA+AES256:EECDH+ECDSA+3DES:EECDH+aRSA+3DES:RSA+3DES:!MD5
或者是 ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
这都是强行把 ECDHE-ECDSA 这种套件提前的设置方式（ EECDH 在我看来基本等价于 ECDHE ）。
所以，在大部分浏览器的套件选择默认以 ECDSA 为先的情况下，你又开了 ssl_prefer_server_ciphers on ，那无疑在取交集时，会优先选择 EECDH+ECDSA+CHACHA20 或 EECDH+ECDSA+AES128 ；因而这是必然：返回证书前两个一定都会是 ECDSA 证书了。
解决方案其实只能是保守的：使用 SAN 证书。在这种双证书的特殊情况下， SNI 扩展不是主要矛盾，套件和证书才是。