自簽章憑證產生器
為內部服務產生一張憑證及其私鑰，無需背誦 openssl 指令：輸入通用名稱，列出憑證必須涵蓋的每個名稱和 IP，選擇效期和金鑰長度，然後下載兩個 PEM 檔案。金鑰在你的瀏覽器中本機產生，從不上傳——本頁面不發出任何網路請求，金鑰在你儲存之前只存在於這個分頁中。
金鑰越長產生越慢：4096 位元在一台普通機器上可能需要一些時間。計算在你的機器上、這個分頁裡完成——讓它開著，等它結束。
自簽章憑證是用來做什麼的
自簽章憑證的發行者和主體是同一個：它為自己作證。這聽起來像缺陷，對公共網路來說確實是——訪客的瀏覽器沒有理由相信一個陌生人的自說自話。但大量 TLS 從不面向公眾：內部儀表板、預備環境、家庭實驗室服務、網路設備的管理介面，以及一個組織內部服務之間的通訊。對這些場景，受眾是你控制的機器，信任問題有不同的答案：你把憑證（或你自己的小型 CA）一次性、慎重地裝進你管理的信任庫。換來的是在自家圍牆內實現加密和身分確認，而公共 CA 永遠不會知道你的內部主機名稱——那些名字本身就是一份你的基礎設施地圖。
從前產生憑證的儀式是一條沒人記得住、人人複製貼上的 openssl 指令，SAN 還要透過設定檔外掛，因為舊版本根本沒有對應的參數。這個頁面存在的意義，是讓憑證的形狀直接可見：名稱是一份你能讀的列表，效期是你明知會到期而選擇的天數，金鑰長度是一個決定，而不是一個你從未注意過的預設值。它刻意不做的，是假裝自己是一個 CA：沒有鏈，沒有中間憑證，也沒有可撤銷的東西。一個服務，一張憑證，一個需要記住的到期日。
讓用戶端接受它
產生憑證是容易的一半；信任才是部署。在你自己的少數幾台機器上，把憑證加進作業系統（或瀏覽器）的信任庫就能一勞永逸地消除警告；curl 和 git 這類工具接受按指令指定的 --cacert 指標，而不是停用驗證這個危險習慣——-k 參數會訓練所有人去忽略那個本該抓住真實攻擊的警告。當受眾超過少數幾台機器，就從單張自簽章憑證升級到一個小型私有 CA：用它簽發服務憑證，只分發 CA 憑證，輪換就不再是逐台用戶端的巡迴。當某個服務最終還是要面向公眾時，把憑證換成公共受信的——SSL 檢查器會核實伺服器上線後實際出示的是什麼，而那正是自簽章不再是一個選項的時刻。
相關工具：用 SSL 憑證解析器把任何憑證讀回來，或用 SSL 檢查器檢查線上伺服器實際出示的憑證。
延伸閱讀：一套可靠性例行工作——為什麼內部憑證及其到期日應該和輪換、備份放在同一張規劃表上。
憑證產生使用 node-forge，依 BSD-3-Clause 授權使用，僅在你按下「產生」時載入。本工具的任何部分都不發出網路請求。
常見問題
自簽章憑證應該用在哪裡？
用在只有你和你自己的系統會存取的東西上：內部儀表板、實驗室和預備環境、家庭實驗室服務、設備管理頁面，以及讓伺服器在真實憑證簽發之前先能啟動起來的佔位符。規則看觸達範圍：如果陌生人的瀏覽器將來會看到它，它就需要一張公共受信憑證——那種憑證可以從 Let's Encrypt 免費取得。
為什麼瀏覽器會對自簽章憑證發出警告？
因為「自簽章」意味著唯一為憑證作證的就是它自己。加密本身是有效的——連線是私密的——但沒有任何東西證明伺服器就是它聲稱的那個身分，而這正是憑證頒發機構通常提供的那一半 TLS。因此瀏覽器會一直警告，直到憑證（或你控制的 CA）被加入使用它的機器的信任庫。
為什麼通用名稱也出現在 SAN 列表裡？
現代瀏覽器完全忽略通用名稱欄位，改為檢查主體別名列表。一張主名稱不在自己 SAN 列表裡的憑證，會在它為之產生的那個名稱上驗證失敗——這是最常見的自簽章錯誤——所以本頁面總是把通用名稱加入 SAN。
2048 位元 RSA 夠用嗎，還是應該選 4096？
2048 位元 RSA 是目前的基線，對內部服務足夠；大多數公共憑證仍在使用它。4096 位元以更慢的產生速度和略慢的交握為代價，換取應對未來密碼分析的餘裕。它適合長期的內部 CA，或一個不容易重新簽發的服務。無論哪種，產生都發生在你自己的機器上——4096 位元可能需要一些時間，分頁是在工作，不是卡住了。
在網頁裡產生私鑰安全嗎？
在這個頁面上安全，原因在於它的建構方式：金鑰對用 node-forge 程式庫在你的瀏覽器中本機產生，頁面不發出任何網路請求，你產生的任何東西都不會被上傳、記錄或儲存。不過這個習慣仍值得保留：只在你信任的頁面（和機器）上產生金鑰，並從私鑰檔案存在的那一刻起就把它當作秘密。