某天快要下班的时候，接到用户投诉说无法打开公司邮箱页面，最后发现是HTTPS的问题。本文完整记录了处理过程。解决投诉后，我也在思考问题的原因。.接到投诉后，我们的运维同事利用QQ远程连接用户桌面的功能（最有效、最快的排查方法）了解具体情况。初步情况如下：Chrome打开企业邮箱官网（https://mail.sina.net）没问题。登录webmail（https://webmail.sina.net）后，页面是空白的。运维同事使用Chrome开发者工具发现webmail页面（页面可以正常输出数据）引入的静态元素（js、css）无法加载，打开某个js文件（i0.sinaimg.js）。cn域名）单独在Chrome中，页面出现ERR_SSL_VERSION_OR_CIPHER_MISMATCH错误。有的同学可能会疑惑为什么js文件打不开会出现空白页？这和我们的前端开发架构有关。页面的渲染极其依赖js。如果js不能加载整个页面，就无法渲染。看到ERR_SSL_VERSION_OR_CIPHER_MISMATCH错误，我最好的反应是服务器https配置不兼容或者客户端（Chrome）https配置支持不够。考虑到只有个别用户投诉，而且我已经知道邮件https配置的兼容性很广（支持tls1.0，tls1.1，tls1.2），所以怀疑客户端https的问题。进一步排查发现用户的Chrome版本为36，潜意识认为用户的浏览器版本太低，做了两个检查：（1）检查Chrome版本发布时间。不太老。(2)查看本Chrome版本https支持的***版本。通过SSLLabsUserAgentCapabilities工具（https://www.ssllabs.com/ssltest/clients.html）测试结果如下：从上图可以看到版本***支持tls1.2，有https版本配置太低没问题。既然理论上已经排除了Chrome兼容性问题，我想通过Chrome开发者工具的【安全】菜单查看具体的https错误信息。遗憾的是，chrome36版本没有【安全】菜单。..***的故障排除工具不再可用。该版本的开发者工具如下图所示：这时，我蒙了，继续思考，两个新的现象进入了我的脑海：（1）webmail360浏览器可以正常访问，IE和Chrome不能被访问。事实上，这个消息非常令人不安，这让我怀疑这是一个客户端兼容性问题。由于我没有远程连接到用户桌面，所以当时没有查看（也没想到）360开发者工具的调试信息，很遗憾。（2）Chrome访问企业邮箱官网没有问题。这其实是一个非常重要的信息。如果是客户端（IE、Chrome）问题，为什么https访问官网没有问题？我打开开发者工具，看了下官网。导入的js元素域名为www.sinaimg.cn。问题渐渐明了。官网和webmail引入的js元素的域名是不一样的。我们公司所有的静态元素都部署在我们自己的CDN上（后来我们也引入了阿里云CDN）。这两个域名配置了吗？证书和HTTPS配置是否不同？虽然我已经知道公司证书是SAN泛域证书，所有域名和子域名都使用同一个证书，但是从严谨的角度来说，我还是使用SSLLabs的SSL服务器测试工具（https：//www.ssllabs.com/ssltest/analyze.html）来测试https配置。这个工具会扫描对应域名的所有IP，然后显示IP下的证书和HTTPS配置的详细信息。www.sinaimg.cn测试结果如下：从上图可以看出整个配置检测没有问题。然后测试i0.sinaimg.cn，结果如下：上图原因是CDN某点的https配置（443端口）获取不到，工具停止检测。这个时候，问题就逐渐明朗了。公司的静态池（staticelement）CDN部署了很多点。是不是某个点的https配置有问题？CDN由公司专门团队维护，第一时间反馈给他们，5分钟解决问题。我得到的反馈是静态池也用了阿里云的CDN（最近刚加的一个点，投诉的用户刚好访问了这个CDN点），但是这个CDN点没有配置支持https。..CDN同事在阿里云上开启443https服务后解决了问题（主要工作是上传i0.sinaimg.cn证书）。我们不禁要问为什么没有https部署这个点。他们的解释是，他们没有收到支持HTTPS要求的这一点。..为此，如果我还年少轻狂，我大概会喷他们（现在只能喷在心里）。静态池服务早就声明全站支持HTTPS。为什么还有这个问题？CDN的配置是开发者不能也不需要知道的（完全透明），既然整个站点都有HTTPS，是不是应该支持一个新的点？怎么能说没有收到需求呢？我的渣男作风还是一如既往。有同学不禁要问，这么大的故障，为什么其他产品没有受到影响呢？原因是i0.sinaimg.cn域名下的服务用户可能很少，下一阶段我们会尽快将静态元素迁移到www.sinaimg.cn域名下。解决完这个问题，我静下心来想，为什么浏览器没有问题360？同一台机器的DNS解析不是一样的吗？360连接的443服务器和Chrome连接的443服务器不一致？如果不一致，那么360浏览器正常显示无可厚非，但是如果一致就很难解释了。由于当时没有看到360浏览器访问的具体情况，所以做了一个测试：（1）登录阿里云CDN控制台，默认443端口是关闭的，也就是说当出现故障时出现这种情况，443肯定是打不开的。（2）由于我没有阿里云CDN服务，所以我做了一个模拟，用自己的服务器测试https://www.simplehttps.com（80开，443关），看看360browserworks最后我用浏览器360访问了网址，但是无法成功打开，所以这就成了一个悬案。通过这件事，我得到了一些体会和想法：排查问题需要经验，而经验是建立在技巧的掌握、头脑冷静、工具使用熟练的基础上的。很多问题看似复杂，但最终的原因却如此无厘头，可见整个技术体系是混乱的、支离破碎的。实际排错的顺序并不像本文描述的那样，走了很多弯路。这样安排是为了让读者更好地理解排查问题的思路。SSLLabs的SSLServerTest工具非常好。它如何检测一个域名对应的所有IP？如果有现成的解决方案，我打算基于此写一个简单的小工具来快速诊断https配置（比较轻量级的工具）。
