Subject Alternative Name是什么鬼
原先一直是用的let’sEncrypt的ssl证书。现在由于换到cloudflare了，按正常逻辑就得上传ssl证书才能整个CDN都用上https。但是现在也都不需要了。这个到底是怎么实现的呢？它背后的校验原理是怎么样的？
当我们访问https://mirages.tech 的时候证书是什么，看到这个证书是颁发给 sni.cloudflaressl.com 的，跟我域名完全没关系啊。
那就拿ssl工具先看下吧，正常情况下，浏览器肯定会报错的。
这里出现了
1 | Alternative Name: *.mirages.tech sni.cloudflaressl.com mirages.tech |
而且看了下这个证书digicert颁发的，那就有线索了。
https://www.digicert.com/subject-alternative-name.htm
这里有说这个是X.509的协议部分在1999年的时候通过的。具体参考rfc https://tools.ietf.org/html/rfc5280#section-4.2.1.6 现在已经是v3的版本了。
但是一直到2006年才开始使用。我去，我怎么记得当年我们连sni都没开始用呢，当年还是xp的天下呢，一个IP只能有一个https证书，就因为这个，当年蓝汛还没少收我们钱。
https://www.digicert.com/multi-domain-add-subject-alternative-names.htm
根据这个我们知道整个流程跟新申请证书是差不多的，都是要新产生csr。github, cloudflare这套流程是相当的快啊，从产生csr，到颁发证书。
具体配置可以参考openssl官网
https://www.openssl.org/docs/manmaster/man5/x509v3_config.html#Subject-Alternative-Name
不过这个既然是rfc里都包含的，那也不是什么黑科技了，原先怎么校验的，现在还是怎么校验。这种证书就叫multi-domain证书。
ClientHello的时候会提交对应的域名，Server返回的时候会带上对应的附加域名。
类似于google这样丧心病狂的把自己所有域名都加上。只要支持SNI的浏览器都支持了，现代应该除了xp以前的系统都支持了吧。
整个流程下面这篇写的还是很完整的：
https://www.jianshu.com/p/a3a25c6627ee
1 | Client Server |