根憑證

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書
根憑證在信任鏈中作為信任錨（英語：Trust anchor）的起點角色

在密碼學和電腦安全領域，根憑證（root certificate）是屬於根憑證頒發機構（CA）的公鑰憑證，是在公開金鑰基礎建設中，信任鏈的起點（英語：Trust anchor）[1]。憑證頒發機構的角色有如現實世界中的公證行，保證網路世界中電子憑證持有人的身分。具體作法是透過中介憑證，利用數位簽章為多個客戶簽發多個不同的終端實體憑證，形成一個以其根憑證為頂層的樹狀結構，在此傳遞關係中所有下層憑證都會因為根憑證可被信賴而繼承信任基礎。

根憑證沒有上層機構再為其本身作數位簽章，所以都是自簽憑證。許多應用軟體（例如作業系統、網頁瀏覽器）會預先安裝可被信任的根憑證，這代表使用者授權了應用軟體代為審核哪些根憑證機構屬於可靠，例如是公認可靠的政府機關（如香港郵政[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」