jt-ipam 憑證派送：自動更換站台憑證並確認生效

Jason Cheng 發布 2026.11.04 瀏覽 3 次

IP 位址管理 jt-ipam Linux Windows 加密連線系統管理網路裝置管理資訊安全防火牆開源軟體

本文目錄

功能概要
系統需求
憑證的匯入
集中保管與檢視
派送代理
推送到防火牆
通知與追蹤
重新簽發時的處理步驟
安全設計
適用範圍與限制
結論
參考資料

你有沒有遇過，憑證明明換了、服務也重新載入了，連上去看到的卻還是舊憑證？

換一張 TLS 憑證，真正花時間的不是申請，而是之後的工作：先查出這張憑證裝在哪些機器上，再一台一台登入換檔、補中繼憑證、重新啟動服務，最後開瀏覽器確認。網站、郵件、VPN、防火牆、虛擬化平台的管理介面各有各的格式與路徑，PEM、PFX、合併檔混在一起，中繼憑證放錯或少放，服務就會出現憑證錯誤。

到期更新是定期的工作，而且公開信任的網站憑證有效期越來越短（2026/3/15 起簽發的最長 200 天）；CA 要求重新簽發、更換中繼憑證時，則要在很短的期限內全部換完。這時最常遇到三個問題：不知道有哪些要換、換的步驟多容易出錯、不知道換完了沒有。設定改了、服務也重新啟動了，服務實際送出去的是不是新憑證，只能一台一台連過去看。

jt-ipam 的「憑證派送」就是為了省下這些工作：憑證集中放在 jt-ipam，換上的工作交給主機上的派送代理或防火牆的管理 API，換上後實際連線確認，不對就換回原本的（有支援連線確認的服務），每台主機的結果都回報到同一個畫面。這篇以 v1.0.19 的示範畫面介紹整個流程。

功能概要

憑證派送分成三段：憑證放進 jt-ipam、集中保管，再由派送代理或推送到防火牆換上，最後確認與回報。

憑證派送的流程：憑證放進 jt-ipam、集中保管、派送代理或推送到防火牆換上、確認與回報

文中標示 v1.0.19 的功能（沿用私鑰、匯入 PFX、依簽發者篩選、換上後的連線確認、派送失敗通知）是這一版新增的。截圖都是示範環境的虛構資料，網域是 example.net，位址屬於文件保留網段；畫面是正式發佈前的開發版，左上角的版本號顯示為 v1.0.18。

系統需求

jt-ipam
憑證、派送代理、推送目標的管理限系統管理員，在「管理 > 憑證派送」；唯讀的現況頁在「進階 > 憑證派送」，有萬用讀取權限就能看
Linux 派送代理
Debian 11/12/13、Ubuntu 22.04/24.04/26.04、RHEL/Rocky/AlmaLinux/CentOS 8/9、Fedora 38 以上、openSUSE Leap/SLES 15 以上，以 root 執行，需要 curl（畫面的一行安裝指令本身就用 curl 下載安裝程式，所以要先裝好）；換上後的連線確認優先用 openssl，沒有時改用 curl 7.88 以上（TLS 後端要支援讀出對方憑證，可用 curl -V 確認），STARTTLS 一定要有 openssl
Windows 派送代理
支援 Windows Server 2019 以上，Windows PowerShell 5.1、以系統管理員執行，不需要安裝任何模組；目前實機驗證過的是 Windows 11 Pro 加 IIS 10
推送到防火牆
設備的管理 API 要開，並另外建一組只用來換憑證的帳號：FortiGate（REST API 權杖）、OPNsense 24.7 以上（API key/secret，Trust API 是 24.7 起才有）、Palo Alto（XML API 金鑰）、pfSense（要安裝 pfSense-pkg-RESTAPI v2）

憑證的匯入

憑證清單列出每張憑證的網域、簽發者、到期日與剩餘天數、版本數，以及有沒有設定自動抓取。剩餘天數依門檻上色，過期的是紅色。

上傳檔案或貼上 PEM

憑證、私鑰、中繼憑證分開上傳或貼上。已經有版本的憑證，上傳新版時私鑰可以留空（v1.0.19），系統會沿用目前版本的私鑰，並檢查新憑證與私鑰是否成對；不成對時會明確寫出「簽發時換了金鑰」。CA 重新簽發或續約沒有換金鑰時，只要上傳新憑證與中繼憑證即可。第一次建立的憑證仍然要附私鑰。

匯入 PFX/P12

Windows 匯出的憑證、廠商提供的憑證多半是 PFX 檔，v1.0.19 起可以直接上傳，系統會取出憑證、私鑰與中繼憑證。PFX 密碼只用來開檔，不儲存，也不寫進稽核記錄。PFX 裡沒有私鑰時，同樣沿用目前版本的私鑰。

自動抓取

ACME 主機自動續約後，憑證多半放在固定路徑。設定 URL 或 SFTP 來源後，jt-ipam 預設每 24 小時去抓一次（可設定 5 分鐘到 30 天），指紋變了才存成新版本。SFTP 第一次連線成功時會記住主機金鑰，之後金鑰不同就拒絕連線。登入可以用密碼或 SSH 金鑰，也可以由 jt-ipam 產生金鑰並安裝到 SFTP 主機。

另外也可以直接在 jt-ipam 產生自簽憑證，給內部服務或測試環境使用，到期前一鍵續簽（續簽會產生新的私鑰）。

集中保管與檢視

私鑰以 AES-GCM 加密存放。每次更新都產生一個新版本，看得到每個版本的簽發者、序號、有效期、指紋，以及憑證鏈是否完整；缺中繼憑證或根憑證時，如果 jt-ipam 伺服器的系統信任庫裡有對應的簽發者憑證，可以一鍵組成完整的鏈；信任庫裡沒有的中繼憑證，仍要自己上傳。

同一張萬用憑證的兩個版本：版本 1 由舊中繼憑證簽發，版本 2 由新中繼憑證重新簽發

下載可以選 fullchain、cert、chain、key、合併檔、DER 與 PFX，含私鑰的格式每次下載都會寫入稽核記錄。

依簽發者篩選

CA 要求重新簽發時，第一個問題是「我們有哪些憑證是這家簽的」。v1.0.19 的憑證清單多了簽發者欄與下拉篩選，選單依簽發單位列出各有幾張，自簽的列為「自簽」。

文字篩選也會比對簽發者。示範環境的新舊中繼憑證名稱只差在年份，輸入舊中繼憑證名稱裡的年份，就能找出還沒換的憑證；實務上中繼憑證的命名方式依 CA 而定，請以 CA 公告的完整名稱核對。

到期通知

到期通知天數有全域預設值（預設 21 天，可設 1 到 365 天），每張憑證也可以另外設定。人工申請的商用憑證可以提早一個月通知，自動續約的提早一週就夠。

派送代理

派送代理裝在要使用憑證的主機上，由代理主動向 jt-ipam 詢問有沒有新版本，有就下載、換上、回報。jt-ipam 不需要連進主機，主機也不用開任何連接埠。

排程方面，Linux 代理用 systemd timer，每天 00:00 執行；Windows 代理用工作排程器，每天 03:30 執行。兩者都會隨機延遲最多 10 分鐘，時間都可以修改。急的時候可以在主機上手動執行一次。

建立代理

每台主機建立一個代理，並勾選它可以取得哪些憑證。沒有勾選的憑證，代理一張都拿不到。建立後畫面會顯示代理金鑰與一行安裝指令；金鑰之後也可以在清單按「檢視」再取得，每次檢視都會寫入稽核記錄。

多台主機共用同一把金鑰雖然能運作，但清單只會顯示最後回報的那一台。7 天內有不同來源 IP 使用同一把金鑰時，清單會在來源 IP 旁標示警告。

要注意的是，畫面產生的安裝指令預設不驗證 jt-ipam 的憑證（curl -k 與 JT_IPAM_INSECURE=1），這是為了讓使用自簽憑證的 jt-ipam 也能安裝。這兩個參數等於不驗證下載來源，安裝程式又是以 root 執行，被中間人攻擊時可能執行到被換掉的程式，之後代理取得私鑰的連線也一樣不驗證。正式環境請讓 jt-ipam 使用 HTTPS 與受信任的憑證（或先讓主機信任內部 CA），再把這兩個參數拿掉；截圖裡的 http://127.0.0.1 只是本機示範位址。

產生設定檔

代理裝好後，在清單按「產生設定檔」，選擇憑證與服務，畫面會產生三樣東西：要貼到主機 /etc/jt-ipam-cert-agent/config 的設定、憑證會寫到哪些路徑、要貼進服務設定檔的那幾行。

Linux 支援的服務有 nginx、Apache、HAProxy、Caddy、Traefik、lighttpd、Zoraxy、Jetty、Postfix、Dovecot、Exim、Mosquitto、Cockpit、Webmin、Wazuh Dashboard、Proxmox VE、PMG、PBS、PDM、Jitsi、coturn、Zimbra，以及只寫入檔案的 files。以 Proxmox VE 為例，代理會寫入 /etc/pve/local/pveproxy-ssl.pem 並重新啟動 pveproxy，不用再查每種服務的憑證要放哪裡、要重新啟動什麼。

產生設定檔（Linux/nginx）：確認位址、寫入路徑、nginx 設定片段，以及試跑與正式執行的指令

設定好之後先用 --dry-run 試跑，確認不會動到任何檔案，再正式執行一次。

Windows 代理支援 IIS（含 SNI 繫結）、WinRM、RDP，以及匯入憑證存放區的 store；LDAPS 用 store 匯入 NTDS\My，再通知網域控制站重新載入；憑證本身要符合網域控制站的條件（名稱相符、有伺服器驗證用途），而且 LDAPS 沒有連線確認，換完請自己用用戶端連線測試。匯入 IIS、WinRM、RDP、store 時，PFX 只在記憶體中處理，不寫入磁碟。

產生設定檔（Windows/IIS）：匯入 LocalMachine\My，換上 0.0.0.0:443 繫結的憑證

換上的步驟

代理換上憑證時依序做這幾件事：

寫入新檔，舊檔先備份
有設定測試的服務先測試（nginx、Apache、HAProxy、lighttpd，例如 nginx -t），失敗就換回舊檔
reload 服務，失敗就換回舊檔
連過去確認服務送出的是新憑證（v1.0.19），不是的話把檔案換回、再 reload 一次，並確認服務已經回到舊憑證
回報每個服務換成哪一張、確認結果與失敗原因

第 4 步的確認位址依服務而定：

Proxmox VE、PMG、PBS、PDM、Cockpit、Webmin
一個連接埠只送一張憑證，預設確認本機，例如 127.0.0.1:8006
nginx、Apache 這類多站台服務
要在設定填入確認位址才會確認，格式是 主機名稱:埠@連線位址，例如 www.example.net:443@127.0.0.1；不填的話不確認，避免連到別的站台、把換對的憑證誤判後換回
郵件服務
確認位址用 smtp://、imap:// 開頭，以 STARTTLS 確認
Windows IIS
換上繫結後一律確認，不對就綁回原本的憑證

換上之前與之後都連不到確認位址時，結果標示「未確認」，不會換回。

這個確認最有價值的地方，是抓出「設定測試沒問題、reload 也成功，但服務還在送舊憑證」的情況，例如另一個 server 區塊指向別的路徑。滑過清單的「已部署/回報」，就看得到每個服務的狀態與原因：

mail-01 的回報：Postfix 與 Dovecot 都以 STARTTLS 確認過

推送到防火牆

防火牆上沒辦法安裝代理，jt-ipam 改用設備的管理 API 把憑證推過去並換上。這個功能目前標示為 Beta，還沒有在每一家的實機上驗證過，正式使用前請先用測試設備或測試用的憑證試一次。

設備	換上的位置	說明
FortiGate	管理介面、SSL VPN（依 FortiOS 版本與機型是否仍提供）	兩個都換時兩個都確認；SSL VPN 用填寫的確認位址
OPNsense	設備上指定的那張憑證	替換憑證內容、識別碼不變，引用它的設定不用改；中繼憑證先匯入信任庫；預設推完重新啟動網頁管理介面，其他引用它的服務要不要重新載入，請自行確認
Palo Alto	SSL/TLS 服務設定檔	有別人還沒提交的變更就不動；可以只 commit 自己帳號的變更；commit 失敗把候選設定換回
pfSense	網頁管理介面	重新啟動時的斷線不算失敗，改由連線確認

推送時先連一次記下原本的憑證，換上後再連過去確認。推之前連得到、推完卻不是新憑證，就自動換回原本的，並再確認一次；推之前就連不到的位址（例如只開在外網的 SSL VPN）只標示「未確認」，不換回。Palo Alto 與 OPNsense 換的憑證不一定是管理介面在用的那張，要填實際使用這張憑證的服務位址（例如 GlobalProtect 的位址）才會確認，沒填就只標示「未確認」。每次推送的步驟都留有記錄，滑過狀態就看得到：

FortiGate：推之前先連一次、匯入、換上管理介面與 SSL VPN、兩個都確認

Palo Alto：檢查待提交變更、匯入中繼 CA 與憑證、partial commit、連線確認

Palo Alto 也可以關掉自動 commit，只寫進候選設定，狀態顯示「已寫入，待 commit」，由管理員自己 commit。管理員一直沒有 commit 時，jt-ipam 不會提醒，清單會一直停在這個狀態。新增推送目標時，表單會依設備換成對應的欄位：

新增推送目標（Palo Alto）：SSL/TLS 服務設定檔、自動 commit、commit 的管理員帳號與確認位址

「自動推送」預設關閉。開啟後，憑證有新版本（上傳或自動抓取）時，下一輪排程同步就會推送（同步排程每 5 分鐘一輪），失敗隔 1 小時再試。也可以隨時按「立即推送」。要注意 jt-ipam 是用自己記錄的上次推送指紋判斷要不要推，不會讀取設備上實際的憑證，有人直接在設備上改了憑證時，jt-ipam 不會發現。

通知與追蹤

通知事件包括憑證即將到期或已過期、換成新版、沒換成最新版、推送到防火牆失敗、自動抓取失敗，以及派送代理超過 2 天沒有回報。v1.0.19 起，代理換上失敗也會發通知，並附上代理回報的原因；它和「沒換成最新版」在通知設定裡是同一個事件「憑證飄移或派送失敗」，共用一個開關。

每種事件可以分別選擇送到站內通知、Email、Telegram、Slack、Teams、Nextcloud Talk、Zulip 或 Webhook。預設只開站內通知。

「進階 > 憑證派送」的現況頁，一頁列出每台主機、每張憑證、每個服務是不是最新版。這個選單在建立過派送代理之後才會出現。

戰情室的「DNS/DHCP/憑證」主題會顯示已過期與 30 天內到期的憑證張數與到期分布，這一區只有管理員看得到。

建立憑證、上傳新版、下載含私鑰的格式、代理下載、檢視代理金鑰、推送都會寫入稽核記錄。上傳新版的記錄會寫明是 PEM 還是 PFX、私鑰是不是沿用，稽核記錄裡不含私鑰。

重新簽發時的處理步驟

CA 要求重新簽發、所有憑證要在期限內換完時，整個流程如下：

找出要換的憑證
憑證清單依簽發者篩選，或輸入舊中繼憑證名稱裡的年份，找出還沒換的
上傳新憑證
每張憑證按「上傳新版」，只放新憑證與新的中繼憑證，確認原私鑰仍安全、CA 沒有要求換金鑰時，私鑰留空沿用；拿到的是 PFX 就切換到 PFX/P12 上傳
換上
派送代理下一次執行時就會取得新版本，趕時間就在主機上手動執行一次；開了自動推送的防火牆，下一輪排程同步就會推送，也可以按「立即推送」
確認
代理與推送都會連過去確認服務送出的是新憑證，不是就換回原本的
追到全部換完
換上失敗、沒換成最新版的主機會發通知並附上原因；在現況頁看每台的狀態，再用簽發者篩選確認清單裡已經沒有舊中繼憑證簽發的憑證

從前要翻文件查憑證裝在哪裡、一台台登入換檔、用試算表追進度，現在是一份清單、一次上傳，換上與確認交給代理，失敗的主機會主動通知。沒有連線確認的服務（Windows LDAPS、Zimbra）與待 commit 的 Palo Alto，仍要自己追蹤。

安全設計

私鑰
以 AES-GCM 加密存放；派送流程中只在三種情況離開伺服器：交給有權限的代理、管理員下載、推送到防火牆。jt-ipam 的系統備份也包含加密的私鑰與解密用的金鑰，備份檔要一樣小心保管。代理下載與含私鑰的下載逐次寫入稽核記錄，推送到 Palo Alto 時私鑰先以隨機密碼加密再送出
代理權限
代理預設一張憑證都拿不到，要逐張開放
帳密
推送目標與抓取來源的帳密只能寫入、不能讀回，系統只回報有沒有設定
對外連線
URL 抓取與推送有 SSRF 防護；SFTP 主機金鑰在第一次連線後記住（第一次按「測試連線」後畫面會顯示主機金鑰指紋，請先和 SFTP 主機上的指紋核對）；確認時連的是檢查過的那個位址
換上
先備份、先測試；有支援連線確認的服務，換上後實際連線確認，失敗就換回

適用範圍與限制

jt-ipam 不向 CA 申請憑證
沒有內建 ACME，新憑證仍要有人上傳一次，或從 ACME 主機以 URL/SFTP 自動抓取
沒有納管的主機看不到
沒裝代理、也沒設推送目標的主機或設備，jt-ipam 不知道它們用的是哪張憑證
確認不是每種服務都有
nginx、Apache 這類多站台服務要填確認位址才會確認；Windows 的 LDAPS 沒有連線確認
Zimbra
代理改用 Zimbra 的 zmcertmgr 驗證、部署並重新啟動服務，沒有自動換回，也沒有連線確認；重新啟動失敗時回報的仍是成功，訊息寫「manual restart needed」，要自己看回報內容
推送到防火牆是 Beta
正式使用前請先用測試設備試一次
代理每天執行一次
急的時候請在主機上手動執行