金鑰竟然是4：誰在決定你的軟體該信任哪些網站

本文由英文原文機器翻譯而成。

最後更新：2026年11月2日 · 閱讀時間約19分鐘

我們這裡有個問題

2026年10月17日星期六，世界協調時間（UTC）18:05，Chrome的根憑證計畫收到一份資安研究人員的報告；外界只知道這名研究人員叫Wayne。他聲稱握有eMudhra旗下8個憑證機構的私鑰；eMudhra是總部設在印度班加羅爾的上市公司。為了證明此言不虛，他用這8把金鑰分別簽署了同一則簡短訊息：「我們這裡有個問題——Wayne。」

他根本不必入侵任何系統。消息傳開後，資安研究人員Scott Helme描述了這些金鑰的模樣：其中一把就是數字4，另外兩把是56和115。Helme說，他在自己的筆電上，從這些金鑰的公開憑證把它們全部還原出來，花了不到一秒。記者的獨立查證也確認，eMudhra「EM OV TLS CA – G3C」背後的私鑰正是4。

這8個都是中繼憑證機構，也就是憑證公司裡實際替別人簽發憑證的那一層。其中6個獲授權簽發網站憑證，受到Chrome、Mozilla、微軟與蘋果的根憑證計畫信任。另外兩個用於程式碼簽署，也就是軟體開發商替自家程式簽名所用的憑證，受到微軟信任。這些金鑰當初產生的方式有誤，因此任何知道該往哪裡找的人，都能直接從憑證本身算出金鑰，而憑證按設計本來就是公開的。自從這些憑證在2025年4月建立以來，情況一直如此。

UTC時間19:45，也就是報告送達1小時40分鐘後，Chrome已確認這些發現，並向使用者推送了封鎖措施。沒有人需要安裝更新，也不必重新啟動瀏覽器。

速度之所以要緊，在於這種金鑰能做的事。任何人只要握有6把網站金鑰中的任何一把，又能攔截某人的連線，就能拿出一張偽造的憑證，冒充銀行、電子郵件服務或任何其他網站，不論真正的網站用的是哪家憑證公司；而信任eMudhra憑證鏈的軟體都會照單全收。擋在中間的主要防線有兩道：一是名為「憑證透明度」（Certificate Transparency）的公開記錄系統，有些軟體堅持要求，許多軟體則不然；二是各套軟體及時收到的封鎖措施。

一張偽造憑證能否得逞，取決於幾個平常看不見的決定：誰為一個網站背書，誰決定這位背書者值得相信，以及一旦背書者本身出了問題，這份信任能多快被撤回。

憑證擔保的是什麼

網站憑證是一份經過簽署的小文件，把一個名稱（例如銀行的網址）和一把公鑰綁在一起。公鑰與私鑰成對存在。私鑰保密，用來產生數位簽章；公鑰則讓任何人都能檢查某個簽章是否出自與它配對的那把私鑰。你的瀏覽器連上一個網站時，網站要證明自己握有與憑證中公鑰相符的私鑰。憑證本身聲明這把公鑰屬於這個名稱，而憑證機構（certificate authority，CA）則以簽署為這項聲明背書。

CA在簽署網站憑證之前，必須確認申請者確實掌控該網域。其中一種獲准的方法，是給申請者一個隨機值，再到該網域的DNS紀錄裡找它。DNS是網際網路的公開通訊錄，只有掌控該網域的人才可能把這個值放進去。CA也可以用一種名為「持有證明」（proof of possession）的技術檢驗，確認申請者確實握有它要求認證的那把私鑰，不過底層標準也允許CA直接採信申請者的說法。

沒有一個瀏覽器能親自查核全世界每一家CA，因此信任是沿著一條鏈層層委託下去的。鏈的頂端是根憑證，收在一份稱為「信任儲存區」（trust store）的清單裡，這份清單就內建在你的作業系統或瀏覽器中。根憑證授權中繼CA，中繼CA再簽發網站使用的憑證。你的軟體看到一個網站的憑證時，會沿著簽章往上追溯，從網站到中繼CA，再到根憑證；只有在這條鏈終止於它信任儲存區裡的某張根憑證、每個簽章都驗證無誤、憑證仍在有效期內且涵蓋正在造訪的名稱，而軟體的其他規則也都不禁止時，它才會接受這個網站。

根憑證計畫由蘋果、Google、微軟與Mozilla等作業系統和瀏覽器廠商經營，負責審查憑證機構，決定哪些根憑證能進入信任儲存區。這正是中繼CA的私鑰如此珍貴的原因。除非被限定只能用於特定名稱（eMudhra的中繼CA並沒有這種限制），一個中繼CA可以替任何網域簽發憑證，而這張憑證往上驗證，就能一路連到受信任的根憑證。根憑證自己的金鑰可以一直深鎖不動；日常簽署靠的是中繼CA的金鑰，一旦它外洩，根憑證的背書也跟著外洩。

這一切都無法告訴你一個網站是否誠實，儘管許多人以為瀏覽器上的鎖頭圖示代表的正是這一點。Google在2021年研究這個問題時，只有11%的受試者正確理解鎖頭的意思，而幾乎所有釣魚網站都使用HTTPS，因此同樣顯示鎖頭。2023年，Google宣布Chrome將以另一個圖示取代鎖頭。一張基本的憑證只說明，連線通往的是握有該名稱金鑰的那一方。有些憑證還會載明網站背後的組織，但沒有一張憑證能為對方的意圖擔保。

此外還有一層。憑證透明度（CT）由Google工程師在2013年提出，把憑證放進公開日誌，任何人都能稽核每家CA簽發過什麼。設計者的本意是，用戶端最終會拒絕任何未登錄日誌的憑證；如此一來，凡是被排除在日誌之外的憑證，不論出自CA，還是出自握有CA金鑰的竊賊，都會遭到拒絕。對於每一條仰賴Chrome根憑證儲存區的連線，Chrome預設都是這樣做。

沒人理會的警訊

製作CA金鑰的規則十分嚴格。對於根憑證和某些中繼CA的金鑰，業界的《基本要求》（Baseline Requirements），也就是瀏覽器根憑證計畫與CA共同維護的那本規則手冊，規定CA必須依照書面的金鑰產生腳本操作，並由合格的稽核人員親臨見證整場儀式，或者全程錄影。任何CA金鑰都必須由數人共同產生，而且其中沒有任何一人掌握獨力完成所需的全部知識。

2025年4月30日，eMudhra一口氣建立了24個中繼CA。它們分成A、B、C三個系列，使用兩種金鑰：RSA，以及一種名為P-384的橢圓曲線金鑰；用途則有4種。出問題的8把金鑰，正是B、C兩個系列裡所有的P-384金鑰。這8把全都是小於256的整數。如果完整寫出來，每一把都是一長串的零，只有最後一個位元組裡有東西。

這把金鑰為什麼猜得到

P-384曲線上的私鑰其實就是一個數字，在1和某個固定上限之間隨機選出，而這個上限本身就長達384位元。公鑰由私鑰計算而得，這種計算往前算很容易，但只要那個數字真正隨機，想反推回去就毫無希望。公鑰就印在憑證上。數字4是完全合法的私鑰，卻也是任何人最先會試的數字之一。Mozilla指出，這麼小的金鑰幾乎轉眼就能還原：把1、2、3一路到256各自對應的公鑰算出來，逐一和憑證上的公鑰比對。兩者相符時，私鑰就是你一開始代入的那個數字。真正隨機的金鑰，不會給你這麼短的一份清單。正如Scott Helme所說，這個範圍裡大約有10的115次方種可能，「所以永遠不會有人去把它搜一遍」。Mozilla的Dennis Jackson也把這項任務交給在本機執行的AI代理程式。它們只憑一段簡單的提示詞，第一次嘗試就還原出了金鑰。

一場金鑰儀式，怎麼會產生這麼小的數字？eMudhra在10月19日發布的初步說明是，當天使用的腳本有瑕疵。該公司說，它曾核准對常規程序做一次性的變更，以測試金鑰匯出；一個程式錯誤讓硬體在正規金鑰之外，另外產生了第二組較弱的金鑰對；而由於兩者的標籤看起來很像，這些弱金鑰隨後被誤用來申請憑證。eMudhra說，這些金鑰是在Utimaco製造的硬體安全模組裡產生的；這種防竄改裝置，本來就是用來產生並守護CA金鑰的。

eMudhra自稱這份說明只是初步版本，而它並沒有解開核心謎團。Mozilla公開bug頁面上的一名留言者指出，若不是這些金鑰在安全硬體之外產生、再違反政策載入硬體，就是這套硬體不知怎地可以被設定成自己產生有缺陷的金鑰。另一名參與者則在Mozilla的公開郵件群組上提出一個未經證實的推測：某個軟體把一個指向硬體內真正金鑰的小檔案，誤當成了金鑰本身。Mozilla下了大得多的工夫，仍無法還原同一批次中A系列的P-384金鑰。它在10月20日向eMudhra提出問題，限24小時內答覆；到了10月23日，它仍未收到任何回音，弱金鑰究竟從何而來，也依然沒有解釋。

有據可查的是，問題早在一年多前就已現形。2025年6月，一個公開的監測服務顯示，eMudhra為這幾個中繼CA提供的6份憑證撤銷清單，簽章都無效。憑證撤銷清單（CRL）是一份經過簽署的登記冊，列出CA已作廢的憑證，其簽章必須能以CA憑證中的公鑰驗證。eMudhra當時的報告說，另一家憑證公司Sectigo早在2025年6月3日就以電子郵件首度警告它，但這封郵件被內部過濾機制隔離，沒有人看到。有問題的清單在6月6日換掉了。

2026年10月，eMudhra說明了當時的修正是怎麼回事。那些清單起初是用原本那組真正隨機的金鑰簽署的；但由於憑證裡放的是弱金鑰的公鑰那一半，這些簽章驗證失敗，公司便改用有缺陷的金鑰重新簽署清單。換句話說，2025年6月時，eMudhra手上已有證據顯示，它的憑證和它以為自己正在使用的金鑰對不上，而它的做法是把清單修好。

Chrome的根憑證計畫追問eMudhra，為何只是重新簽署清單，而沒有暫停營運、調查這些CA為何存在兩組金鑰對，並撤銷相關憑證。eMudhra說，它的根憑證和簽發CA連續兩年接受獨立稽核。2026年10月14日，也就是Wayne提出報告的三天前，eMudhra為另一張根憑證emSign Root TLS CA – G1發布了一份撤銷清單，其簽章同樣無法通過驗證。

兩種切斷開關

Chrome的第一步之所以快，是因為它鎖定的是金鑰。Chrome維護一份名為CRLSet的封鎖清單，由Google在背景推送到瀏覽器。它在UTC時間19:45上線的更新，封鎖了這6個中繼CA公鑰的指紋。由於封鎖指名的是金鑰，凡是使用這些金鑰的憑證都涵蓋在內，包括偽造者日後可能製作的憑證。Mozilla則透過自家的清單OneCRL，在Firefox中封鎖這些憑證，並在UTC時間22:59完成。OneCRL不需要使用者更新、甚至不必重新啟動Firefox就能生效。

在背景推送的清單，只能保護收得到它的軟體。10月20日，Mozilla為那些因設定而收不到封鎖清單的使用者發布了Firefox更新，之後又針對部分沒有套用清單的Firefox Android版設定檔推出修正。Google在10月19日星期一UTC時間22:00左右，開始透過Google Play服務向Android裝置發送同等的封鎖，並在隔天表示大多數裝置都已收到。微軟和蘋果在幾天內相繼跟進，不過對於蘋果採取行動的確切日期，已公開的說法並不一致。

憑證機構也有所動作。eMudhra在10月18日UTC時間09:38之前，把8張憑證全數標記為已撤銷，撤銷理由註明為CA遭破解。曾為這些中繼CA交叉簽署的Sectigo，在10月19日撤銷完它的交叉憑證。Chrome也安排讓憑證透明度日誌拒收任何連到這些遭破解CA的憑證，如此一來，偽造憑證就再也拿不到檢查CT的軟體所要求的日誌紀錄。

較重的手段，是移除當初授權這些中繼CA的根憑證。10月20日，Mozilla指出這時已有好幾個人各自獨立還原出金鑰，於是決定緊急把emSign ECC Root CA – G3從自家信任儲存區移除；這張eMudhra根憑證，正位於那些出問題的中繼CA之上。Firefox其實不需要這項措施，因為OneCRL已經保護了Firefox。這是為了其他所有使用Mozilla根憑證清單、或使用由它衍生的清單，卻沒有OneCRL的人。Mozilla警告，這項變更會讓這些使用者暫時連不上某些伺服器，直到那些伺服器換上新的憑證鏈為止。

Chrome也從自家儲存區移除了同一張根憑證。Google預計，這項變更會在太平洋時間2026年10月27日星期二上午，送達所有仰賴Chrome根憑證儲存區的裝置，在Canary和Beta測試版上則會更早生效。Google直言，有些連到這張根憑證的合法憑證，將因此在Chrome中失效。

這兩種開關的差別，在於能攔下什麼，以及會傷到誰。移除根憑證，會切斷所有經過這張根憑證的路徑，連誠實網站的路徑也一併切斷，卻漏掉經由其他根憑證的路徑，而eMudhra的中繼CA恰好還有另一條。Sectigo曾為它們交叉認證，把同樣的金鑰連到一張名為AAA Certificate Services、以Comodo名義簽發的根憑證。Chrome已在2025年4月拿掉這張根憑證，但有些系統仍然信任它：Ubuntu從所有仍受支援的版本中移除了emSign ECC Root CA – G3，並在仍帶有Comodo根憑證的舊版本中，把它也一併移除。直接針對中繼CA本身的封鎖，則能一次攔下所有路徑。Go程式語言採取的就是這種做法：從10月19日發布的版本起，Go的憑證檢查程式會濾掉任何含有這些遭破解中繼CA之一的憑證鏈，不論它最終連到哪張根憑證。

其他人的更新

10月18日，Mozilla在公開bug頁面上寫道，它擔心更廣泛的生態系，因為許多端點根本沒有有效的方式接收撤銷資訊。瀏覽器有自己的背景清單。許多其他建立安全連線的軟體，則完全沒有類似的機制。

Mozilla的Dennis Jackson架設了一個公開的事件追蹤網站，把哪些人暴露在風險中講得一清二楚。自帶一套受信任根憑證的應用程式和函式庫，都需要軟體更新。以Electron打造的應用程式也一樣。Electron是Slack、Discord等桌面程式背後的框架，這些程式必須以修補過的版本重新建置，才會取得Electron的修正。

有些缺口出在作業系統自己的信任檔案裡。截至10月22日，事件網站指出，macOS已封鎖遭破解的中繼CA，但它內建的命令列工具，包括curl、git和python3，是依據另一個檔案檢查憑證，不會查詢撤銷狀態，而那個檔案並未更新。在Ubuntu上，Java的信任儲存區在系統更新後還需要手動處理，原因是一個同步問題，Canonical到10月22日仍未解決；以snap套件安裝的瀏覽器，則根本不使用系統的信任儲存區。

另一些缺口出在自帶清單的函式庫裡。Go以安全性版本1.27.3和1.26.10推出修正，編號為CVE-2026-111943。Python廣泛使用的certifi憑證包，在10月18日移除了全部4張emSign根憑證，接著在標記為2026.10.19的版本中，恢復了未受影響的3張；10月23日的一次自動發布，又把這3張中的兩張拿掉了。還有些產品只能由製造商修補：思科的Talos資安團隊特別點名，虛擬私人網路（VPN）很可能需要更新。

這一切的底層是憑證透明度。多數瀏覽器都強制執行，但許多非瀏覽器的用戶端，包括curl，並沒有。一張用eMudhra金鑰偽造、從未登錄日誌的憑證，會被Chrome拒絕，卻可能被這些用戶端接受，只要它們仍然信任eMudhra的憑證鏈，而且沒有其他機制擋下，例如只接受自家伺服器已知憑證的應用程式。

有充分的理由可以說，這套系統發揮了作用。在Chrome於10月17日封鎖之前，沒有任何連到這6個中繼CA的網站憑證被登錄到憑證透明度日誌，因此從2025年4月金鑰建立到那次封鎖之間，用這些金鑰偽造的憑證，都不可能拿來對付強制執行CT的用戶端。Talos表示，截至10月21日UTC時間14:00，它沒有在真實環境中看到任何惡意使用。eMudhra說，受影響的中繼CA中只有一個曾經投入正式營運，而且沒有一個曾向網站或軟體開發商簽發過憑證。

對於始終強制執行CT的軟體來說，這個論點沒錯，而且保護來自一條常設規則，而不是那個週末的緊急應變。只是它涵蓋的範圍，比「系統發揮了作用」這句話給人的印象要窄。Firefox Android版直到第145版才開始強制執行憑證透明度，這個版本在2025年11月11日首度提供給使用者。Android應用程式要到Android 16才能使用內建的CT檢查，而且只有針對Android 17建置時才會預設啟用。

這場緊急應變，對後來的局面也很重要。Mozilla最初發給信任儲存區下游維護者的通知，刻意沒有提到任何人都能還原這些金鑰。到了10月20日，這點已經不太要緊：好幾個人已各自獨立還原出金鑰，Helme也公布了全部8個數值。金鑰一旦形同公開，能防止有人用它們偽造新憑證的，就是那些封鎖措施和CT日誌的拒收。截至10月24日，已公開的資訊都無法看出，攻擊者是否曾在2025年4月到2026年10月之間，用這些有缺陷的金鑰對付不檢查CT的用戶端。

開關握在誰手裡

瀏覽器和作業系統要信任哪些根憑證，由根憑證計畫決定，而這些計畫的規則給了經營者很大的空間。Chrome的政策寫道，Google「全權自行決定」納入或移除憑證，而每張納入的憑證為使用者帶來的價值，都必須超過保留它的風險。Mozilla的政策則說，它可以全權自行決定，隨時以任何理由停用或移除一張憑證。Mozilla也表示，它不收取任何納入費用。

這種裁量權，曾以不同的方式行使。2014年，印度國家資訊中心（National Informatics Centre）為數個Google網域簽發了未經授權的憑證，Chrome並沒有因此剔除它上層的India CCA根憑證，而是把這張根憑證限定只能用於一份印度網域清單。再往前推三年，對一家荷蘭憑證機構的回應則是全面封殺：2011年9月3日，Google決定拒絕DigiNotar營運的所有憑證機構；17天後，荷蘭一家法院宣告該公司破產。

DigiNotar，2011年

DigiNotar遭入侵一事，是透過一名普通使用者曝光的。2011年8月28日，伊朗網路服務供應商ParsOnline的一名客戶在Google支援論壇上發文，提到Chrome向他顯示的一則憑證警告。那張憑證聲稱屬於Google，來自DigiNotar，而DigiNotar的系統已經遭人入侵。受荷蘭政府委託的資安公司Fox-IT，其調查人員後來發現，一張涵蓋google.com網址的冒牌憑證，被用在一場大規模攻擊中，波及約30萬名使用者，幾乎全在伊朗，他們的Google流量很可能遭到攔截或重新導向。調查人員是根據查詢過這張偽造憑證狀態的298,140個不同網際網路位址推算出這個數字，並稱之為非常粗略的估計。9月3日，荷蘭政府公開撤回對DigiNotar的信任。截至2026年10月底，還沒有任何利用eMudhra金鑰的攻擊被通報。DigiNotar讓人看到，CA的簽署權落入願意動用它的人手裡，會發生什麼事。

Google寫道，要列入Chrome的根憑證儲存區，CA經營者必須持續證明自己具備保護Chrome使用者所需的技術能力與營運上的嚴謹；它還表示，正在「密切調查」eMudhra其餘的CA憑證是否應該保留。10月23日，eMudhra在公開bug頁面上表示，社群媒體的密集檢視，加上投資人與客戶的分析，讓有意義的事件分析變得「幾乎不可能」。Chrome當天就回覆，這不是藉口，eMudhra仍對仰賴這套系統的「數十億」人負有義務，而這些人正是因它的錯誤而暴露在風險之中。

eMudhra董事會早在10月22日就已決定退出全球SSL/TLS憑證業務。該公司表示，這項業務在其營運中只占很小一部分。

同樣這幾家公司，也與CA一起在一個名為CA/瀏覽器論壇（CA/Browser Forum）的組織裡制定共同規則。在一場2025年4月11日截止的投票中（距eMudhra產生那些有缺陷的金鑰還有19天），蘋果、Google、微軟和Mozilla全都投票贊成縮短網站憑證的效期，另有25家憑證簽發者投下贊成票，eMudhra也在其中。這項提案的理由是，在網際網路的規模下，撤銷無法充分保護使用者，到期失效則可以。提案寫道：「憑證有效期，以及信賴方對它的強制執行，可靠得驚人。」依照2026年10月時的現行規則，2026年3月15日起簽發的網站憑證，效期最長200天；2027年3月15日起為100天；2029年3月15日起則為47天。

這些上限適用於網站使用的憑證，並依簽發日期計算。規則條文並未對這起事件核心的CA憑證設定效期上限，所以就算效期縮短，eMudhra的中繼CA也不會因此到期。撤銷機制也沒有消失。免費憑證機構Let’s Encrypt在2025年8月關閉了它的OCSP服務。這項服務讓瀏覽器一次查詢一張憑證；之所以關閉，是因為每一次查詢都會讓CA知道哪個網際網路位址正在造訪哪個網站。10月17日的那些緊急封鎖，實際上就是由瀏覽器廠商自行整理並推送的撤銷清單。

這種安排把大量權力交到少數私人手中，而且其中多數是美國公司。eMudhra一案顯示的，是這種權力如何行使：在一個任何人都能讀到提問、期限與回覆的公開bug頁面上，由執行移除的公司公布理由。

得搬家的憑證

移除一張根憑證，宣布起來很快，消化起來很慢。截至10月21日，Chrome統計出約3.08萬張連到emSign ECC Root CA – G3、尚未到期的預憑證（precertificate）。預憑證是憑證在簽發前提交給透明度日誌的副本，所以這個數字算的是已登錄的憑證，而不是仍在使用它們的網站。其中30,791張，也就是99.9%，來自InCommon旗下的兩個中繼CA；InCommon是美國網路組織Internet2經營的憑證服務。這兩個中繼CA不在出問題的8個之列，只是剛好掛在那張要被移除的根憑證底下。eMudhra估計約有3萬張憑證需要搬遷，幾乎全都是透過ACME簽發的；ACME是讓伺服器自動申請和更新憑證的協定。eMudhra在10月20日停止以G3根憑證簽發憑證。

自動化本身解決不了這個問題。標準的ACME用戶端只會在憑證的續期日到來時才更換憑證，除非用戶端支援一項較新的擴充功能，讓CA可以要求提前續期，或者有人手動介入。Chrome在10月21日指出，從eMudhra的橢圓曲線憑證階層轉到它的RSA階層，可能還得修改用戶端的設定。

InCommon的憑證來自CertiNext，這家供應商的母公司正是eMudhra。10月22日，InCommon告訴訂戶，許多人在春夏兩季完成了一次成功卻令人心力交瘁的遷移之後，這一週又忙著處理憑證錯誤，並為自己無法掌控的變化重新規劃。它當天上午的建議是，在橢圓曲線憑證恢復簽發之前，先把受影響的憑證改以RSA重新簽發。

eMudhra在10月20日表示，G3客戶唯一的替代方案，是連到其RSA根憑證emSign Root CA – G1的中繼CA。Mozilla同一天表示，現階段不會撤除對G1的信任。G1是Chrome在10月20日表示正在密切調查的eMudhra其餘憑證之一；截至10月24日，Chrome尚未宣布任何決定。10月21日，Chrome要求eMudhra確認，客戶究竟是被移轉到G1、另一家公司的憑證階層，還是兩者都有。

InCommon在10月22日晚間的更新，處理了眼前的問題。橢圓曲線憑證已恢復簽發，如今連到G1根憑證，現有的用戶端無須更改任何設定就能續期。同一份更新也說，eMudhra將在30天後停止從任何連到其公開根憑證的中繼CA簽發憑證，確切日期由CertiNext確認；InCommon則正在研擬替代路徑。對那些才在春夏兩季熬過一次心力交瘁遷移的訂戶來說，移除一張根憑證，又開啟了另一次遷移。

相關文章

• 美國制裁名單的手，能伸進海牙的法院多深？
• 比特幣，下一步往哪走？
• AI到底怎麼運作：開發者知道、頭條卻沒說的事

延伸閱讀

Eikleaf參與亞馬遜聯盟計畫（Amazon Associates），可透過符合計畫條件的購買獲得佣金。下方標示Amazon的書籍連結為聯盟行銷連結；若您透過這些連結購買商品，我們可能獲得少量佣金，您無須額外付費。標示博客來的連結則非聯盟行銷連結。

推薦影片

生成式AI使用聲明

本頁部分內容使用生成式AI協助撰寫或編輯。

圖片與媒體來源

網址列中的HTTPS與鎖頭圖示 – Wikimedia Commons（攝影：Santeri Viinamäki，CC BY-SA 4.0）

nCipher nShield F3硬體安全模組 – Wikimedia Commons（攝影：Alexander Klink，CC BY 3.0）

Googleplex總部 – Wikimedia Commons（攝影：Asoundd，CC BY-SA 4.0）

主要資料來源與參考文獻

Mozilla Bugzilla. “Bug 2083449: eMudhra: Private key compromise of Intermediate Certificates.” Opened 18 October 2026, comments to 23 October 2026. https://bugzilla.mozilla.org/show_bug.cgi?id=2083449

Chrome and Android Security Teams. “Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates.” Google, The Keyword, 20 October 2026. https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/

Mozilla dev-security-policy mailing list. “Compromised eMudhra Intermediate Certificates” thread, posts by Dennis Jackson (Mozilla) and the Chrome Root Program, 20 October 2026, and by Wayne and Corey Bonnell, 21 October 2026. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE

Jackson, Dennis. “eMudhra Intermediate CA Compromise.” Incident tracking site, 20 October 2026, updated 22 October 2026. https://emudhra.we-have-a-problem.com/

InCommon (Internet2). “Moving Forward Together: InCommon Certificate Service Update.” Updates of 22 October 2026. https://incommon.org/about/news/incommon-certificate-service-update

InCommon (Internet2). “InCommon Certificate Service FAQ.” Last updated 22 October 2026, 18:30 ET. https://incommon.org/certificates

Stanescu, Luci. “eMudhra CA compromise fixes available.” Ubuntu blog, Canonical, 20 October 2026, updated 22 October 2026. https://ubuntu.com/blog/emudhra-ca-compromise-fixes-available

Canonical. “USN-8944-1: ca-certificates update” and “USN-8944-2: ca-certificates update.” Ubuntu security notices, 20 October 2026. https://ubuntu.com/security/notices/USN-8944-1 and https://ubuntu.com/security/notices/USN-8944-2

Go team. “[security] Go 1.27.3 and Go 1.26.10 are released.” golang-announce, posted 20 October 2026 (releases dated 19 October 2026). https://groups.google.com/g/golang-announce/c/66pojueaQek

Go project. “Release History.” Accessed 24 October 2026. https://go.dev/doc/devel/release

certifi. “Remove emsign (#437),” “Restore unaffected emSign roots (#439) (#440)” and “2026.10.23 (#445).” python-certifi repository, 18, 20 and 23 October 2026. https://github.com/certifi/python-certifi/commit/5cb238caeeb6c30ec1a7309ad3e16a5aa7b10ce8 and https://github.com/certifi/python-certifi/commit/662df63d7906df66f1f07c0751a3dfe9da14d914 and https://github.com/certifi/python-certifi/commit/b60466c9f2882d9cf088943c650b0faac06c080c

Cisco Talos. “Compromised eMudhra intermediate certificates.” Talos Intelligence blog, 21 October 2026. https://blog.talosintelligence.com/compromised-intermediate-certificates/

eMudhra Limited. “eMudhra Statement on distrust of select Global TLS Intermediate and one Root CA.” 21 October 2026. https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca

eMudhra Limited. “eMudhra to exit global SSL/TLS certificate business.” 22 October 2026. https://emudhra.com/en/press-release/emudhra-to-exit-global-ssl-tls-certificate-business

Abrams, Lawrence. “Mozilla, Google, Apple block compromised eMudhra CA certificates.” BleepingComputer, 20 October 2026. https://www.bleepingcomputer.com/news/security/mozilla-google-apple-block-compromised-emudhra-ca-certificates/

Helme, Scott. “Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds.” 20 October 2026. https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/

Sharwood, Simon. “Indian certification authority eMudhra’s private keys compromised – one of them was the number ‘4’.” The Register, 20 October 2026. https://www.theregister.com/a/5304312

Mozilla Bugzilla. “Bug 1970728: eMudhra: Invalid CRL signatures.” June 2025. https://bugzilla.mozilla.org/show_bug.cgi?id=1970728

Mozilla. “Firefox for Android 145.0 release notes.” 11 November 2025. https://www.firefox.com/en-US/firefox/android/145.0/releasenotes/

Cooper, D., et al. “RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.” IETF, May 2008. https://www.rfc-editor.org/rfc/rfc5280

Laurie, B., Langley, A., and Kasper, E. “RFC 6962: Certificate Transparency.” IETF, June 2013. https://www.rfc-editor.org/rfc/rfc6962

CA/Browser Forum. “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, Version 2.3.1.” 4 October 2026, sections 3.2.2.4.7, 6.1.1.1 and 6.3.2. https://github.com/cabforum/servercert/blob/3574ae809e5f909b58ee4c26b7bac4a3b9e78421/docs/BR.md

CA/Browser Forum. “Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods.” 11 April 2025. https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/

Google. “Chrome Root Program Policy, Version 1.8.” Last updated 5 February 2026. https://googlechrome.github.io/chromerootprogram/crp/policy/

Mozilla. “Mozilla Root Store Policy, Version 3.1.” Effective 1 July 2026. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

Aas, Josh. “OCSP Service Has Reached End of Life.” Let’s Encrypt, 6 August 2025. https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-end-of-life/

Adrian, David, Serena Chen, Joe DeBlasio, Emily Stark and Emanuel von Zezschwitz. “An update on the lock icon.” Chromium Blog, May 2023. https://blog.chromium.org/2023/05/an-update-on-lock-icon.html

von Zezschwitz, Emanuel, Emily Margarete Stark and Serena Chen. “‘It builds trust with the customers’ – Exploring User Perceptions of the Padlock Icon in Browser UI.” SecWeb 2022, IEEE. https://research.google/pubs/it-builds-trust-with-the-customers-exploring-user-perceptions-of-the-padlock-icon-in-browser-ui/

Android Developers. “Network security configuration: Certificate transparency.” Accessed 24 October 2026. https://developer.android.com/privacy-and-security/security-config

Langley, Adam. “Maintaining digital certificate security.” Google Online Security Blog, July 2014. https://security.googleblog.com/2014/07/maintaining-digital-certificate-security.html

Adkins, Heather. “An update on attempted man-in-the-middle attacks.” Google Online Security Blog, 29 August 2011, updated 3 September 2011. https://security.googleblog.com/2011/08/update-on-attempted-man-in-middle.html

Fox-IT. “Black Tulip: Report of the investigation into the DigiNotar Certificate Authority breach.” 13 August 2012. https://zoek.officielebekendmakingen.nl/blg-191225.pdf