SHA-1 憑證雜湊是憑證確切位元組序列的 160 位元 SHA-1 訊息摘要，顯示為 40 個小寫十六進位字元。因為 SHA-1 雜湊產生器在瀏覽器中執行，並對檔案的原始位元組進行雜湊處理而不上傳，所以你可以將其指向匯出的憑證（.cer、.crt、.pem、.der），並讀取與 Android Studio、OpenSSL 或 Java 的 keytool 會列印的相同 40 字元指紋。訣竅是使用檔案模式而非文字模式，因為憑證是二進位資料，將其內容貼入 UTF-8 文字欄位會無聲地損毀位元組。一旦計算出摘要，你就會透過受信任的通道（簽署的發行版頁面、開發者入口或頻外驗證）比較每個字元，以確認你收到的檔案與發行者預期的檔案相符。
SHA-1 憑證雜湊實際上是什麼
數位憑證只是二進位資料的一塊——通常是由 X.509 定義的 DER 編碼 ASN.1 結構。無論你將其儲存為帶有 BEGIN/END 標記的 .pem 檔案或原始 .der 檔案，實際進行雜湊處理的位元組都是憑證本體本身。SHA-1 指紋因此是這些確切位元組的確定性函式：位元組相同進入，40 個十六進位字元摘要相同輸出。指紋在開發工作流程中廣泛使用（Android 金鑰庫、程式碼簽署憑證、OAuth 用戶端密碼、TLS 鎖定指令碼），其中你需要一個特定憑證的穩定、緊湊識別碼，而不暴露完整公開金鑰。
SHA-1 由 NIST 安全雜湊標準定義，它填充輸入、將其分成 512 位元塊，並為每個塊執行八十輪混合以產生 160 位元狀態（請參閱NIST FIPS 180-4）。對於 X.509 憑證，輸入只是你指向的檔案中的任何位元組——無標頭、無中繼資料、無修改時間戳記、無 MIME 標籤。產生器傳回的 40 字元十六進位字串包含與 OpenSSL 等工具為憑證計算的相同 SHA-1 摘要位元組，因此可以與現有驗證指令碼中使用的基礎指紋值進行比較。
使用 SHA-1 產生器對憑證檔案進行雜湊
- 在瀏覽器中開啟SHA-1 雜湊產生器。該頁面完全在標籤中執行，永遠不會上傳你選擇的檔案。
- 將你要指紋化的憑證匯出為磁碟上的檔案。PEM 和 DER 都可以；產生器對原始位元組進行雜湊處理，因此磁碟上的副檔名無關緊要。如果憑證位於金鑰庫（.p12 / .pfx / .jks）內，請先使用你平台的工具匯出憑證——金鑰庫容器的 SHA-1 與其內部憑證的 SHA-1不同。
- 將輸入模式切換為「檔案」而非「文字」。憑證是二進位；將其貼入 UTF-8 文字欄位會無聲地損毀它並產生無意義的指紋。
- 點擊檔案選擇器並選擇憑證檔案。100 MB 限制適用於整個檔案，遠高於任何實際憑證大小（大多數遠小於 10 KB）。
- 觸發摘要計算。該頁面透過瀏覽器的檔案 API 讀取位元組，執行標準 FIPS 180-4 SHA-1 壓縮，並以 40 個小寫十六進位字元和 28 個 Base64 字元的形式顯示結果。
- 複製十六進位字串。不要去除任何空格、不要新增換行符，並將其視為確切文字。大多數工具期望小寫。
- 透過受信任的通道將每個字元與憑證擁有者發佈的值進行比較。相符確認你收到的位元組符合預期；不相符表示檔案在傳輸中被修改或你正在查看錯誤的檔案。
十六進位或 Base64：選擇憑證工具需要的格式
相同的 20 位元組摘要可以用兩種方式編寫：40 個小寫十六進位字元或 28 個 Base64 字元（根據標準 RFC 4648 的 27 個資料字元加 1 個填充字元）。Android Studio 的 gradle signingReport、Facebook 的 Android 金鑰雜湊欄位和大多數 OpenSSL 命令輸出都需要十六進位形式。某些網路 API 和舊版憑證鎖定庫只接受 Base64 形式，少數整合接受任何一種只要長度正確。
如果文檔沒有說明，預設使用十六進位——40 個小寫字元，沒有空格，沒有冒號。如果你要將摘要餵入已顯示帶冒號的樣本的工具（Windows 憑證管理器中的常見慣例），在比較前去除它們。位元組相同；只有可列印編碼不同。
比較憑證雜湊時的常見陷阱
- 對錯誤的檔案進行雜湊。金鑰庫的指紋不是其內部憑證的指紋。對你打算使用的憑證進行雜湊，而不是其容器。
- 在雜湊前解碼 PEM。只有原始位元組重要。去除 BEGIN/END 標記並對 PEM 本體進行 Base64 解碼會產生不同的位元組和不同的摘要。要麼對整個 .pem 檔案進行雜湊，要麼先匯出為 .der。
- 當一側是大寫時不分大小寫地比較。十六進位數字 0–9 和 a–f 在值中不分大小寫，但尾隨空格、BOM 和漂移冒號則不同。將列印的指紋視為確切文字。
- 對重新儲存的副本進行雜湊。如果你在文字編輯器中開啟憑證並重新儲存，行尾可能已變更。指紋將與原始檔案不相符。使用原始檔案。
- 混淆 SHA-1 和 SHA-256。Google 的 Play Console、現代 OAuth 提供者和目前的 Android 簽署報告現在發佈 SHA-256 摘要（64 個十六進位字元）。同一憑證的 SHA-1 和 SHA-256 指紋是完全無關的值。
為什麼舊版系統仍然發佈 SHA-1 憑證摘要
SHA-1 是碰撞破裂——攻擊者可以在現實條件下使用相同摘要構建不同內容，如RFC 6194 的安全考慮所述。因此 SHA-1 相符不是作者身份的證明，絕不能用於新簽署方案、密碼儲存、憑證發行決策或竄改保護。憑證的 SHA-1 指紋之所以可接受，僅因為它充當緊湊識別碼：你確認「這是我之前下載的相同檔案」，而不是「此憑證由某人信任的人簽發」。
對於新的整合，偏好 SHA-256 或更強的。SHA-256 雜湊產生器計算相同憑證檔案的標準 256 位元摘要，並傳回 Google Play 應用簽署、現代 OAuth 流程和目前 TLS 鎖定工具期望的 64 字元十六進位字串。如果你控制憑證發佈者，並肩發佈 SHA-256 指紋（或改為發佈），並隨時間遷移使用者。
SHA-1 vs SHA-256 vs SHA-512：快速參考
| 屬性 | SHA-1 | SHA-256 | SHA-512 |
|---|---|---|---|
| 摘要大小（位元） | 160 | 256 | 512 |
| 十六進位字元 | 40 | 64 | 128 |
| Base64 字元 | 28（含 =） | 44（含 =） | 88（含 ==） |
| 塊大小（位元） | 512 | 512 | 1024 |
| 每塊輪數 | 80 | 64 | 80 |
| 碰撞狀態 | 破裂 | 安全 | 安全 |
| 標準 | FIPS 180-4 | FIPS 180-4 | FIPS 180-4 |
十六進位長度由演算法固定——聲稱輸出 SHA-1 的每個實作都必須為相同輸入位元組產生恰好 40 個小寫十六進位字元，這就是為什麼缺少或額外字元立即告訴你檔案錯誤、編碼錯誤或演算法錯誤。
值得記住的限制和邊界案例
基於瀏覽器的產生器接受最多 100 MB 的憑證檔案；真實 X.509 憑證舒適地放在 10 KB 以內，因此限制本質上是透明的。它只在單個標籤中工作，在摘要操作完成前將檔案處理為一個位元組緩衝區——它不是用於多 GB 成品的串流命令行替代品。對於非常大的套件，使用此工具個別對每個憑證進行雜湊，並根據其發佈的參考驗證每個指紋。
空輸入是有效訊息，具有眾所周知的 SHA-1 值 da39a3ee5e6b4b0d3255bfef95601890afd80709；以空文字欄位點擊計算按鈕仍然產生此常數。這很少是你對憑證想要的，與空輸入常數相符的指紋幾乎總是意味著載入了錯誤的檔案或檔案選擇器未觸發。
如果你在權衡選項，在 JavaScript 中產生 SHA-256 雜湊：Web Crypto 和工具詳細涵蓋了這一點。
如果你在權衡選項，如何從文字或檔案建立 SHA-512 雜湊詳細涵蓋了這一點。