背景
晚上9点整，突然接到微信大群里的报障信息：
Caused by: javax.net.ssl.SSLException: Certificate for <pass.cctalk.com> doesn't match any of the subject alternative names: [bdydns.com, www.bdydns.com, *.cdn.bcebos.com, download.meizu.com, firmware.meizu.com]
提到：
cdn https证书导致我们调 <某某域名> 都失败了，请紧急处理一下
看到很明确的说CDN出问题了，而且又是产线大佬发的，哪敢怠慢，立即回复1，同时准备把这个域名切到备线（看到SSL错误，又看到多域名证书，不禁联想到SNI，但还不太肯定），后来发现切到备线也不顶用（这个时候心里已经比较有底了，可以确定是SNI的问题了），只好切回源，切完生效恢复正常（源站网关是一个SSL证书对应一个公网IP地址，不存在SNI的问题，所以绑定源站是没问题的）。
但这时候，其他产线大佬开始担心切回源，没了CDN这层，可能会影响到用户访问质量（跨运营商跨国访问没有CDN必然会出问题），开始问我们相应对策了。
说来也巧，这个时候正好领导电话我了，和刚才投诉的大佬沟通过了，确定了这个问题一直存在，且有服务降级，不用太过理会。听到这，才敢放心的切回CDN，也省的瞎折腾了，松了口气。
问题
这个SNI的问题已经不是第一次出现了，印象中至少有过4~5个开发来问过我都是由于SNI导致的证书错误问题，这边引用阿里的技术文档：SNI 兼容性导致 HTTPS 访问异常（服务器证书不可信），我们再来复习一遍：
SNI（Server Name Indication）是为了解决一个服务器使用多个域名和证书的 SSL/TLS 扩展。它的工作原理是：在连接到服务器建立 SSL 连接之前，先发送要访问站点的域名（Hostname），这样服务器会根据这个域名返回一个合适的证书。
没错，一个是由于IPv4地址段稀缺，另一个是因为CDN供应商为节省服务器成本，所以使用了SNI的方式，这种做法无可厚非；即便是CDN提供独享的SSL服务，我们也不可能去用它，因为成本实在太高。
关于SNI相关内容点，有兴趣的同学还可深挖下，这边不再累述了：
- 维基百科 - 服务器名称指示/ Server Name Indication
- rfc6066 - Transport Layer Security (TLS) Extensions: Extension Definitions
家里正好还有台古董机，装的XP系统，打开IE浏览器试了下，果然真能重现：
缓解
要想解决这个问题，阿里的技术文档中也给到答案，简单说来就是：升级版本。
后记
SNI的问题，也不能完全责怪开发同学，毕竟人家只管写代码，具体涉及到服务器部署、证书部署之类的问题，都是运维的活，难怪只能找我们。 另外服务端通信必须走内网，走公网绕了一大圈不说，HTTPS协议还增加各代理节点响应损耗，这个我觉得应该属于常识范畴。
彩蛋
9点处理这个问题的时候正好从2号线世纪大道下车，立马就找了个角落打开电脑，先连大号（移动），连是连上了，但拨了VPN死活连不上，尝试了1分钟未果，立即拿出小号（电信）开启热点，成功连上，开切！
切完后猜想备线路是不是能扛下来，收拾收拾东西准备回家了，走到4号线站台准备上车时发现微信又炸了，切了备线还是不顶用，立马又找了个角落打开电脑，继续切！
前后加起来差不多半个多小时，附近没有板凳，只能坐在角落里，晚高峰，感觉旁边好多人上车下车走过，但没空看别人，就想早点搞定可以回家。
电脑、手机、双肩包、眼镜、T恤、七分牛仔裤、角落里盘腿坐墙边，标准张江IT民工配备……
题外话
本来这篇差不多凌晨1点就能写完了，不料线上出故障了，还正好赶上了重要事件，愣是熬到了现在4点多。熬夜也就算了，关键是问题还没搞定！力不从心，外加运气点背，哎…
但话说回来，发现到问题也是为了能够更好的解决问题，本来一切事物都是一个发展、优化、改善的过程，知道问题所在，更应该努力吸取教训，积累宝贵经验，不断完善、进步，否则失败就真的是失败了。
