文/震羽
证书、私钥和CA
现在我们所说的证书一般是指服务器证书，也就是公钥加上域名、公司信息、序列号、签名信息等组成；
私钥和公钥相对应，私钥加密的东西只能公钥解密，公钥加密的东西只能私钥解密，并且不能由公钥推断出私钥，但是可以由私钥算出公钥来。所以这里有一件非常有意思的事情，你可以在公私钥不变的情况下换一张证书，因为证书其实包括其他信息，所以你换的是别的信息，这些信息的变化会导致证书签名也会变化，所以就变成了一张新的证书，但是公钥私钥是没有变化的。
CA也由证书和私钥组成，它的证书和普通的证书长得差不多，只是其中的Basic Constraint字段里面的CA值为True而已，普通的服务器证书这一块为False，但是因为有了这个True，所以CA可以签发别的证书。
服务器证书的分类
可以从两个维度去看证书的分类，一种是商业角度，为了区分不同的用户级别，服务端证书可以分成DV、OV和EV证书。
- DV（Domain Validation）证书只进行域名的验证，一般验证方式是提交申请之后CA会往你在whois信息里面注册的邮箱发送邮件，只需要按照邮件里面的内容进行验证即可。
- OV（Organization Validation）证书在DV证书验证的基础上还需要进行公司的验证，一般他们会通过购买邓白氏等这类信息库来查询域名所属的公司以及这个公司的电话信息，通过拨打这个公司的电话来确认公司是否授权申请OV证书。
- EV证书一般是在OV的基础上还需要公司的金融机构的开户许可证，不过不同CA的做法不一定一样，例如申请人是地方政府机构的时候是没有金融机构的开户证明的，这时候就会需要通过别的方式去鉴别申请人的实体信息。
从业务角度来看证书还可以分成单域名证书、多域名证书、泛域名证书和多泛域名证书，具体可以参考表格里面的例子。
因为DV证书认证级别比较低，所以你查看DV证书的时候只能查看到域名信息，无法查看组织、公司信息，而OV和EV证书是可以的，特别是EV证书在地址栏上会展现成绿色的长条并且显示公司信息，给人的感觉比较专业和安全。
DV证书因为主要面向个人用户，安全体系会相对比较弱，所以只支持单域名和多域名证书，价格非常便宜，甚至现在有CA提供免费的DV证书（例如国内的wosign和国外即将上线的Let's Encrypt）。
OV和EV证书比较贵，除了需要人工验证之外，还在于他们有比较高的保险费用，如果CA的私钥出问题了，那么这些OV、EV证书都将得到巨额的赔偿，一般一张证书的赔偿金额都在100万美元以上。
这里最有特色的就是多泛域名证书，到现在为止也还没有正式的名字，我一般叫做Wildcard SAN certificate，简称WSAN，现在在CA的申请网页里面一般也很难看到有这样一个单独的申请选项，不过主流的CA现在都已经支持这种证书了，我所知道的Digicert和GlobalSign都可以申请，你如果有需要可以找他们的客服问问。
如何生成和查看CA/服务器证书
这是我觉得非常好的介绍如何创建Root、签发CA以及服务器证书的文章，大家有兴趣可以参考：https://jamielinux.com/docs/openssl-certificate-authority/
这里简单说一下为什么现在都是二层的CA架构？首先这二层CA我们一般叫做RootCA和IssuingCA，RootCA是自签名的，IssuingCA是由RootCA签发的。其实很早以前CA会直接使用他们的RootCA签发证书，但是因为RootCA的证书非常干净，上面没有任何的限制，容易出问题，所以现在都会签发一个pathlen=0的IssuingCA，再由这个CA去签发证书，表示这个CA只能签发普通证书，是无法在签发新的CA的。
CA的历史和事故
Verisign是第一家CA厂商，创办于1995年，当时得到了RSA算法的使用授权，是全世界最大的CA厂商，在2010年以12.8亿美元卖给了赛门铁克。当前TOP5的CA厂商分别是Symantec、Comodo、Godaddy、GlobalSign和Digicert，占据了90%以上的市场份额。
CA的历史上也出过几次严重的问题：
-
- 2002年Verisign在未经微软授权的情况下签发了一张微软的证书，攻击者通过使用伪造的身份来通过Verisign的验证，最终的后果就是微软为此发布了一个紧急的更新补丁。
- 2008年在实验室里通过MD5的碰撞获取了一个“真”的CA，用它签发出来的证书会被认为是浏览器里面已经受信的某个CA签发出来的。
- 2011年连续出现了几次攻击，最严重的就是DigiNotar被伊朗的黑客入侵，签发了500多张未授权证书，所以他的Root全部被浏览器和操作系统吊销，整个公司也最终破产，可以说这是有史以来最严重的CA事故。
之后Google利用HPKP还发现了很多MITM（Man in the Middle）攻击，例如TURKTRUST和ANSSI，有兴趣的可以去搜索了解一下。
PKI体系介绍、漏洞和方案
PKI体系的原理就是浏览器内置可信赖的RootCA的证书，所有由这些RootCA签发出来的证书都信任。所以今天虽然很多网站已经上了HTTPS，但是如果另外一家CA他偷偷签发了同样域名的证书然后进行流量劫持或者篡改，我们也是无法知道的。
所以为了应对这种问题，现在比较主流的两种方案是HPKP和Certificate Transparency：
HPKP的基本原理就是用户在第一次访问的时候在Response Header里面发送给用户正确的域名证书的签名信息，之后用户在访问我们网站如果遇到了别的证书发现签名信息不匹配就上报甚至拒绝访问。
-
- 当然这种方案缺点也很明显，它采用类似HSTS的所谓的**首次信任**原则，也就是认为用户第一次的请求是可信没有被篡改的，而实际上这个无法百分百保证。
- 第二个问题是我们的证书太多，这样我们的配置发布系统就需要在证书更新之后发布新的签名信息给用户，而且还需要根据证书的有效期去设定返回头的有效期时间，如果再次遇到HeartBleed之类的攻击导致我们短期内大批量的吊销证书就蛋疼了。
- 另外当前只有Chrome 38 和 Firefox 36以上的版本支持，不过用这个功能来进行汇报还是不错的选择，具体如何配置可以Google一下。
第二种方式是让CA支持的透明证书功能，也就是要求所有的CA将他们颁发的证书日志全部都公开出来，这样我们就可以检索所有CA看看是否在我们未授权的情况下颁发了我们的域名证书。
多证书问题
SHA1证书安全问题，理论上从2016年1月1日开始CA是不能在颁发SHA1的证书给用户了，从2017年开始，所有的浏览器和操作系统都不应该支持SHA1的证书，对于最新的Chrome用户如果你的证书过期时间超过2016年1月1日，那么就会出现左边提醒，地址栏上也会显示成黄色三角。但是如果直接升级到SHA256就会导致老的XP SP2的用户不能访问你的网站，所以对于这个问题，我们的建议是：
1. 如果一定要使用SHA1证书，过期时间不超过2015年年底
2. 提供多证书支持，对于新的浏览器提供SHA256的证书，对于那些老的XP用户提供SHA1证书，还有一个注意点是中间证书也需要是SHA256的。
SNI（Server Name Indication）问题和WSAN证书
大家都知道我们可以在一个IP:PORT上部署多个虚拟主机，它的原理就是在HTTP请求头里面的Host字段带上了域名信息，例如Host: www.a.com，nginx在收到这个请求的时候就会通过匹配这个Host，然后把请求对应到具体的servername的配置。
但是SSL/TLS的握手过程是在HTTP传输之前，所以我们是无法使用HTTP的Host字段进行区分的。如果有多个域名指向到同一个VIP并且端口相同，例如a.com、b.com都指向到192.168.1.1，那么在SSL/TLS握手的过程中，我们是该返回a.com域名的证书还是b.com域名的证书呢？
解决方案很简单，可以使用前面提到的WSAN来解决这个问题，因为你可以把所有的域名合并在一张证书里面，而且WSAN证书还可以让你在多个域名之间保持连接复用，也就是说如果你之前访问了www.a.com，然后跳转到www.b.com，这个证书可以让你跳过**TCP**和**TLS**的握手，直接发送数据，当然，这是有前提的，你需要满足这些域名指定到同样的IP、使用SPDY3.1或者HTTP2，而且只有Chrome支持这个功能。
WSAN证书（WildCard SubjectAlternativeName Certificate）
这种证书想必大家已经很熟悉了，下一步具体介绍一下WSAN还有什么其他好处：
统一的过期时间：
如果你管理过证书你就知道当有几百张证书的时候，每张证书的过期时间都不一样，时不时的需要重新renew，非常的痛苦；而使用WSAN之后，每次新增域名直接加到证书里面，这样大家的过期时间都一样，进行renew的时候只需要renew一张就所有的都renew了，每年统一干一次就好了
证书使用范围控制：
因为WSAN证书里面域名非常多，安全级别要求也非常高，所以需要妥善保管私钥。
当然WSAN也有不好的地方，就是每次需要新增域名的话都需要进行证书的更新（私钥可以不更新），所以可以限制WSAN证书的更新频率，例如每两个月固定新增一批新的域名。
总体来看WSAN让运维效率可以大幅提升，同时通过限制使用范围，使用自动化的方式更新WSAN证书。
扫码关注阿里技术保障公众号，有更多技术干货分享。
