关于全站HTTPS，你必须知道的一些事儿

通过对数百个应用，百万级页面的深度改造，阿里巴巴目前已成为全球唯一大规模启用电商平台全站HTTPS的公司。

证书、私钥和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看看是否在我们未授权的情况下颁发了我们的域名证书。

保障君注：本文原标题为《CA和证书那些事》