憑證與金鑰配對器

放入任意組合的憑證、私密金鑰和 CSR——PEM 或 DER——這個工作台會證明哪把金鑰與哪份憑證配對，把憑證排成鏈，轉換格式並產生 CSR。私密金鑰從不離開你的瀏覽器：一切都在這個分頁中本機解析，金鑰只保存在記憶體中，從不上傳、記錄或儲存，本頁面不發出任何網路請求。如需深入解碼一份憑證，請使用SSL 憑證解析器；如需快速產生自簽章憑證，請使用自簽章憑證產生器。

新增憑證、金鑰和 CSR

配對結論

新增一份憑證和一把私密金鑰，結論就會出現在這裡：哪把金鑰與哪份憑證配對——由相同的公開金鑰證明，絕不靠檔案名稱猜測。

鏈建構器

載入兩份或更多憑證後，建構器會按發行者與主體名稱的配對把它們排序：葉子在前，然後是中間憑證，最後是根——然後，在瀏覽器的密碼學能力允許時，它會驗證每一環上的實際簽章，而不是只信任名稱。

產生 CSR

為在這裡、你的瀏覽器中產生的金鑰製作一份憑證簽署請求：填寫主體，選擇金鑰類型，下載 CSR 傳送給你的 CA——外加私密金鑰，私密金鑰必須由你自己妥善保存。金鑰只在這裡顯示；本頁面不會保留它。

配對實際上是如何運作的

憑證和私密金鑰不是一個檔案的兩半；它們是共享同一個數學物件的兩個檔案。產生金鑰對時，公開的一半被放進憑證（以及用該金鑰製作的任何 CSR）中，私密的一半則留在金鑰檔案中。兩個項目恰好在它們攜帶同一把公開金鑰時配對——對 RSA 而言是相同的模數和指數；對 EC 而言是同一條曲線上的同一個點。本頁面把這把公開金鑰編碼進它的標準包裝（SubjectPublicKeyInfo），用 SHA-256 對編碼做雜湊，並按該雜湊對每個已載入項目分組。因此每張卡片上顯示的雜湊是證據，而不是摘要：相同的雜湊不可能是巧合，不配對同樣確定，這就是為什麼結論可以直白地說——這把金鑰與這份憑證配對，或者沒有任何已載入的金鑰配對。這一檢查能抓住的經典故障寫在當你的金鑰與憑證不配對時裡：凌晨 2 點的重新載入，磁碟上續好的憑證屬於另一把金鑰，而不是伺服器已載入的那一把。

檔案名稱什麼都證明不了。一個目錄裡滿是 server.crt、server.key、final-v2.pem 和一份去年續簽嘗試留下的 CSR，這是接手來的基礎設施的常態，而這些名稱是考古學，不是文件。相同的副檔名或相同的日期同樣證明不了什麼。那麼傳統的 openssl 檢查呢——比較憑證的模數雜湊與金鑰的模數雜湊？那正是本頁面的檢查，只是它限於 RSA、一次只能查一對，而且完全漏掉 EC 金鑰，因為 EC 金鑰沒有模數。公開金鑰指紋統一涵蓋每種演算法，這就是它在這裡作為分組鍵的原因。

鏈、順序，以及「已驗證」的含義

伺服器應當先出示葉子憑證，然後按順序出示每一份中間憑證，這樣客戶端就能沿發行者到主體的連結一路走到它已經信任的根。以錯誤的順序出示同樣的憑證——或者缺了一份中間憑證——就會產生經典的「unable to get local issuer certificate」系列錯誤，來自那些無法自己取得缺失環節的客戶端。上面的建構器僅從名稱重建順序，這總是做得到的，然後它更進一步：對 RSA 和 ECDSA 簽章，它匯入發行者的公開金鑰並驗證對憑證簽章內容的簽章。標有簽章已驗證的環節是經過密碼學證明的。標有僅名稱配對的環節則不是——名稱能接上，但簽章使用的演算法本平台不驗證（RSA-PSS 是常見情形），頁面會如實說明，而不是把名稱配對包裝成證明。如果簽章驗證失敗，名稱只是巧合或偽造，建構器會用紅色顯示失敗，而不是悄悄產出一個包。

格式：PEM、DER 與 .pfx 問題

PEM 是把 DER 位元組用 Base64 包裝並加上帶標籤的標頭；DER 是原始編碼。兩者之間轉換不損失什麼，也不證明什麼——是同一個物件換了信封——這就是為什麼每張卡片都提供兩種下載。Windows 和一些 Java 工具偏好 DER 或 PKCS#12；大多數 Unix 工具想要 PEM。PKCS#12（.pfx/.p12）是另一回事：它是一個帶自身完整性 MAC 的加密容器，做出一個每個消費者都接受、且保護名副其實的檔案，不是應該在網頁裡手工拼湊的東西。本工具刻意不提供它。要自己打包一對已配對的檔案，就在檔案所在之處執行 openssl：openssl pkcs12 -export -inkey key.pem -in cert.pem -certfile chain.pem -out bundle.pfx——在本頁面告訴你哪把金鑰、哪份憑證和哪條鏈真正配套之後。

解析與組鏈是為本站手寫的 DER 程式碼（BSD 風格，無第三方解析器）；雜湊、簽章驗證和金鑰產生使用瀏覽器的 WebCrypto。本工具的任何部分都不發出網路請求。

常見問題

配對器如何證明一把金鑰和一份憑證配套？

靠比較公開金鑰，而不是檔案。每份憑證、CSR 和私密金鑰都能給出同一份編碼的公開金鑰（SubjectPublicKeyInfo）；本頁面用 SHA-256 對它做雜湊，並把雜湊一致的項目分組。公開金鑰相同意味著這把私密金鑰在數學上就是這份憑證簽發時所用的那一把——與 openssl 用模數比較所做的檢查相同，只是一次對所有檔案進行，且對 EC 金鑰和 RSA 同樣適用。

把真實的私密金鑰載入到網頁裡安全嗎？

在本頁面上是安全的，因為它的建構方式：一切都在你的瀏覽器中本機解析，金鑰只保存在這個分頁的記憶體中，什麼都不上傳、不記錄、不寫入任何儲存，本頁面不發出網路請求。要保持的習慣是：在貼上金鑰之前，先在任何工具上核查這一說法——並且永遠不要把私密金鑰貼到聊天、工單或在遠端處理它的伺服器端「檢查器」中。

鏈建構器中的「僅名稱配對」是什麼意思？

鏈建構器先把每份憑證的發行者名稱與下一份憑證的主體名稱配對來排序，然後嘗試用發行者的公開金鑰驗證實際簽章。當簽章演算法是瀏覽器的 WebCrypto 能驗證的演算法時（實際中是 RSA 和 ECDSA），這一環會被標為「簽章已驗證」，或者驗證失敗時標為「簽章失敗」。其他一切情況——RSA-PSS 是常見情形——會被如實標為「僅名稱配對」：名稱能對上，但本頁面沒有用密碼學證明這一環。

為什麼沒有 PKCS#12（.pfx）匯出？

PKCS#12 檔案把金鑰和憑證包裝在基於口令的加密中，並帶 MAC 完整性——這是一個需要謹慎、經過充分測試的編碼的格式。與其發布一個手工拼湊的版本、可能產出其他軟體拒絕的檔案（或者更糟，保護薄弱的金鑰），本頁面在 PEM 和 DER 之間轉換，把 .pfx 打包留給 openssl：頁面上給出了指令，你可以在金鑰已經所在之處執行它。

本頁面能讀取加密的私密金鑰嗎？

它能識別出一把並如實說明，但不能使用它：加密的（口令保護的）金鑰在解密之前不會暴露其公開金鑰，而配對正是基於公開金鑰。用 openssl 在本機解密一份副本（pkcs8 -topk8 -nocrypt，或 rsa/ec）並載入解密後的副本——在一台你信任的機器上，之後刪除該副本。