维基百科

根证书

在密码学和计算机安全领域，根证书（root certificate）是属于根证书颁发机构（CA）的公钥证书，是在公开金钥基础建设中，信任链的起点（英语：Trust anchor）[1]。证书颁发机构的角色有如现实世界中的公证行，保证网路世界中电子证书持有人的身份。具体作法是透过中介证书，利用数位签章为多个客户签发多个不同的终端实体证书，形成一个以其根证书为顶层的树状结构，在此传递关系中所有下层证书都会因为根证书可被信赖而继承信任基础。

根证书在信任链中作为信任锚（英语：Trust anchor）的起点角色

根证书没有上层机构再为其本身作数位签章，所以都是自签证书。许多应用软件（例如操作系统、网页浏览器）会预先安装可被信任的根证书，这代表用户授权了应用软件代为审核哪些根凭证机构属于可靠，例如是公认可靠的政府机关（如香港邮政[2]）、专职机构（如Google[3]、Let's Encrypt、CAcert.org、Comodo、DigiCert、GlobalSign）等。应用软件在建立安全连接时，例如使用网页浏览器造访一个网站，会执行认证路径验证演算法（英语：Certification path validation algorithm），使用该主机提供的电子证书，验证是否能够对应到预先安装的根证书，从而验证从根证书到终端节点的路径是否为一条有效的信任链，确保TLS安全连接中的身份。但是，这意味着用户信任浏览器的发布商、它所预先安装的证书颁发机构，以及这些证书颁发机构可能颁发的所有中间证书颁发机构，相信他们忠诚地确保各证书持有人的身份和意图。

钥匙典礼

编辑
主条目：钥匙典礼（英语：Key ceremony）

凭证机构自签一张新的根凭证时，需要产生一对公开金钥及私有密钥，这个过程在公证人、律师及录影系统监察下经过一系列严谨的程序，在高度防护的设施内进行[4]。

根凭证计划

编辑

由于根凭证在公开金钥基础建设担任重要角色，负责任的凭证机构会公布凭证作业准则（英语：Certification Practice Statement）以供公众查阅，并负上法律责任[5]。根证书一般会预先在不同的软体广泛部署，所以各大软体商（如Mozilla[6]、微软[7]、苹果公司[8]、甲骨文公司Java[9]、Adobe Systems[10][11]）也发布自己的审核标准，列明严谨的核认程序，例如行政人员的授权及机构法人身分的核认，才会部署于软件产品，发放给大众用户安装。而由于部署程序复杂费时，凭证机构发出的根凭证有效期可能长达十年以上。

在不少较为发达的国家和地区，都已立法承认数位签章拥有等同亲笔签名的法律效力，并列出在法律上可被信任的根凭证（如欧洲联盟[12][13]、香港[14][15]、台湾[16]）。

自行安装根证书

编辑
 
在Ubuntu上Firefox的电子证书管理用户介面

虽然应用软件会根据审核标准预载一系列可靠的根证书，但用户仍然可以透过介面自行增删其电脑上所安装并信任的根证书清单[17][18]。有时候，用户连接某些网站时，会得到来自应用软件（浏览器）的安全警告，但基于实际情况，仍然可能选择信任网站，跳过警告以继续；典型的例子是一般家用路由器，这些家用路由器的设定介面一般是以网页形式在浏览器上执行，如果设定成为“以HTTPS连接”，则其原厂设定所使用的电子证书一般为自签证书，即未经凭证机构数位签章担保，但用户仍然可能选择跳过警告，甚至在浏览器的信任根证书清单增加路由器的自签证书，以便日后再设定时不必再收到浏览器的安全警告[19]。另外一种情况，就是企业内部网的企业级软件，企业的资讯工程部门可能在员工的电脑上安装了企业自行管理的根证书，使企业软件不必倚赖外间第三者的凭证机构，而是可以自行担当企业内部的凭证机构[20]；但是这些根凭证可能未被广泛认可，只在企业内部适用[21]。

警告

编辑

自行安装根证书，或跳过应用软件的安全警告，都可能会使用户面对资讯安全风险，可能使应用软件的保固条款失效，甚至使用户的法律权益受损。尤其是在知名网站、银行及政府机关等都不应有这种需要。使用者需自行了解所要安装的根证书的加密技术、所属网站的真实身份及用户的法律权责[19]。

截取通讯

编辑
 
如果马洛里可以在爱丽斯的电脑安装他自己的根证书，并以代理伺服器身份转发爱丽斯的对外连线，他便可以解密得到爱丽斯的加密讯息，而爱丽斯和鲍伯双方并不知情

无论是出于企业为了保障网路安全[22][23]、或为了监控员工、或间谍软件和特洛伊木马为了窃取用户资讯，只要有人得到用户电脑的控制权，可以任意安装根凭证，并且可以进行域名服务器缓存污染或控制网路路由，就可以进行中间人攻击以解密用户与远端伺服器之间的安全连线[24]，以下用爱丽丝与鲍伯作范例：

  1. 假设爱丽丝的电脑已在较早前被马洛里安装了特定的根凭证，马洛里拥有对应的私钥
  2. 当爱丽丝尝试与鲍伯建立安全连线时，马洛里以代理服务器的身份先行收到连线请求
  3. 马洛里暂时搁下爱丽丝的请求，转而建立另一条连线向鲍伯请求他的电子证书
  4. 鲍伯的电子证书已得到一个受广泛认可的认证机构数位签章，如果马洛里如实转交给爱丽斯，一切都不会有问题
  5. 但马洛里使用自己的私钥签发一个电子证书，证书上主体名称声称是属于鲍伯，并交给爱丽斯，而鲍伯不曾知道
  6. 爱丽斯验证收到的电子证书，根据其信任链，她找到签发的根证书
  7. 她发现自己的电脑中已安装并信任这样一个根证书，便信以为真，开始使用证书上的公钥与鲍伯的秘密通讯
  8. 其实该根证书就是马洛里早前安装上去用以欺骗爱丽斯，这时马洛里能够利用自己的私钥解密爱丽斯传出的密文，并即时再用先前收到、鲍伯真正的电子证书上的公钥再加密，并传给鲍伯
  9. 鲍伯收到密文时不虞有诈，他能够用自己的私钥解密马洛里传送过来的密文

由此可见，爱丽斯与鲍伯都以为他们可以安全通讯，但却不知道马洛里可以在中间窃听，甚至篡改通讯内容。

防御方法

编辑

要避免中间人攻击置换假冒的电子证书，HTTPS网站可以使用HPKP指明其固定的公钥，让中间人的欺诈证书无法使用。另外，凭证机构可以透过证书透明度公布签发的电子证书，让大众检查手上收到的电子证书是否可能未被正式授权（中间人攻击不会“公布”他伪冒了别人签发了欺诈证书），网站管理员也可以定期检查是否有不明机构发出了未被授权的证书。而OCSP和OCSP装订也在发展中，让用户软件可以透过第三方检查证书是否有效。

保护根凭证

编辑

由于根凭证在信任链中的重要角色，一旦凭证机构的私钥外泄，将可能导致整个信任链被摧毁，影响广及众多客户，所以认证机构会使用各种方法保护根凭证，例如硬体安全模组。有些储存私钥的电脑甚至平时不会连线，只在固定的排程下，经过一系列严谨的行政程式重重把关，才会取出私钥为客户签章凭证。在信任链设计中，绝大部份的根凭证都不会直接为客户签章，而是先签章一个（或多个）中继凭证，再由中继凭证为客户签章，这可以加强控管能力及控制一旦签章私钥被泄时的损失[25][26]。

根证书可信任程度争议

编辑

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

编辑

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

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

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

沃通及StartCom遭封杀事件

编辑

2016年，拥有奇虎360背景的中国最大CA证书签发机构沃通（WoSign）[33]及其以色列子公司StartCom，遭谷歌拒绝承认其凭证。

沃通被揭发在短短5日内发行了几百个相同序列号的证书，以及对证书日期上造假[34]，甚至签发了一张假的Github证书[35]。

微软也曾在2017年表示会将相关证书下架[36]，但在2021年2月仍有用户表示沃通和StartCom的证书在Windows 10仍然生效，只能手动移除证书[37]。

中国铁路客户服务中心网站自签根证书

编辑
参见：中国铁路客户服务中心

中国铁路客户服务中心（简称：12306网站）初期启用https访问时，使用的是由证书机构的名称为“Sinorail Certification Authority”（SRCA）颁发的证书，而该根证书并没有记录在任何公开的根证书记录中，所以会被浏览器出于安全性而阻止访问，12306网站也在网站上要求用户手工添加该根证书，由于证书缺少证书吊销列表等问题，同样地也引发对该根证书对用户隐私安全的隐忧，或者和CNNIC根证书一样抱以不信任处理。用户在支付票款时所使用的站点（即pay.12306.cn）是使用由Verisign签发的有效证书。在2017年12月12日开始，主站点陆续开始更换为由DigiCert签发的证书，直至现在，全站已更换为DigiCert签发的证书。

哈萨克斯坦政府根证书

编辑
主条目：哈萨克斯坦政府实行的中间人攻击

2015年至2020年间，哈萨克斯坦政府通过颁发并劝诱用户安装其颁发的网络根证书，试图实现对HTTPS流量的监控，但遭到软件厂商的抵制而未能成功。

欧盟根证书

编辑

2023年，欧盟计划制定法规eIDAS 2.0，其中第45条规定禁止浏览器未经成员国批准下对某些政府指定的CA根证书进行现代安全检查，意味着政府可以通过这些CA实现对HTTPS流量的监控，电子前线基金会、一些相关行业厂商（浏览器开发商，CDN服务商）和安全专家等对此表示担忧或要求欧盟对此释义。[38][39][40][41]

参考资料

编辑
  1. ^ RFC 4158. IETF （英语）. all of the end entities and relying parties use a single "Root CA" as their trust anchor. If the hierarchy has multiple levels, the Root CA certifies the public keys of intermediate CAs (also known as subordinate CAs). These CAs then certify end entities' (subscribers') public keys or may, in a large PKI, certify other CAs. 
  2. ^ 關於香港郵政電子證書. 香港邮政. [2017-07-15]. （原始内容存档于2020-08-20）. 香港邮政在二零零零年成立香港第一家在《电子交易条例》（香港法例第553章）下的认可公共核证机关。现时，香港邮政核证机关发出符合电子交易条例要求的“认可数码证书”。根据《电子交易条例》，使用该条例下认可的数码证书作出的数码签署与书面的签署具同等法律效力。 
  3. ^ Repository of Documentation and Certificates. Google Trust Services. [2017-07-15]. （原始内容存档于2020-12-19） （英语）. The Google Public Key Infrastructure (“Google PKI”), has been established by Google Trust Services, LLC (“Google”), to enable reliable and secure identity authentication, and to facilitate the preservation of confidentiality and integrity of data in electronic transactions. 
  4. ^ Key Ceremony. Digi-Sign. [2017-07-20]. （原始内容存档于2020-10-26） （英语）. A Key Ceremony is only required when your organisation wishes to achieve your own independent root, or intermediate, Certificate Authority. This typically occurs where an organisation wants to create and own its own Root CA for reasons relating to compliance to specific standards (e.g. ISO 27001, WebTrust, EU Qualified Certificates, etc). A Root Key Ceremony is a procedure where a unique pair of Public and Private Root Keys is generated. Depending on your requirements and specifications, the generation of the Root Keys may require notarisation, legal representation, witnesses and "Key Holders" to be present 
  5. ^ Policy and Legal Repository. Let's Encrypt. [2017-07-15]. （原始内容存档于2021-02-24） （英语）. 
  6. ^ Mozilla Root Store Policy. Mozilla. [2017-07-15]. （原始内容存档于2017-04-15） （英语）. When distributing binary and source code versions of Firefox, Thunderbird, and other Mozilla-related software products, Mozilla includes with such software a set of X.509v3 root certificates for various Certification Authorities (CAs). The included certificates have their "trust bits" set for various purposes, so that the software in question can use the CA certificates to anchor a chain of trust for certificates used by SSL servers and S/MIME email users without having to ask users for further permission or information. 
  7. ^ Microsoft Trusted Root Certificate: Program Requirements. 微软 （英语）. The Microsoft Trusted Root Certificate Program ("Program") supports the distribution of qualifying root certificates in Microsoft Windows and other Microsoft Products and Services. 
  8. ^ Apple Root Certificate Program. 苹果公司. [2017-07-15]. （原始内容存档于2017-03-20） （英语）. Apple uses public key infrastructure (PKI) to secure and enhance the experience for Apple users. Apple products, including our web browser Safari and Mail.app, use a common store for root certificates. Apple requires root certification authorities to meet certain criteria[...] 
  9. ^ Including Certificate Authority Root Certificates in Java. 甲骨文公司. [2017-07-15]. （原始内容存档于2019-11-27） （英语）. In order to protect Oracle's Java SE customers from security issues related to the use of public key infrastructure (PKI) certificates while enhancing their overall experience, Oracle requires that all root certificates authorities meet the following criteria before applying for inclusion of their root certificates in Oracle’s Java Runtime Environment (JRE). 
  10. ^ Adobe Approved Trust List. Adobe Systems. [2017-07-15]. （原始内容存档于2018-06-02） （英语）. Essentially, both Acrobat and Reader have been programmed to reach out to a web page to periodically download a list of trusted "root" digital certificates. Any digital signature created with a credential that can trace a relationship ("chain") back to the high-assurance, trustworthy certificates on this list is trusted by Acrobat and Reader. 
  11. ^ EU Trusted List now available in Adobe Acrobat!. Adobe Systems. 2015-10-26 [2017-07-15]. （原始内容存档于2017-03-20） （英语）. Adobe is delighted to announce the completion of our work to support and integrate the EU Trusted Lists (EUTL) into Adobe Acrobat and Acrobat Reader. For the first time, citizens, governments and businesses across the world will have easy access to electronically signed documents based on EU qualified certificates in the ubiquitous Adobe Acrobat and Acrobat Reader software. 
  12. ^ EU Trusted Lists. 欧洲联盟委员会. 2017-05-09 [2017-07-15]. （原始内容存档于2020-08-25） （英语）. Under the Regulation (EC) No 910/2014/EU (eIDAS Regulation), national Trusted Lists have a constitutive effect. In other words, a trust service provider and the trust services it provides will be qualified only if it appears in the Trusted Lists. Consequently, the users (citizens, businesses or public administrations) will benefit from the legal effect associated with a given qualified trust service only if the latter is listed (as qualified) in the Trusted Lists. 
  13. ^ REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC. EUR-Lex. 2014-08-28 [2017-07-15]. （原始内容存档于2018-01-15） （英语）. A qualified electronic signature shall have the equivalent legal effect of a handwritten signature. 
  14. ^ 香港的認可核證機關. 政府资讯科技总监办公室. 2017-06-30 [2017-07-15]. （原始内容存档于2017-10-27） （中文（香港））. 核证机关在确保公开密码匙基础建设的有效运作方面担当重要角色，并作为可信赖的第三方，负责证明电子交易所涉及有关各方的身分。目前，香港有两间根据《电子交易条例》（第553章）获得认可的核证机关。根据《电子交易条例》，邮政署署长是认可核证机关，提供香港邮政核证机关服务，而电子核证服务有限公司则是根据《电子交易条例》下核证机关自愿认可计划获得认可的商营核证机关。 
  15. ^ 《電子交易條例》(第553章). 政府资讯科技总监办公室. 2017-06-30 [2017-07-15]. （原始内容存档于2017-06-29） （中文（香港））. 政府于2000年1月制定《电子交易条例》(第553章)（“条例”），并于2004年6月作出修订。大体上，条例旨在：赋予电子纪录及电子签署（请看下文的注释1）跟纸张文件上的纪录和签署同等的法律地位；以及设立核证机关自愿认可计划以加强社会人士对电子交易的信心。（注释1︰就不涉及政府单位的电子交易而言，任何形式的电子签署，只要可靠恰当并获签署的接受人认同，已能符合法律有关签署的规定。就涉及政府单位的电子交易而言，有认可数码证书证明的数码签署，便符合法律上的签署规定。） 
  16. ^ 電子簽章法. 中华民国法务部全国法规资料库工作小组. 2001-11-14 [2017-07-15]. （原始内容存档于2020-08-08） （中文（台湾））. 依法令规定应签名或盖章者，经相对人同意，得以电子签章为之。 
  17. ^ 管理受信任的根憑證. 微软. [2017-07-19]. （原始内容存档于2013-04-12） （中文（台湾））. 某些组织可能会想要管理凭证信任，并避免网域中的使用者设定自己的信任根凭证集。此外，某些组织在需要额外信任关系的状况下，会需要识别并分送特定的信任根凭证，以符合业务所需。 
  18. ^ PSM:Changing Trust Settings. Mozilla. 2017-05-05 [2017-07-20]. （原始内容存档于2021-10-11） （英语）. This page describes how to change the default root certificate trust settings in Mozilla products, including Firefox and Thunderbird. [...] Some browsers only display the root certificates that the user has actually used, and dynamically download new ones on demand. However, Mozilla believes it is important for users to know the root certificates that could be used, so the full set of certificates is always shown. This also allows you to edit the trust bits for any root certificates that you do not want to use. 
  19. ^ 19.0 19.1 排除在安全性網站上 "SEC_ERROR_UNKNOW_ISSUER" 的錯誤代碼. Mozilla. 2016-06-29 （中文（台湾））. 警告： 您永远不该为合法的主要网站或金融交易网站增加凭证例外 - 此时无效的凭证可能表示您的连线正受到第三方的危害。如果允许，您可以增加例外以造访网站，虽然它的凭证预设是不受信任的：在警告网页，点击 进阶。点击 增加例外…。将显示 增加安全例外 对话框。阅读叙述网站问题的文字。您可以点击 检视… 来更精确的检视此不受信任的凭证。如果您确认您想信任些网站，点击 确认安全例外。 
  20. ^ 在中小企業建立企業根憑證授權單位. 微软. [2017-07-16]. （原始内容存档于2013-12-01） （中文（台湾））. 这份文件提供的指示可帮助您建立企业根 CA、使用凭证范本启用自动注册、为无线使用者建立自动注册。您可以学到如何执行下列工作：安装及设定企业根 CA。 
  21. ^ SSL/TLS Certificates for Internal Servers. GlobalSign. 2016-09-29 [2017-07-16]. （原始内容存档于2020-11-12） （英语）. Enterprises can easily push out the necessary IntranetSSL non-public roots to their users via Group Policy Object (GPO), or other centralized management system which will make the IntranetSSL certificates trusted by their user community. 
  22. ^ SSL Forward Proxy. 派拓网络. [2017-07-17]. （原始内容存档于2017-12-01） （英语）. The firewall uses certificates to establish itself as a trusted third party to the session between the client and the server [...] When the client initiates an SSL session with the server, the firewall intercepts the client SSL request and forwards the SSL request to the server. The server returns a certificate intended for the client that is intercepted by the firewall. If the server certificate is signed by a CA that the firewall trusts, the firewall creates a copy of the server certificate signs it with the firewall Forward Trust certificate and sends the certificate to the client [...] When the client authenticates the certificate, the SSL session is established with the firewall functioning as a trusted forward proxy to the site that the client is accessing. As the firewall continues to receive SSL traffic from the server that is destined for the client, it decrypts the SSL traffic into clear text traffic and applies decryption and security profiles to the traffic. The traffic is then re-encrypted on the firewall and the firewall forwards the encrypted traffic to the client. 
  23. ^ SSL Forward Proxy Overview. Juniper Networks. 2016-06-14 [2017-07-17]. （原始内容存档于2021-02-25） （英语）. SSL forward proxy is a transparent proxy; that is, it performs SSL encryption and decryption between the client and the server, but neither the server nor the client can detect its presence. SSL forward proxy ensures that it has the keys to encrypt and decrypt the payload 
  24. ^ Jeremy Schatten. Setup Squid Forward Proxy. 2016-09-09 [2017-07-17]. （原始内容存档于2018-03-16） （英语）. In this configuration, the proxy is performing what in another context would be considered a man-in-the-middle attack. The client is completely unaware that somewhere their traffic is being sent is posing as the destination, decrypting their communication, and re-encrypting it to send to the real target server. Responses are captured on-the-fly as well, and sent back to the origin server. [...] It presents a certificate valid for any domain that it generates as requests hit it in real time, and because the client needs to be configured to trust the same root CA certificate the proxy uses, will allow the connection. (Remember, any certificate trusted as a root certificate can sign valid certificates for any and all domains and paths, not just its own.) 
  25. ^ 什麼是中間憑證？. GoDaddy. [2017-07-20]. （原始内容存档于2021-03-04） （中文（台湾））. 中间凭证为我们根凭证的替身。由于我们必须将我们的根凭证置于数层安全防护之后，因此我们利用中间凭证作为 proxy，确保根凭证的密钥绝对无法被存取。但是，由于根凭证本身签署了中间凭证，中间凭证可以被用来签署我们的客户安装与维护的“信任连锁” SSL。 
  26. ^ How do certification authorities store their private root keys?. Stack Exchange. [2017-07-20]. （原始内容存档于2021-01-22） （英语）. For extra recovery, the CA is often split into a long-lived root CA which is kept offline, and a short-lived intermediate CA. Both machines are in the cage and bunker; the root CA is never connected to a network. The root CA is physically accessed, with dual control (at least two people together, and video recording) on a regular basis, to emit the certificate for the intermediate CA 
  27. ^ 476766 - Add China Internet Network Information Center (CNNIC) CA Root Certificate. bugzilla.mozilla.org. [2020-01-03]. （原始内容存档于2020-02-22） （英语）. 
  28. ^ CNNIC发行的中级CA发行了Google的假证书. solidot. 2015-03-24 [2015-03-24]. （原始内容存档于2015-03-26）. 
  29. ^ 最危险的互联网漏洞正在逼近. [2015-03-26]. （原始内容存档于2015-11-21）. 
  30. ^ 谷歌不再承認中國CNNIC頒發的信任證書. 华尔街日报. 2015-04-03 [2015-04-03]. （原始内容存档于2020-03-27）. 
  31. ^ 谷歌不再信任中国CNNIC 的网站信任证书. 美国之音. 2015-04-03 [2015-04-03]. （原始内容存档于2015-04-05）. 
  32. ^ Mozilla紧随谷歌 拒绝承认中国安全证书. 美国之音. 2015-04-04 [2015-04-04]. （原始内容存档于2015-04-10）. 
  33. ^ 谷歌宣布开始全面封杀使用沃通CA证书网站，信誉破产的恶果 - 超能网. www.expreview.com. [2020-01-03]. （原始内容存档于2020-08-20）. 
  34. ^ CA:WoSign Issues - MozillaWiki. wiki.mozilla.org. [2020-01-03]. （原始内容存档于2016-10-28）. 
  35. ^ Stephen Schrauger. The story of how WoSign gave me an SSL certificate for GitHub.com. Schrauger.com. [2021-03-15]. （原始内容存档于2017-03-17）. 
  36. ^ Microsoft Defender Security Research Team. Microsoft to remove WoSign and StartCom certificates in Windows 10. Microsoft. 2017-08-08 [2021-03-15]. （原始内容存档于2020-11-12）. 
  37. ^ Toxic Root-CA certificates of WoSign and StartCom are still active in Windows 10. Windows Phone Info. [2021-03-15]. （原始内容存档于2021-09-27）. 
  38. ^ Hoffman-Andrews, Jacob. Article 45 Will Roll Back Web Security by 12 Years. Electronic Frontier Foundation. 2023-11-07 [2023-11-13]. （原始内容存档于2023-12-30） （英语）. 
  39. ^ Industry Joint Statement on Article 45 in the EU's eIDAS Regulation (PDF). [2023-11-13]. （原始内容存档 (PDF)于2024-01-12）. 
  40. ^ Claburn, Thomas. Europe prepares to break browser security with eIDAS 2.0. www.theregister.com. [2023-11-13]. （原始内容存档于2024-02-02） （英语）. 
  41. ^ Last Chance to fix eIDAS. last-chance-for-eidas.org. [2023-11-13]. （原始内容存档于2023-12-30）. 
检索自“https://zh.wikipedia.org/w/index.php?title=根证书&oldid=80790637”