公开金钥认证(英语:Public key certificate),又称数位凭证(digital certificate)或身份凭证(identity certificate)。是用于公开金钥基础建设的电子档案,用来证明公开金钥拥有者的身份。此档案包含了公钥资讯、拥有者身份资讯(主体)、以及数字证书认证机构(发行者)对这份文件的数位签章,以保证这个文件的整体内容正确无误。拥有者凭著此档案,可向电脑系统或其他使用者表明身分,从而对方获得信任并授权存取或使用某些敏感的电脑服务。电脑系统或其他使用者可以透过一定的程序核实凭证上的内容,包括凭证有否过期、数位签章是否有效,如果你信任签发的机构,就可以信任凭证上的金钥,凭公钥加密与拥有者进行可靠的通讯。

Thumb
维基百科网站所使用的数位凭证,可见载有维基媒体基金会的名称、签发的数字证书认证机构、有效期及公开密钥指纹

简而言之,认证机构用自己的私钥对需要认证的人(或组织机构)的公钥施加数字签名并生成证书,即证书的本质就是对公钥施加数字签名。[1]

数位凭证的其中一个最主要好处是在认证拥有者身分期间,拥有者的敏感个人资料(如出生日期、身分证号码等)并不会传输至索取资料者的电脑系统上。透过这种资料交换模式,拥有者既可证实自己的身分,亦不用过度披露个人资料,对保障电脑服务存取双方皆有好处。

人们透过信任数字证书认证机构的根证书、及其使用公开密钥加密作数位签章核发的公开金钥认证,形成信任链架构,已在TLS实作并在万维网HTTPS、在电子邮件的SMTPS和STARTTLS广泛应用。业界现行的标准是国际电信联盟电信标准化部门制定的X.509[2],并由IETF发行的RFC 5280详细述明。而在不少国家/地区,都已立法承认使用数位凭证所作的数位签章拥有等同亲笔签名的法律效力(如欧洲联盟[3][4]香港[5][6]台湾[7]美国加拿大)。

证书种类

Thumb
根证书(自签证书)、中介证书和终端实体(TLS伺服器/客户端)证书的关系

自签证书

在用于小范围测试等目的的时候,用户也可以自己生成数字证书,但没有任何可信赖的人签名,这种自签名证书通常不会被广泛信任,使用时可能会遇到电脑软件的安全警告[8]

根证书

根证书获得广泛认可,通常已预先安装在各种软体(包括操作系统浏览器电邮软件等),作为信任链的起点,来自于公认可靠的政府机关(如香港邮政[9]台湾网路资讯中心)、证书颁发机构公司(如DigiCertGoogle[10])、非营利组织(如Let's Encrypt)等,与各大软件商透过严谨的核认程序才在不同的软件广泛部署。由于部署程序复杂费时,需要行政人员的授权及机构法人身份的核认,一张根证书有效期可能长达二十年以上。在某些企业,也可能会在内部电脑自行安装企业自签的根证书,以支援内部网企业级软件;但是这些证书可能未被广泛认可,只在企业内部适用。

中介证书

认证机构的一个重要任务就是为客户签发证书,虽然广泛认可的认证机构都已拥有根证书,相对应的私钥可用以签署其他证书,但因为密钥管理和行政考虑,一般会先行签发中介证书,才为客户作数位签署。中介证书的有效期会较根证书为短,并可能对不同类别的客户有不同的中介证书作分工。

授权凭证

授权凭证又称属性凭证,本身没有公钥,必须依附在一张有效的数位凭证上才有意义,其用处是赋予相关拥有人签发终端实体凭证的权力;某些情况下,如果只在短期内授予凭证机构签发权力,便可以不改变(缩短)该机构本身持有的凭证的有效期。这种情况,类似于某人持有长达十年期的护照,而只透过签发短期入境签证,来个别赋予护照持有人额外权力。

终端实体证书

其他不会用作签发其他证书的,都可称为终端实体证书,在实际的软件中部署,以便建立加密通道时应用。

TLS伺服器证书

伺服器通常以域名形式在互联网上提供服务,伺服器证书上主体通用名称就会是相应的域名,相关机构名称则写在组织单位一栏上。伺服器证书(包括公钥)和私钥会安装于伺服器(例如Apache),等待客户端连接时协议加密细节。客户端的软件(如浏览器)会执行认证路径验证算法英语Certification path validation algorithm以确保安全,如果未能肯定加密通道是否安全(例如证书上的主体名称不对应网站域名、伺服器使用了自签证书、或加密算法不够强),可能会警告用户。

通配符证书

如果伺服器证书上主体的通用名称(或主体别名英语Subject Alternative Name)一栏以通配符前缀,则该证书可以用于旗下的所有子域名,特别适合较具规模、或设有多个子网站的机构一次过申领,套用于多个伺服器上;即使未来建立新的子域名,也可以套用。但通配符不可用于扩展认证证书上。

TLS客户端证书

有时候,某些TLS伺服器可能会在建立加密通道时,要求客户端提供客户端证书,以验证身份控制存取权限。客户端证书包含电子邮件地址或个人姓名,而不是主机名。但客户端证书比较不常见,因为考虑到技术门槛及成本因素,通常都是由服务提供者验证客户身份,而不是依赖第三方认证机构。通常,需要使用到客户端证书的服务都是内部网的企业级软件,他们会设立自己的内部根证书,由企业的技术人员在企业内部的电脑安装相关客户端证书以便使用。在公开的互联网,大多数网站都是使用登入密码Cookie来验证用户,而不是客户端证书。

在台湾,中华民国内政部凭证管理中心根据电子签章法负责签发自然人凭证,让国民在网路使用各种政府服务[11]

客户端证书在RPC系统中更常见,用于验证连接设备的许可授权。

内容栏位

一般遵从X.509格式规范的凭证,会有以下的内容,它们以栏位的方式表示[12]

  • 版本:现行通用版本是 V3
  • 序号:用以辨识每一张凭证,特别在撤消凭证的时候有用
  • 主体:拥有此凭证的法人自然人身份或机器,包括:
    • 国家(C,Country)
    • 州/省(S,State)
    • 地域/城市(L,Location)
    • 组织/单位(O,Organization)
    • 通用名称(CN,Common Name):在TLS应用上,此栏位一般是网域
  • 发行者:以数位签章形式签署此凭证的数字证书认证机构
  • 有效期开始时间:此凭证的有效开始时间,在此前该凭证并未生效
  • 有效期结束时间:此凭证的有效结束时间,在此后该凭证作废
  • 公开金钥用途:指定凭证上公钥的用途,例如数位签章、伺服器验证、用户端验证等
  • 公开金钥
  • 公开密钥指纹
  • 数位签章
  • 主体别名英语Subject Alternative Name:例如一个网站可能会有多个网域(www.wikipedia.org, zh.wikipedia.org, zh.m.wikipedia.org 都是维基百科)、一个组织可能会有多个网站(*.wikipedia.org, *.wikibooks.org, *.wikidata.org 都是维基媒体基金会旗下的网域),不同的网域可以一并使用同一张凭证,方便实作应用及管理

申领及使用

Thumb
向凭证机构申领签发电子证书的过程

数字证书一般由数字证书认证机构签发,简单的程序如下:

申领

  1. 鲍伯在自己的机器上使用密码学安全伪随机数生成器产生一对足够强的密钥,鲍伯的私钥不会向任何人传送。
  2. 鲍伯把他的公钥,连同主体讯息、使用目的等组成凭证签署请求英语Certificate signing request,传送给认证机构伊凡
  3. 伊凡(用另外一些渠道)核实鲍伯的身份。
  4. 如果伊凡信任这个请求,他便使用鲍伯的公钥和主体讯息,加上凭证有效期、用途等限制条件,组成凭证的基本资料。
  5. 伊凡用自己的私钥对鲍勃的公钥加上数字签名并生成证书。
  6. 伊凡把生成的凭证传送给鲍伯(伊凡也可以透过证书透明度公布他签发了新的证书)。

使用

  1. 鲍伯可以随便把凭证向外发布。
  2. 鲍伯与爱丽丝事先可能互不认识,但鲍伯与爱丽丝都信任伊凡,爱丽丝使用认证机构伊凡的公钥验证数字签名,如果验证成功,便可以信任鲍勃的公钥是真正属于鲍伯的。[1]
  3. 爱丽丝可以使用凭证上的鲍勃的公钥加密明文,得到密文并传送给鲍伯。
  4. 鲍伯可以可以用自己的私钥把密文解密,得到明文。

储存格式

电子证书可以二进制Base64形式储存,常见的文件扩展名有 .cer、.crt、.der和.pem。如果把证书和私钥一起储存,则可以使用PKCS#12(.p12)格式[13]

  • DER用于二进制DER编码的证书。
  • PEM用于不同类型的X.509v3文件,是以“ - BEGIN ...”前缀的ASCII(Base64)数据。
  • CER和CRT几乎同义,证书可以被编码为二进制DER或ASCII PEM。
  • PKCS7 文件,也被称为 P7B,通常用于 Java Keystores 和 Microsoft IIS(Windows)。它们是 ASCII 文件,可以包含证书和 CA 证书。
  • PKCS12 文件,也被称为 PFX 文件,通常用于在 Micrsoft IIS(Windows)中导入和导出证书链。

审核级别

法人团体申领数位凭证的时候,可以视乎其法人的地位及其实际需要申领不同级别的凭证,认证机构会作相应的审核,越高级别的通常都牵涉越严谨的行政程序,及需付出更高昂的费用。各大凭证机构和网页浏览器软件商透过CA/浏览器论坛共同建立和维护相关的指导方针[14]

域名验证(DV)

这是最基本的审核级别,如果申领代表可以证明他拥有管理某域名的权力,认证机构就可以发放域名验证(DV)证书。认证机构通常使用自动机制(例如自动证书管理环境英语Automated Certificate Management Environment[15]或透过电邮确认)审核域名拥有权,所以成本也较低[16]

组织验证(OV)

如果申领代表可以证明他拥有管理某域名的权力,而且相关组织是实际存在的法人,认证机构可以发放组织验证(OV)证书。审核程序通常需要经过人手处理。

扩展验证(EV)

这是最严格的审核级别,审核过程可能牵涉专业法律人员的调查及独立审计人员的确认,成本也自然更高[17];成功获得扩展验证证书的网站,现代浏览器通常会在位址列以绿色表示相关机构的法人名称及所属国家代码[18]。扩展验证证书的主体名称或主体别名上不可以有通配符。

弱点与防御

公开金钥基础建设的弱点,在于人们必须循数位凭证上的信任链找到根证书,并信任核发根证书的数字证书认证机构,一旦凭证机构被黑客入侵,黑客可以在人们不知情下签发了伪冒他人身份的证书,以中间人攻击进行欺诈。业界已研发不同的防御方法,例如凭证机构可以透过证书透明度公布新签发的电子凭证,让大众检查手上收到的电子凭证是否可能未被正式授权(中间人攻击不会“公布”他伪冒了别人签发了欺诈凭证),网站管理员也可以定期检查是否有不明机构发出了未被授权的凭证。另一方面,HTTPS网站可以使用HPKP指明其固定的公钥,让中间人的欺诈凭证无法使用。另外,而OCSPOCSP装订也在发展中,让用户软体可以透过第三方检查凭证是否有效。

在公钥基础设施以外,信任网络则采用去中心化的概念,取代了依赖数字证书认证机构的公钥基础设施,因为每一张电子证书在信任链中最终只由一个根证书授权信任,信任网络的公钥则可以累积多个用户的信任。

根证书弱点与争议事件

中国互联网络信息中心发行假凭证事件

2009年,中国互联网络信息中心(CNNIC)的一名员工向Mozilla申请要求将 CNNIC 加入 Mozilla 的 根证书列表[19],并且得到了批准。后来微软也把 CNNIC加到了Windows根证书列表里。

2015年,因CNNIC发行的一个中级CA被发现发行了Google域名的假证书[20],许多用户选择不信任CNNIC颁发的数字证书[21]。并引起对CNNIC滥用证书颁发权力的担忧[22]

2015年4月2日,Google宣布不再承认CNNIC所颁发的电子证书[23][24]。4月4日,继Google之后,Mozilla也宣布不再承认CNNIC所颁发的电子证书[25]。2016年8月,CNNIC官方网站已放弃自行发行的根证书,改用由DigiCert颁发的证书。

沃通及StartCom遭封杀事件

2016年,拥有奇虎360背景的中国最大CA证书签发机构沃通(WoSign)[26]及其以色列子公司StartCom,遭谷歌拒绝承认其凭证。 ]] 沃通被揭发在短短5日内发行了几百个相同序列号的证书,以及对证书日期上造假[27]

参见

参考文献

Wikiwand in your browser!

Seamless Wikipedia browsing. On steroids.

Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.

Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.