根证书

在密码学和计算机安全领域，根证书（root certificate）是屬於根证书颁发机构（CA）的公钥证书，是在公開金鑰基礎建設中，信任鏈的起點[1]。证书颁发机构的角色有如现实世界中的公證行，保證網路世界中電子證書持有人的身份。具體作法是透過中介證書，利用數位簽章為多個客戶签发多个不同的終端實體证书，形成一个以其根证书為顶层的樹狀結構，在此传递关系中所有下層證書都会因為根证书可被信赖而继承信任基礎。

根證書在信任鏈中作為信任錨的起點角色

根證書沒有上層機構再為其本身作數位簽章，所以都是自簽證書。许多应用软件（例如操作系统、网页浏览器）会預先安裝可被信任的根证书，這代表用戶授權了應用軟件代為審核哪些根憑證機構屬於可靠，例如是公認可靠的政府機關（如香港郵政[2]）、專職機構（如Google[3]、Let's Encrypt、CAcert.org、Comodo、DigiCert、GlobalSign）等。應用軟件在建立安全連接時，例如使用网页浏览器造訪一個網站，会執行認證路徑驗證演算法，使用該主機提供的電子證書，驗證是否能夠對應到預先安裝的根證書，從而验证從根證書到終端節點的路徑是否為一條有效的信任鏈，確保TLS安全连接中的身份。但是，这意味着用户信任浏览器的发布商、它所預先安裝的证书颁发机构，以及这些证书颁发机构可能颁发的所有中间证书颁发机构，相信他们忠诚地确保各证书持有人的身份和意图。

鑰匙典禮

憑證機構自簽一張新的根憑證時，需要產生一對公開金鑰及私有密鑰，這個過程在公證人、律師及錄影系統監察下經過一系列嚴謹的，在高度防護的設施內進行[4]。

根憑證計劃

由於根憑證在公開金鑰基礎建設擔任重要角色，負責任的憑證機構會公佈憑證作業準則以供公眾查閱，並負上法律責任[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. . 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. . 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. . 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. . Let's Encrypt. [2017-07-15]. （原始内容存档于2021-02-24） （英语）.
  6. . 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. . 微软 （英语）. The Microsoft Trusted Root Certificate Program ("Program") supports the distribution of qualifying root certificates in Microsoft Windows and other Microsoft Products and Services.
  8. . 蘋果公司. [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. . 甲骨文公司. [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 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. . 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. . 欧洲联盟委员会. 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. . 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. . 政府資訊科技總監辦公室. 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. . 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. . Mozilla. 2016-06-29 （中文（臺灣））. 警告： 您永遠不該為合法的主要網站或金融交易網站增加憑證例外 - 此時無效的憑證可能表示您的連線正受到第三方的危害。如果允許，您可以增加例外以造訪網站，雖然它的憑證預設是不受信任的：在警告網頁，點擊 進階。點擊 增加例外…。將顯示 增加安全例外 對話框。閱讀敘述網站問題的文字。您可以點擊 檢視… 來更精確的檢視此不受信任的憑證。如果您確認您想信任些網站，點擊 確認安全例外。
  20. . 微軟. [2017-07-16]. （原始内容存档于2013-12-01） （中文（臺灣））. 這份文件提供的指示可幫助您建立企業根 CA、使用憑證範本啟用自動註冊、為無線使用者建立自動註冊。您可以學到如何執行下列工作：安裝及設定企業根 CA。
  21. . 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. . 派拓网络. [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. . 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. . 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. . 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. . bugzilla.mozilla.org. [2020-01-03]. （原始内容存档于2020-02-22） （英语）.
  28. . solidot. 2015-03-24 [2015-03-24]. （原始内容存档于2015-03-26）.
  29. . [2015-03-26]. （原始内容存档于2015-11-21）.
  30. . 華爾街日報. 2015-04-03 [2015-04-03]. （原始内容存档于2020-03-27）.
  31. . 美國之音. 2015-04-03 [2015-04-03]. （原始内容存档于2015-04-05）.
  32. . 美國之音. 2015-04-04 [2015-04-04]. （原始内容存档于2015-04-10）.
  33. . www.expreview.com. [2020-01-03]. （原始内容存档于2020-08-20）.
  34. . wiki.mozilla.org. [2020-01-03]. （原始内容存档于2016-10-28）.
  35. Stephen Schrauger. . Schrauger.com. [2021-03-15]. （原始内容存档于2017-03-17）.
  36. Microsoft Defender Security Research Team. . Microsoft. 2017-08-08 [2021-03-15]. （原始内容存档于2020-11-12）.
  37. . Windows Phone Info. [2021-03-15]. （原始内容存档于2021-09-27）.
  38. Hoffman-Andrews, Jacob. . Electronic Frontier Foundation. 2023-11-07 [2023-11-13]. （原始内容存档于2023-12-30） （英语）.
  39. (PDF). [2023-11-13]. （原始内容存档 (PDF)于2024-01-12）.
  40. Claburn, Thomas. . www.theregister.com. [2023-11-13]. （原始内容存档于2024-02-02） （英语）.
  41. . last-chance-for-eidas.org. [2023-11-13]. （原始内容存档于2023-12-30）.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.