嗨伙计们，
如果网站使用的是SSL，您如何测试配置是否已准备好用于生产？
我仍然收到来自客户的投诉，他们由于一些认证问题而无法登录我的网站。
最后一个来自Windows 7，是最新的Chrome，错误消息为：ERR_CERT_AUTHORITY_INVALID
在投入生产之前，我已经尽可能地通过不同的操作系统/浏览器进行了测试，但似乎有一些情况下留下了非常具体的配置。
列出我的问题：
我们是否还有LetsEncrypt的测试版程序来包含为我的域颁发的证书的信息，我应该在那里申请吗？
我正在使用最新的LetsEncrypt X3(v0.5)为我的网站颁发证书。
我使用的是订书机，下面是我的产品Nginx的配置：
Ssl_证书/etc/letsencrypt/live/luckstock.com/fullchain.pem；
Ssl_证书_密钥/etc/letsencrypt/live/luckstock.com/privkey.pem；
SSL_协议TLSv1 TLSv1.1 TLSv1.2；
Ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES：！MD5；
启用SSL_PERFER_SERVER_CIPHERS；
共享的SSLSESSION_CACHE：SSL50M；
SSLSession_TIMEOUT 180M；
Ssl_dhparam/etc/nginx/cert/dhparam.pem；
启用了SSL_STAPPING；
SSL_STAPPING_VERIFY ON；
Ssl_Trusted_证书/etc/letsencrypt/live/luckstock.com/chain.pem；
解析器8.8.8.8 8.8.4.4有效=86400秒；
解析器_超时5s；
添加报头严格-传输-安全最大值=15768000；
您能检查一下我的配置/证书是否足够可靠，可以在生产中运行吗？
据我所知，目前还没有任何用户在Windows7上存在信任问题的报告。Windows7附带的DST根CA。我见过过时或有漏洞的杀毒软件导致的问题，就像你过去看到的那样(它们有时包括使用本地MITM代理扫描HTTPS流量的组件，而该…往往会出错)，但这只是一种猜测。
我注意到的另一件事是，Luckstock.com使用的是We‘s Encrypt证书，但www.Luckstock.com似乎托管在CloudFlare上，并且使用的是CloudFlare证书。我想不出为什么这会导致你的问题，但我觉得这很奇怪，所以我提到了这一点。从概念上讲，游戏的一部分是客户端。您的服务器端只占方程式的50%左右。
要测试所有可能的场景(如所有版本的浏览器、操作系统等)，您需要设置…每个场景。当然，这是不可行的。
曾经有一段时间，在您的站点上引入动态内容会给用户的访问可能性带来同样的不确定性。
我想，对于一个商业网站来说，从http到HTTPS版本的硬重定向可能是一个极端的步骤，尽管这可能是从提供HTTPS服务中获益最大的类型的网站。
如果你担心你的客户无法访问你的网站，主要(但不完全)是因为他们拥有访问你网站的过时的软件，那么你可以考虑使用一个http备份版本，可能功能较少和/或向用户提供一些简单的解释。
然后，我会做的是记录对http简化版本的访问，以跟踪谁未能使用完整的HTTPS版本，并尝试在个案的基础上解决这个问题。
这当然是漫长而昂贵的，但如果我们仍然需要处理一些鲜为人知的早期版本的Netscape Navigator和Windows 95下的Internet Explorer的第一个版本的访问，那么我们就处于不兼容的竞赛中。这一点都不好玩。
仍然有大量的Windows XP系统在运行，尽管它们被原始软件提供商排除在太空之外，已经过测试(在硬重定向到HTTPS之前)，并看到了良好的结果：
你认为有什么问题吗？同意，我认为这里的问题是客户端计算机上损坏的DST根CA。
我已经在CNAME记录(www.Luckstock.com)上删除了一个CloudFlare加速。不过，我不认为这可能是一个原因。我建议你看看密码诉讼顺序。目前，您更喜欢在CBC模式下使用AES128位，而非前向保密适用于AES128位高于AES256位。
关于256位的AESGCM是否比128位的CBC更好，还存在争议。各方意见不一。我总是避开CBC(即：较低的偏好)，因为它在过去也有过麻烦和功绩。在任何情况下，你都应该，IMHO，出于明显的原因，总是更喜欢向前保密套装而不是非FS套装。
我想，对于一个商业网站来说，从http到HTTPS版本的硬重定向可能是一个极端的步骤，尽管这可能是从提供HTTPS服务中获益最大的类型的网站。
因此，您认为我应该从配置中删除以下行：
添加报头严格-传输-安全最大值=15768000；
摩托车手：
然后，我会做的是记录对http简化版本的访问，以跟踪谁未能使用完整的HTTPS版本，并尝试在个案的基础上解决这个问题。
有没有办法在现实生活中实现这一点？
目前，该网站在大多数装有FF或Chrome的WinXP系统上都能很好地打开。
我担心的是客户因为一些证书无效问题而无法登陆Https站点的罕见情况。我在密码套装方面经验不足，所以我去了CloudFlare推荐的密码：
Github.com
CloudFlare/sslconfig/BLOB/master/conf
SSL_协议TLSv1 TLSv1.1 TLSv1.2 TLSv1.3；
Ssl_ecdh_curve X25519：P-256：P-384：P-224：P-521；
Ssl_ciphers‘[ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-ECDSA-CHACHA20-POLY1305|ECDHE-RSA-AES128-GCM-SHA256|ECDHE-RSA-CHACHA20-POLY1305]：ECDHE+AES128:RSA+AES128:ECDHE+AES256:RSA+AES256:ECDHE+3DES:RSA+3DES’；
启用SSL_PERFER_SERVER_CIPHERS；
我打赌他们比我更了解这一点。
关于生产环境中的密码串，你有什么建议？请看这个帖子，更准确地说，第一条评论：
Githeb.com/CloudFlare/sslconfig
问题：Mozilla推荐的密码
按节点套接字打开
2015/09/21
按节点套接字关闭
2015/09/21
Mozilla推荐配置生成器：
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA：！aNULL：！eNULL：！EXPORT：！DES：！RC4：！MD5：！PSK：！aECDH：！EDH-DSS-DES-CBC3-SHA：！EDH-RSA-DES-CBC3-SHA：！KRB5-DES-CBC3-SHA
但你还是建议：
EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES：！MD5
应该使用哪一种？
如果你把非FS套件放在256位的…套件之前或之后，这可能并不重要，因为我认为每个客户端都支持128位的FS套件
但总结云闪耀会更好地了解它，嗯，我不知道…也许Mozilla推荐的密码套件会是更好的选择，因为这些建议并不是针对CloudFlare的。
