0%

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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Client                                               Server

ClientHello:HandShake -------->
ServerHello:Handshake
Certificate*:Handshake
ServerKeyExchange*:Handshake
CertificateRequest*:Handshake
<-------- ServerHelloDone:Handshake
Certificate*:Handshake
ClientKeyExchange:Handshake
CertificateVerify*:Handshake
[ChangeCipherSpec]
Finished:Handshake -------->
[ChangeCipherSpec]
<-------- Finished:Handshake
Application Data <-------> Application Data