密码讲堂 | 第13讲 SSL证书及相关国际标准
2022年6月25日

点击 这里 阅读PDF版本(有全球信任和全球法律效力的数字签名和时间戳,版权所有,抄袭违法必究!转载请注明:转载自零信CEO博客)

本计划在第13讲开始讲加密DNS,但是笔者最近看到一个非常重要的单位的内网部署使用的SSL证书有非常多的安全问题,零信浏览器无法正常访问这个内网系统,这个用户就说是零信浏览器的问题,因为某个浏览器可以正常访问。笔者发现这不是个个案,因为这个内网是一个覆盖全国的系统,所以笔者决定再多讲几讲SSL证书,可以理解为SSL证书进阶知识,供有兴趣进阶了解SSL证书的读者学习。本讲先讲一讲SSL证书相关的国际标准。

还是先让大家了解一下这个有N个安全问题的SSL证书有哪些问题,以便同时对比了解国际标准是怎么要求的:

  • 这张SSL证书的公钥为RSA算法1024位,非常不安全!
    国际标准要求2010年12月31日停止签发1024位证书,并于2013年12月31日禁用1024位证书,国家密码管理部门也已发类似通知要求,但是居然这么重要的内网系统在国际标准要求禁用1024位证书的十年后的今天还在使用1024位RSA算法SSL证书!
  • 这张SSL证书的签名算法为SHA1,非常不安全!
    国际标准要求在2015年12月31日停止签发SHA1证书,从2017年1月1日起Windows停止支持SHA1证书,但是7年后的今天这个重要的系统还在使用RSA算法SHA1证书!
  • 这张SSL证书没有使用者可选名称(SAN)字段!
    只有CN字段=10.xx.xx.xx的IP地址,这是一个大问题,因为浏览器验证SSL证书绑定的域名或IP地址是只读取SAN字段信息的,没有这个字段就无法判断证书绑定的IP地址是否同用户正在访问的网站IP地址一致,当然会有“不安全”警告。
  • 这张SSL证书没有“服务器身份验证和客户端身份验证”的增强密钥用法(EKU)!
    没有增强密钥用法等于就是没有定义这种证书是SSL证书,当然也就无法实现双向认证。
  • 这张SSL证书没有必须有的(Critical)“密钥用法”!
    没有密钥用法,就甚至不能称之为证书,这是一个非常严重的问题。
  • 这张SSL证书没有可访问的吊销列表和授权信息访问(AIA)网址,反正是内网无法访问外网,这还可以接受。但不了解服务器部署SSL证书是否同时部署了中级根证书,如果没有,则无法验证证书。
  • 这张SSL证书没有证书策略字段,更没有证书透明SCT列表。
  • 这张SSL证书在内网使用,绑定的是内网IP地址10.xx.xx.xx,这个不是大问题,但是这张SSL证书都已经过期一年多了还在使用,这是个大问题。

相信大家已经从上面的各种问题能看出这张SSL证书依据国际标准是根本不允许使用的,正常功能的浏览器也是无法正常同服务器握手成功的。据了解,这张SSL证书居然是某个国内知名的“技术领先”的厂商的CA系统签发的,一个CA系统厂商是生产签发SSL证书的系统的,不懂SSL证书的话如何能生产出合格的CA系统?这更加让笔者深感普及SSL证书知识的重要性。其实,大家如果有心的话,随便打开一个正常网站,查看一下SSL证书的参数就能知道正常的SSL证书应该有哪些字段,本文就以零信官网部署的国际SSL证书为例,重点讲一讲几个重要的字段。

1. 使用者(Common Name, CN) 和 使用者可选名称(Subject Alternative Name, SAN)

“使用者”是Windows证书查看器新启用的名称,原先名称是“通用名称”,就是Common Name的直译,只能包含一个域名,一个单域或一个通配域名,这个字段是X.509证书标准中标准字段,在Netscape发明SSL证书时被用于绑定网站的域名,在邮件证书中用于绑定电子邮件地址,在客户端身份证书中用于绑定个人姓名或单位名称,在代码签名证书和文档签名证书中用于绑定单位名称。

但是,随着SSL证书的普及应用,一张证书绑定一个域名无法满足用户的应用需求,所以X.509规范就增加了一个扩展项:Subject Alternative Name(SAN),主题备用名称 或 使用者可选名称,这个扩展字段可以是域名、电子邮件地址、IP地址、网址等信息,允许写入多条数据,这就有了多域证书。2000 年 5 月发布的国际标准RFC 2818指定主题备用名称作为将域名添加到SSL证书的首选方法,弃用以前将域名添加到通用名称字段的方法。

CA/浏览器论坛制定的基线标准要求 SAN 中必须包含通用名称中的域名或IP地址,从而有效地使 SAN 成为与网站域名相匹配的唯一必需验证依据,通用名称字段已经被弃用,但允许CA签发含有通用名称的SSL证书,仅作为过去的技术遗产而存在。谷歌浏览器从58版本(2017年3月)开始就根本不再检查通用名称字段的信息,只查看和验证SAN字段,这实际上是加快了浏览器验证SSL证书时间,提升了用户体验。

也就是说:SSL证书标准要求必须有SAN字段,必须把网站域名写入到这个字段,这个字段可以写入多个域名和IP地址,但一般不会超过100个,绑定太多的域名也不是很好的选择,因为太多域名会导致SSL证书文件变大,这就会增加浏览器同服务器握手时的流量,不仅浪费了流量,而且影响浏览器的SSL证书验证效率,降低了用户体验。

SSL证书 SSL证书

2. 授权信息访问(Authority Info Access, AIA) 和 证书策略(Certificate Policy, CP)

授权信息访问(Authority Info Access),简称为AIA,意思是证书签发者信息访问网址,用于告诉浏览器这张证书是哪个签发CA签发的,去哪里可以下载签发者证书用于验证用户证书是否真的是这个签发CA签发的,这个信息必须包含在用户证书中,以便浏览器能获得证书签发者的证书来验证用户证书。

零信浏览器在处理各家CA机构的可信根认证申请时发现有多家CA签发的用户证书和签发CA都没有AIA信息,这样即使预置信任了根证书也由于无法往上验证而使得浏览器无法显示为可信证书。有些用户证书中有AIA信息,但是无法访问,这就等于没有,所以这个字段必须有,并且一定要确保AIA网址可访问,而且必须是正确的签发CA证书。

也就是说,这个字段影响了浏览器是否可以正常识别和验证网站部署的SSL证书,当然非常重要。这个字段中还有一个联机证书状态协议信息,这个留到下面同CRL字段一起讲。

SSL证书 SSL证书

证书策略(Certificate Policy)这也是必须有的字段,明确用户这张证书的签发依据的CPS(认证业务声明)的访问网址,用户可以直接点击证书常规中显示的“颁发者说明”直接访问这个网址。同时还会显示Policy Identifier(OID),一般至少有两个OID,一个是定义此证书类型的CA自用OID,另一个是此证书遵循的国际标准证书类型的OID,如上右图中的2.23.140.12.1就是CA/浏览器论坛定义的DV SSL证书OID。

可以毫不夸张地讲,没有证书策略这个字段就是不可信的证书,因为签发者没有公开告知用户是依据什么标准来签发这张证书的、是如何验证用户身份的等等。这是一个必须有的字段。

3. 证书吊销列表(Certificate Revocation List, CRL) 和 联机证书状态协议(Online Certificate Status Protocol, OCSP)

如果CA机构错误签发了证书,则必须马上吊销这张证书,或者用户怀疑网站部署的SSL证书私钥泄露,则用户也应该马上通知CA机构吊销这张证书。而证书吊销后如何告知浏览器此证书已经吊销,这就是证书吊销列表(CRL),证书中的“CRL分发点”字段就是告诉浏览器和其他方这张证书的吊销列表访问网址,浏览器可以下载吊销列表文件(.crl)来验证此证书是否在吊销列表中。请注意:如果这个签发根有很多张证书被吊销的话,这个吊销列表文件会很大,一个有324条吊销记录的文件大小为12K,所以,目前谷歌的CRL的发布方式是每7天启用一个新的吊销列表文件,零信CA系统是每年启用一个新的吊销列表文件,而不是传统的使用一个一直不变的吊销列表文件。

大家应该可以看出:使用吊销列表文件的不好之处就是可能文件会很大,这样浏览器下载这个吊销文件并验证用户证书的时间会变长,这会影响用户体验。当然,吊销列表文件是定期发布的,国际标准要求至少每7天必须发布一次,有效期最多不能超过10天,也就是说在吊销列表文件未到期之前是不用重复下载的。而为了能及时发布已吊销的证书,国际标准要求SSL证书被吊销后必须在24小时内发布包含了此吊销证书序列号的新的吊销列表。

SSL证书 SSL证书

联机证书状态协议(OCSP)是一个能实时查询证书是否被吊销的计划替代CRL的协议,意在解决CRL文件可能很大(必须下载整个CRL文件才能查询到某种证书是否被吊销),以及吊销列表发布不及时等问题,其优点是无需下载整个CRL文件,只需把要查询的证书的序列号给OCSP查询是否已吊销而返回一个“是”或“否”即可,这的确是一个高效率的解决方案。

但是,现在国际标准又计划废弃OCSP,原因是随着所有常用网站都已经实现了https加密,用户浏览器不断地访问地OCSP系统泄露了用户的访问轨迹,这不利于保护用户隐私。所以,CA/浏览器论坛计划修改标准把目前的“OCSP必须和CRL可选”改为“CRL必须OCSP可选”,并有专家提议把在证书透明机制中增加证书吊销查询功能。无论怎么变,证书吊销查询服务是CA机构必须提供的,可以只有CRL或者只有OCSP,必须有一个或者两个全有,这样浏览器就可以验证这张证书是否被吊销,从而能及时停止使用已吊销的证书。

4. 密钥用法(Key Usage, KU) 和 增强密钥用法(Extended Key Usage, EKU)

密钥用法是SSL证书必须有的关键字段,顾名思义这个字段用于说明这张证书是干什么用的。RSA算法SSL证书应该是“Digital Signature, Key Encipherment (数字签名,加密)”,而ECC算法SSL证书则是“Digital Signature (数字签名)”,这两种算法在https加密中的作用是不一样的。

增强密钥用法则不是关键字段,但是必须有的字段,这个字段进一步说明这张证书的用途,SSL证书的EKU字段值为“服务器身份验证 (1.3.6.1.5.5.7.3.1),客户端身份验证 (1.3.6.1.5.5.7.3.2)”,意思是这张SSL证书既用于服务器的身份认证,也可以用于同其他服务器通信时的一个客户端的身份认证,一般用于服务器与服务器之间的加密通信。SSL证书至少必须有“服务器身份验证”这个EKU,用于“向远程计算机证明服务器的身份”,没有这一项就无法实现同客户端证书的双向认证。

SSL证书 SSL证书

5. 证书透明日志签名数据列表(SCT List)

这个字段是判断SSL证书是否可信的两个要素之一,因为一个CA机构如果不敢把自己签发的SSL证书公示的话,谁都能想象出这个CA可能想干什么。这就是为何自2013年以来已经有97亿多张全球信任的SSL证书都已经在证书透明日志系统透明备案公示,一个负责任的公共信任的CA是愿意公示其证书签发行为的,是愿意接受公众监督。而如果有CA机构不提交CT系统公示,怎么办?如果SSL证书中没有SCT列表字段,则谷歌浏览器直接不信任,如果有,则必须满足几个条件:(1) CT日志服务必须是通过谷歌认证并预置谷歌浏览器中信任(包括Chromium);(2) 证书有效期小于180天必须包含2个SCT数据,大于180天必须包含3个。否则,谷歌浏览器一样不信任,提示“不安全”。

如下左图为Windows证书查看器看到的SCT列表字段信息,已经解析了SCT数据,第1行是证书透明版本号,目前全球各大CA和浏览器都在使用V1版本;第2行是证书透明日志服务器ID,第3行是证书透明日志系统的签名时间,第4行则是日志数据的签名算法(SHA256/ECDSA),第5行就是证书透明日志的签名数据。这些数据用于浏览器验证这张SSL证书是在哪个证书透明日志系统备案的、是何时备案的、证书透明日志系统是否是浏览器信任的等等,只有通过验证,浏览器才会正常显示加密锁标识。大家再看看右图,这是目前谷歌浏览器展示的SCT列表字段信息,根本就没有解析这个字段,这也是不可思议的事情,也许是谷歌急于推出自己的证书查看器还来不及解析这个字段,希望将来的版本能正常展示证书透明日志信息。

SSL证书 SSL证书

按照谷歌证书透明政策,对于非公共信任的企业CA,则可以没有SCT列表字段。当然,为了保障企业CA签发的SSL证书安全,也可以部署企业CT系统为SSL证书提供证书透明服务,但谷歌浏览器不查验企业CT中的SCT列表数据。

以上讲清楚了SSL证书中最关键的9个字段,这些字段遵循由国际标准组织-CA/浏览器论坛制定的国际标准,包括:SSL证书基线标准、EV SSL证书标准和CA系统网络安全要求,另外还有两个RFC国际标准,包括:证书透明(RFC6962)和自动化证书管理标准(RFC8555),SSL证书中SCT列表字段遵循的就是RFC6962标准,本文并没有讲到RFC8555标准,因为本文仅讲解SSL证书的各个字段的含义和要求,并不涉及到SSL证书的自动化申请和部署,这个知识点已经在密码讲堂第八讲讲过,大家可以查看第八讲的内容。

SSL证书由Netscape于1994年发明到现在已经将近三十年了,SSL证书相关标准也一直在不断完善中,目前SSL证书相关标准有两条线,一条线属于基础类标准,一般都会形成RFC标准,与SSL证书相关的RFC标准有:RFC2818、9110、5785、7230、6962、9162、8555等等。另一类是应用类标准,这些标准则是由CA/浏览器论坛来负责制定,并据此形成WebTrust审计标准,审计机构依据WebTrust审计标准来审计CA机构是否遵循这些标准来运营CA系统签发各种全球信任的数字证书。我国CA机构或企业自建CA系统,如果需要签发RSA/ECC算法SSL证书,当然应该参考和遵循这些标准,无论是否预置浏览器信任,遵循这些标准是为了保证SSL证书的安全,从而保障采用SSL证书实现的https加密流量安全。

下一讲内容预告|第14讲 国密SSL证书及相关国密标准
本讲详细讲解国密SSL证书中对照国际SSL证书标准必须有的最重要的9个字段的含义和作用,这些字段都是国密SSL证书必须有的而且不能错的字段。本文可供国密SSL证书使用者、CA机构和CA系统提供商学习参考。