CSR（憑證簽署請求）解碼器
貼上 PEM 格式的 CSR（憑證簽署請求），即可在送交憑證機關前，先確認申請中的 CN、SAN、組織名稱與公開金鑰演算法。免費工具，協助您在提交前抓出輸入錯誤。
什麼是 CSR 解碼器
CSR 解碼器是一款免費工具，只要貼上 PEM 格式的 CSR（Certificate Signing Request，憑證簽署請求），就能一次列出申請中的 Subject（CN、組織名稱等）、SAN（主體別名）、公開金鑰演算法與簽章演算法。在送交憑證機關（CA）之前，您可以當場確認輸入內容是否符合預期。
相鄰工具「X.509 憑證解碼器」解析的是已經核發的憑證，而本工具鎖定的是尚未經過 CA 審核、發行前的 CSR 本身。適合用在憑證尚未核發、或是重新產生私鑰前的最終確認。
CSR 解碼器的使用方法
- 貼上 PEM 格式的 CSR 將以「-----BEGIN CERTIFICATE REQUEST-----」開頭的文字整段貼到輸入欄位。
- 也可一次貼上多筆 CSR 同時貼上多筆 CSR 時，系統會依區塊自動逐一偵測。
- 按下「開始解析」 確認偵測到的 CSR 筆數後，按下按鈕即可交由伺服器端解析。
- 查看解析結果 Subject、SAN、公開金鑰演算法等資訊會條列顯示。
用好本工具的小技巧
- 送交前務必確認 CN（Common Name，通用名稱）與 SAN 是否已涵蓋所有預計核發的主機名稱，漏填 SAN 常會導致事後得重新申請憑證。
- 趁這個時機順便檢查公開金鑰演算法是否為 RSA 2048 位元以下，或使用了不建議的 EC 曲線，可避免送審後被 CA 退件。
- 若打算將同一份 CSR 用在多台伺服器，送出前請再次確認 Subject 與 SAN 中的組織名稱、網域是否與實際申請對象一致。
- 本工具只能顯示 CSR 中申請人所填寫的內容，CA 實際核發時採用哪些 SAN，仍以審核結果為準，可能與申請內容不同。
適用情境
送交 CA 前的最終確認
在購買付費 SSL 憑證之前，先確認產生 CSR 時所填的 CN、SAN 是否正確。
驗證內部系統的 CSR 產生流程
即使不熟悉命令列操作，也能以視覺化方式確認用 openssl req 等指令產生的 CSR 內容是否符合預期。
回頭確認過去申請用的 CSR 內容
對於歸檔保存的 CSR 檔案，可在不接觸私鑰的情況下安全地重新檢視其內容。
檢查多網域憑證的 SAN 是否有遺漏
一次為多個主機名稱申請同一張憑證時，可在送出申請前先找出 SAN 是否有遺漏。
用語集
- CSR（憑證簽署請求）
- Certificate Signing Request 的縮寫，是向 CA 申請核發憑證時所提交的資料，內含公開金鑰與 Subject、SAN 等申請資訊。
- CA（憑證機關）
- Certificate Authority 的縮寫，是負責審核 CSR 內容並實際核發 SSL/TLS 憑證的第三方機構。
- CN（通用名稱）
- Common Name 的縮寫，是 Subject 中代表憑證主要對象（主機名稱或服務名稱）的欄位。過去瀏覽器僅檢查 CN，現在則以 SAN 為優先。
- SAN（主體別名）
- Subject Alternative Name 的縮寫，是列出憑證另外適用之主機名稱或 IP 位址的擴充欄位。在 CSR 階段會以「Requested Extensions（請求的擴充）」形式記錄。
- Requested Extensions（請求的擴充）
- 申請人在 CSR 中要求「核發時請一併加入」的擴充屬性，SAN 即屬於此類，但 CA 不一定會照單全收。
- 公開金鑰演算法
- CSR 中所含公開金鑰的產生方式，常見有 RSA、EC（橢圓曲線密碼）等，強度會依金鑰長度與曲線而異。
常見問題
小知識 ― CSR 為什麼會包含「簽章」
仔細觀察 CSR 的內容會發現，在 Subject、公開金鑰資訊之後，還附有簽章演算法與簽章值。這乍看之下有點奇怪：一份用來請求 CA「請證明我的身分」的文件，為什麼自己就先簽了名？答案在於「Proof of Possession（私鑰持有證明）」的概念。申請人會用與 CSR 中所附公開金鑰配對的私鑰，對整份 CSR（Subject、公開金鑰等）進行簽章，藉此向 CA 證明「自己確實持有與這把公開金鑰對應的私鑰」。如果有人擅自拿別人的公開金鑰來產生 CSR，由於沒有對應的私鑰，就無法產生正確的簽章，這個機制因此能有效防止冒名申請。
CSR 這套機制最早是由 RSA 公司在 1986 年制定，屬於公開金鑰密碼標準系列 PKCS（Public-Key Cryptography Standards）中的 PKCS#10。如今 IETF 已將其以 RFC 2986 重新定義，但業界至今仍普遍沿用「PKCS#10」這個稱呼。它在 TLS 憑證的世界裡並不顯眼，卻是整個憑證核發流程不可或缺的起點。
CSR 的 Requested Extensions（請求的擴充）能夠納入 SAN，其實是相對晚近才標準化的做法。CSR 原始標準（PKCS#10）原本只設想 Subject 與 CN 等基本欄位，隨著多網域憑證、萬用字元憑證日益普及，各家 CA 才各自發展出接受 SAN 的方式。目前 openssl 等主流工具已普遍支援以 RFC 2985 所定義的 Extension Request 機制，將 SAN 一併放入 CSR，而本工具正是從這個標準位置（Attributes 內的 extensionRequest 屬性）讀取 SAN 資訊。