簡介win-acme.v2.1.18-x64 是一款面向 Windows 站點管理員、個人站長與小型項目運維者的免費 SSL 證書自動化工具重點解決 Lets Encrypt 證書申請、安裝與續(xù)訂流程繁瑣的問題。壓縮包共 27 個文件、約 29.58MB包含 15 個 ps1 腳本、4 個 dll 運行庫、2 個 json 配置文件、2 個 bat 批處理文件以及 exe 主程序、xml 配置模板、dat 公共后綴列表和 txt 版本說明等兼顧圖形化操作與命令行腳本自動化。工具可自動完成域名所有權驗證、證書簽發(fā)、IIS 等 Web 服務器部署及到期續(xù)訂并支持多域名與通配符證書管理配合日志與報告便于排查驗證失敗、續(xù)訂異常等問題對 HTTP-01 與 DNS-01 驗證、證書計劃任務和狀態(tài)檢查也有相應支持。已有 334 人學習下載適合希望以較低成本為站點啟用 HTTPS、減少手工維護證書負擔并借助腳本與配置樣例搭建自動化續(xù)期流程的讀者參考使用。1. 免費域名搜進來先說清楚 win-acme 到底給什么搜「免費域名」的人多半會被 win-acme 這個名字帶偏它不發(fā)域名發(fā)的是 90 天一輪的免費 TLS 證書把 HTTPS 那筆每年幾千塊的開銷直接抹掉。v2.1.18 的 x64 自包含包解開就是一個wacs.exe不需要預裝 .NET 運行時Windows Server 2012 R2 以上丟上去雙擊就能跑。它管的是證書從簽發(fā)、驗證、部署到續(xù)期的整條鏈路對接 ACME 協(xié)議、跑 HTTP-01 或 DNS-01 驗證、把結果寫進 IIS 或 PEM/PFX 文件、再自己掛一個計劃任務做無人值守續(xù)期。適合自己維護一兩臺 Windows 機器的運維、給內網(wǎng)測試站配證書的后端以及不想天天敲 OpenSSL 的人。它不管域名本身也不替你做解析這兩件事必須先自己搞定。2. 裝到簽發(fā)第一張證書x64 自包含包的啟動姿勢與向導映射2.1 解壓后的目錄結構為什么優(yōu)先選自包含包這個包最大的價值是「零依賴啟動」。解壓出來你會看到wacs.exe加一批 dll、一個web子目錄和若干插件目錄全部自包含機器上沒裝 .NET 運行時也能直接跑。同一版本系列里還有依賴框架的變體體積小一些但換來的代價是每臺目標機器都得先補運行時一旦版本對不上雙擊就是一句「缺少運行時」的彈窗連菜單都進不去。生產(chǎn)環(huán)境里我一般無條件選自包含版硬盤多占幾十兆換的是排障時少一個變量。解壓路徑也有講究別放桌面或者帶中文的目錄放到C:\tools\win-acme這類純英文短路徑下因為后面計劃任務的工作目錄會引用這個位置路徑里帶空格或者中文很容易在任務計劃里被截斷。第一次運行必須以管理員身份開命令行不是雙擊 exe——雙擊雖然也能進交互菜單但后續(xù)寫證書存儲、改 IIS 綁定都需要提權中途失敗會讓你以為證書簽發(fā)失敗其實是權限不夠。先做一件事確認這版支持哪些參數(shù)別照抄三年前的教程。# 管理員身份打開 cmd進到解壓目錄 cd /d C:\tools\win-acme # 打印完整參數(shù)列表重點看 target / validation / store / installation 四段 wacs.exe --help--help的輸出很長但只需要盯四組參數(shù)--target決定主機名從哪來手動輸入還是掃 IIS--validation決定用哪種驗證方式--store決定證書存成什么格式--installation決定要不要順手裝進 IIS。這四個決定了后面所有命令的形狀。不同小版本之間參數(shù)名會有微調比如早期版本某些開關叫法不一樣抄舊命令最常見的報錯就是「未知參數(shù)」而這條命令能在三十秒內告訴你正確答案。養(yǎng)成習慣換一臺機器、換一個版本先跑一次--help比出問題再回頭查強得多。2.2 交互向導走一遍從主菜單到證書落地第一次用建議走交互模式把流程在腦子里建立一遍映像之后再用命令行固化。運行wacs.exe管理員 cmd 里主菜單是幾個字母鍵新建證書、續(xù)期、管理續(xù)期、列出已有續(xù)期。選新建之后向導會依次問你五件事這五件事和后面命令行的參數(shù)是一一對應的理解了這層映射參數(shù)就不用背了。第一步問主機名輸入www.example.com多個域名用逗號分隔注意這里填的必須是能通過公網(wǎng)解析到本機的域名填錯后面驗證必然失敗。第二步問驗證方式列表里會同時出現(xiàn)文件系統(tǒng)驗證、自托管驗證、DNS 手動驗證、DNS 腳本驗證等選項每一項前面標著[http-01]、[dns-01]或[tls-alpn-01]這就是協(xié)議類型。第三步問證書存到哪可選 PEM 文件、PFX 歸檔、Windows 證書存儲選完還會追問具體路徑或存儲位置。第四步問要不要安裝到 IIS如果這臺機器上有 IIS 站點選安裝會自動更新綁定。第五步是接受協(xié)議條款和填郵箱郵箱必須真實可用證書快到期時 CA 會往這個地址發(fā)提醒很多「證書突然過期」的事故就是當初隨手填了個不存在的郵箱。向導跑完屏幕上會打印一段匯總包含證書路徑、指紋、到期時間和下次續(xù)期時間。這一段務必截圖或者復制到記事本因為它是后面寫腳本、核對綁定關系的依據(jù)。整個過程中最容易出錯的是第二步和第三步的路徑驗證路徑填的必須是網(wǎng)站真實根目錄證書輸出路徑必須是空目錄或者你有寫權限的目錄兩者填反了會得到兩種完全不同的報錯前者是驗證 403后者是寫文件失敗。2.3 用命令行把向導固化一條能重復執(zhí)行的簽發(fā)命令交互模式適合第一次第二次開始就該上命令行了。命令行最大的好處是可復現(xiàn)換機器、換域名改幾個變量就能重跑而且能直接塞進自動化腳本里。下面這條是我常用的最小可用組合做的是「手動指定域名 文件系統(tǒng)驗證 輸出 PEM」wacs.exe ^ --target manual ^ --host www.example.com ^ --validation filesystem ^ --webroot C:\inetpub\wwwroot ^ --store pemfiles ^ --pemfilespath C:\certs\www.example.com ^ --accepttos ^ --emailaddress opsexample.com ^ --verbose逐段說明這幾個參數(shù)在干什么以及改哪里參數(shù)作用改動時的注意點--target manual域名從參數(shù)里讀不掃 IIS想讓它自動發(fā)現(xiàn) IIS 站點改成--target iis--host要簽的域名逗號分隔多個通配符寫*.example.com且必須配 DNS 驗證--validation filesystem把驗證文件寫進網(wǎng)站根目錄需要--webroot配套路徑必須是站點真實根--webroot驗證文件的落地目錄寫錯就是 403用瀏覽器能訪問到該目錄再繼續(xù)--store pemfiles輸出 PEM 格式證書需要--pemfilespath目錄不存在會自動建--pemfilespathPEM 輸出目錄建議一域名一目錄便于腳本按目錄 reload--accepttos自動接受 CA 條款不加會卡在交互確認自動化場景必加--emailaddress到期提醒郵箱別填 noreply 之類的假地址--verbose打印詳細過程首次簽發(fā)必開出問題就看它這條命令跑完最快十幾秒就能出結果。如果第一次就失敗把--verbose的輸出從頭看到尾它會明確告訴你卡在哪一步是 DNS 解析不到、是 80 端口連不上、還是文件寫不進去。這比在瀏覽器里反復刷新猜原因高效得多。還有一點調試階段不要拿生產(chǎn)環(huán)境反復試ACME 服務端對同一組域名有每周簽發(fā)次數(shù)限制反復失敗重試很容易把自己鎖住正確做法是把 baseuri 指向 CA 提供的測試目錄先跑通再切回來。測試證書瀏覽器不認這是正常的它只用來驗證流程通不通。3. 驗證方式怎么選HTTP-01、DNS-01 與產(chǎn)物落地位置3.1 文件系統(tǒng)驗證和自托管驗證差在一個 80 端口兩種方式都屬于 HTTP-01本質都是讓 CA 通過http://域名/.well-known/acme-challenge/隨機串訪問到一個指定內容。差別在于誰來提供這個 HTTP 服務。文件系統(tǒng)驗證是「借」你已有的 web 服務器win-acme 把驗證文件寫進網(wǎng)站根目錄的.well-known/acme-challenge/下然后由你現(xiàn)有的 IIS 或 nginx 把它吐出去。這條路適合已經(jīng)有站點在跑、80 端口本來就被占用的機器缺點是對 web 服務器的路由配置有依賴最常見的失敗原因是站點做了全站 301 跳 HTTPS或者 nginx 里寫了try_files把所有請求都轉給后端應用導致.well-known這個路徑根本落不到真實文件上。自托管驗證是 win-acme 自己臨時起一個極簡 web 服務器搶占 80 端口驗完就關。它適合這臺機器上根本沒有 web 服務、或者 web 服務不在這臺機器上的場景。代價是運行期間 80 端口必須是空閑的如果 IIS 正在跑就會直接報端口占用。判斷方法很簡單netstat -ano | findstr :80看有沒有進程在監(jiān)聽有就說明自托管模式走不通乖乖用文件系統(tǒng)模式或者先停服務再簽。下面這段是 nginx 環(huán)境下最容易踩的配置坑放行規(guī)則要寫在跳轉規(guī)則之前server { listen 80; server_name www.example.com; # 驗證路徑必須優(yōu)先匹配且不能跳轉、不能交給后端 location ^~ /.well-known/acme-challenge/ { root /var/www/html; default_type text/plain; try_files $uri 404; } # 其余請求才走 HTTPS 跳轉 location / { return 301 https://$host$request_uri; } }^~前綴匹配的優(yōu)先級高于正則能保證驗證請求不被后面的 rewrite 規(guī)則截走try_files $uri 404是為了在文件真的不存在時返回 404 而不是被兜底到首頁這樣出問題時你能立刻從狀態(tài)碼判斷是「文件沒寫進來」還是「路由被攔了」。改完 nginx 一定要nginx -t再 reload配置語法錯誤會導致整個站點掛掉那時候你面對的就是雙重故障。IIS 那邊同理檢查 URL 重寫模塊里有沒有全站規(guī)則有的話給.well-known加一條排除。3.2 DNS-01 與通配符手動模式和腳本鉤子的邊界通配符證書*.example.com只能走 DNS-01這是硬約束因為 HTTP-01 無法證明你控制所有子域。DNS-01 的原理是 CA 讓你在_acme-challenge.example.com加一條指定內容的 TXT 記錄它去權威 DNS 查詢這條記錄查到就算通過。手動模式下win-acme 會把該加的記錄名和記錄值打印在屏幕上你復制到 DNS 控制臺等生效后回車繼續(xù)簽完再手動刪掉。這條路適合一年只簽一次、域名數(shù)量個位數(shù)的場景雖然笨但絕不會因為 API 權限出問題而失敗。腳本模式是把「加記錄 / 刪記錄」兩個動作交給腳本win-acme 在驗證前后各調一次。真正的坑不在腳本本身而在 DNS 傳播延遲記錄提交成功不代表權威 DNS 立刻對外可見客戶端如果查得太早會拿到 NXDOMAIN 直接判失敗。穩(wěn)妥做法是在腳本里加主動探測用公共 DNS 反復查這條 TXT 直到查到為止再返回給 win-acme而不是靠固定 sleep 硬等。另一個坑是 TXT 記錄同名多條同一主域下同時簽*.example.com和example.com時兩條驗證會往同一個記錄名寫不同值如果腳本是「覆蓋寫」而不是「追加寫」第二條必然覆蓋第一條導致驗證失敗。腳本里必須實現(xiàn)「讀現(xiàn)有值 → 追加 → 驗證完刪掉自己那條」的邏輯。提示腳本模式的參數(shù)名在不同小版本間有過調整寫腳本之前先跑wacs.exe --help找到 validation 段的實際寫法別直接套網(wǎng)上的舊示例。3.3 產(chǎn)物清單PEM、PFX、證書存儲分別喂給誰同一個證書不同消費者要不同格式這一步選錯后面會得到「證書明明簽下來了服務就是不認」的玄學現(xiàn)象。下面這張表是我這幾年反復對照過的對應關系存儲類型落地產(chǎn)物典型消費者備注PEM 文件fullchain.pem、privkey.pem、chain.pemnginx、Apache、Go 服務私鑰權限要收緊Linux 側 600PFX 歸檔.pfx單文件IIS 導入、Tomcat、Java keystore需要設密碼密碼要能傳給部署腳本W(wǎng)indows 證書存儲本機「個人」或「Web 托管」存儲IIS 綁定、SMTP、遠程桌面私鑰 ACL 丟了會報密鑰集不存在IIS 安裝中央證書存儲 站點綁定直接對外的 IIS 站點會自動改綁定簽之前先備份配置PEM 那一行要特別說一句fullchain.pem是「站點證書 中間證書」拼起來的完整鏈chain.pem只有中間證書privkey.pem是私鑰。nginx 的ssl_certificate要指向 fullchain 而不是單獨的站點證書只配站點證書會出現(xiàn)在部分客戶端上「證書鏈不完整」的警告桌面瀏覽器因為會自動補鏈所以看不出來手機和部分 API 客戶端就直接報錯了。這個問題藏得很深屬于典型的「本機測試一切正常、上線被投訴」類型。證書存儲那條路的坑在私鑰權限。證書導進「Web 托管」存儲后IIS 應用池賬戶需要能讀到私鑰如果這臺機器是從別的機器遷移過來的、或者你手工用 certutil 導入過私鑰 ACL 很容易丟癥狀是綁定站點時報0x80070520。遇到這個別急著刪證書重來先用certutil -store WebHosting看證書是否在、私鑰是否標記為可導出再檢查私鑰文件的 ACL。4. 自動續(xù)期閉環(huán)計劃任務、鉤子腳本與日志三件套4.1 續(xù)期任務是怎么被寫進任務計劃的證書只有 90 天能不能自動續(xù)上決定了這套方案是省事還是添亂。win-acme 在創(chuàng)建續(xù)期條目時默認會往 Windows 任務計劃里注冊一個名字帶win-acme renew的任務觸發(fā)器設成每天跑一次實際執(zhí)行時它自己判斷「離到期還有多久」沒到續(xù)期窗口就直接退出所以天天跑并不會真的天天簽發(fā)。這個設計比「算好日期定一個 60 天后的單次任務」穩(wěn)得多因為機器可能關機、可能休眠、可能臨時沒網(wǎng)單次任務錯過就是錯過每日輪詢則有很多次補救機會。注冊任務時會問你用哪個賬戶運行這一步別隨手選當前登錄用戶。選當前用戶意味著任務依賴這個賬戶的密碼密碼一改、賬戶一禁用任務就靜默失敗而且失敗得很安靜——任務計劃里只顯示一個錯誤碼沒有任何彈窗。我一般選 SYSTEM它不受登錄狀態(tài)和密碼策略影響缺點是腳本里如果用到了用戶級的環(huán)境變量或者映射網(wǎng)絡驅動器會讀不到。如果確實需要訪問網(wǎng)絡路徑就用一個有固定密碼的服務賬戶并且把「不管用戶是否登錄都運行」勾上。:: 列出當前所有續(xù)期條目看下一次到期時間和上次執(zhí)行結果 wacs.exe --list :: 強制立刻走一次續(xù)期流程用于驗證鉤子腳本是否生效 wacs.exe --renew --force :: 測試階段不想讓它自動注冊計劃任務加上這個開關 wacs.exe --renew --notaskscheduler--list這條命令的價值被嚴重低估。它輸出的不只是域名還有每條續(xù)期的 ID、綁定的驗證方式、證書路徑和下次續(xù)期時間出問題時先跑它能立刻區(qū)分是「續(xù)期條目壓根沒建」還是「條目在但執(zhí)行失敗」。--renew --force是調試利器但它會真的去 CA 申請新證書所以在生產(chǎn)域名上別連著跑——一周內重復簽發(fā)同一組域名是有次數(shù)上限的超了就得等窗口重置。想反復測流程就把 baseuri 指到測試目錄隨便折騰。注意--force繞過的是「是否在續(xù)期窗口內」的判斷不是繞過 CA 的限制。調試和生產(chǎn)的邊界要在這里劃清楚。4.2 續(xù)期后的鉤子導出 PEM 并讓服務熱加載證書續(xù)下來只是第一步讓正在跑的服務用上新證書才是閉環(huán)。win-acme 支持在續(xù)期成功后執(zhí)行一個腳本把續(xù)期 ID、證書指紋之類的信息作為參數(shù)傳進去腳本里根據(jù)這些信息做后續(xù)動作。典型場景是win-acme 只負責把新 PEM 寫到固定目錄腳本負責把文件同步到 nginx 目錄并 reload。# reload-nginx.ps1 # 由 win-acme 在續(xù)期成功后調用參數(shù)由 --scriptparameters 傳入 param( [string]$RenewalId, [string]$Thumbprint ) $log C:\tools\win-acme\hooks\reload.log $(Get-Date -Format s) renewal$RenewalId thumbprint$Thumbprint | Out-File $log -Append # 先做語法檢查檢查不過就不 reload避免把站點搞掛 C:\nginx\nginx.exe -t if ($LASTEXITCODE -ne 0) { nginx config test failed, skip reload | Out-File $log -Append exit 1 } # 平滑重載不中斷現(xiàn)有連接 C:\nginx\nginx.exe -s reload reload done, exit$LASTEXITCODE | Out-File $log -Append這段腳本的關鍵設計有三點。第一它自己寫日志因為 win-acme 的日志只記錄到「腳本已執(zhí)行」腳本內部的成敗它看不到?jīng)]有獨立日志你就只能靠猜。第二reload 之前先nginx -t配置有問題時寧可繼續(xù)用舊證書也不要讓服務起不來這個順序反了就是血淚經(jīng)驗。第三用-s reload而不是重啟服務reload 是平滑的重啟會掐斷正在處理的請求。參數(shù)$RenewalId和$Thumbprint來自 win-acme 的占位符替換具體可用哪些占位符以--help里 script 段的說明為準不同版本支持的不完全一樣寫之前對一遍別想當然。4.3 用日志和狀態(tài)文件判斷這次續(xù)期到底成沒成續(xù)期失敗最怕的是「靜默」計劃任務照常跑日志里沒有明顯紅色報錯等到某天瀏覽器彈證書過期才發(fā)現(xiàn)已經(jīng)斷了兩個月。所以要有固定的巡檢動作。日志落在程序數(shù)據(jù)目錄下路徑形如C:\ProgramData\win-acme\acme-v02.api.letsencrypt.org\Log文件名按日期組織一次續(xù)期一個文件。判斷成敗不要只看最后一行要看有沒有出現(xiàn)明確的成功字樣和證書指紋中間出現(xiàn)的重試記錄不算失敗只有最終沒有拿到新證書才算。除了日志續(xù)期條目的配置文件也值得看一眼。每個續(xù)期條目在Renewals子目錄下有一份自己的配置文件記錄了域名、驗證方式、存儲路徑、上次執(zhí)行時間。這份文件是「當前生效配置」的唯一真相改了它等于改了續(xù)期行為所以我一般先備份再動。有些場景下你會需要手工改它比如換了 webroot 路徑、換了輸出目錄與其刪掉重建不如直接改配置里的路徑字段保留原來的續(xù)期 ID 和計劃任務關聯(lián)。巡檢腳本可以很簡單每天讀一次最新日志找關鍵字沒有成功標記就發(fā)告警。真正麻煩的不是寫腳本而是堅持看。我見過太多「配好就不管」的案例包括我自己早期配完三個月后證書過期排查半天才發(fā)現(xiàn)是某次系統(tǒng)更新后計劃任務的運行賬戶被改成了需要交互登錄。從那以后我給自己定了規(guī)矩任何自動續(xù)期上線后第二周必須人為跑一次--list確認狀態(tài)之后再按月抽查。5. 五個翻車現(xiàn)場從 403 到 0x80070520 的排查順序5.1 驗證返回 403 或 Invalid response現(xiàn)象命令跑完報驗證失敗提示從http://域名/.well-known/acme-challenge/xxx取文件失敗返回 403 或 404。原因基本只有三類webroot 路徑填的不是站點真實根目錄站點有全站跳轉或重寫規(guī)則把.well-known攔截了文件寫進去了但 web 服務器進程沒有讀權限。解決順序是先用瀏覽器或curl -I直接訪問那個路徑看返回什么狀態(tài)碼403 就是權限或規(guī)則問題404 就是路徑問題。確認路徑無誤后檢查 nginx 的location順序和 IIS 的 URL 重寫規(guī)則把.well-known的放行規(guī)則提到跳轉規(guī)則之前。5.2 自托管模式報端口占用現(xiàn)象選自托管驗證后立刻失敗日志里出現(xiàn)地址已被占用的字樣。原因很直接80 端口上已經(jīng)有別的進程在監(jiān)聽最常見的是 IIS 的默認站點其次是某些系統(tǒng)服務。排查用netstat -ano | findstr :80拿到 PID再tasklist | findstr PID對上是哪個進程。解決方式不是硬停服務而是換驗證方式——既然 80 端口已經(jīng)被 web 服務器占著直接改用文件系統(tǒng)驗證把驗證文件寫進那個站點的根目錄反而更省事。硬停 IIS 再簽簽完還得啟回來中間站點是斷的。5.3 IIS 綁定更新了但瀏覽器還是舊證書現(xiàn)象證書續(xù)期成功路徑里的文件時間也是新的但瀏覽器訪問還是顯示舊證書或者證書鏈不完整。原因通常是 IIS 站點綁定還指向舊證書的指紋或者用了中央證書存儲但站點沒有正確引用。先用netsh http show sslcert看 443 端口當前綁定的指紋和--list輸出的新指紋比對不一致就是綁定沒更新。再檢查 IIS 站點綁定的 SNI 設置多站點共用 443 時靠 SNI 區(qū)分SNI 沒開會導致所有域名都拿到同一個證書。改完綁定記得iisreset或者回收應用池某些情況下 IIS 會緩存證書句柄。5.4 計劃任務天天跑但證書始終不續(xù)現(xiàn)象任務計劃里能看到任務上次運行結果是一個非零的錯誤碼證書到期時間紋絲不動。原因有三個高頻項任務運行賬戶的密碼過期或被改任務被設成「僅在用戶登錄時運行」而服務器沒人登錄機器在續(xù)期窗口期長期斷網(wǎng)。排查先看任務的「上次運行結果」和「歷史記錄」再手動用同一賬戶執(zhí)行一次--renew看報錯。解決方式是把運行賬戶改成 SYSTEM勾選「不管用戶是否登錄都運行」并在腳本里加網(wǎng)絡可達性檢查不通時提前退出并寫日志而不是等到驗證階段才失敗。5.5 報 too many certificates 被限流現(xiàn)象調試階段反復重試突然所有簽發(fā)都失敗提示同一組域名的證書簽發(fā)次數(shù)超限。原因是公共 CA 對「同一組域名集合」的單位時間簽發(fā)數(shù)量有上限--force反復跑正好踩中。這個坑沒有后悔藥只能等窗口重置通常是一周。正確的應對是提前把調試流量導到測試目錄簽發(fā)命令里把 baseuri 指向 CA 提供的測試入口測試證書不被瀏覽器信任但流程完全一致等流程確認無誤再切回生產(chǎn)目錄跑一次。這個習慣我從第一次被限流之后就固定下來了此后再沒在生產(chǎn)目錄上做過任何調試。6. 多站點批量把續(xù)期配置當代碼管起來機器上站點一多一條條敲命令就不現(xiàn)實了。批量模式的核心思路是先用一條命令把多個域名塞進同一個證書再用--list和續(xù)期配置文件統(tǒng)一管理而不是為每個域名建一個計劃任務。6.1 多域名合并與配置復用同一個站點的主域、www、幾個子域完全可以簽進同一張證書--host支持逗號分隔多個域名驗證只需做一次續(xù)期窗口也只有一個管理成本直接降一個量級。但要注意證書里的域名數(shù)量不是越多越好一個域名驗證失敗會導致整張證書簽發(fā)失敗所以「按業(yè)務分組、每組一張證書」比「全站一張大證書」更穩(wěn)。:: 三個域名合并一張證書輸出到按主域命名的目錄 wacs.exe ^ --target manual ^ --host example.com,www.example.com,api.example.com ^ --validation filesystem ^ --webroot C:\inetpub\wwwroot ^ --store pemfiles ^ --pemfilespath C:\certs\example.com ^ --accepttos ^ --emailaddress opsexample.com這條命令生成的續(xù)期條目會作為一個整體存在續(xù)期時三個域名一起驗、一起簽、一起更新文件。改配置時改的也是這一個條目不用滿機器找散落的計劃任務。如果確實需要通配符把--host換成*.example.com,example.com同時把驗證方式換成 DNS-01因為通配符不支持 HTTP 驗證。6.2 用一條命令驗收證書鏈簽完之后別只信日志直接驗證證書本身。Windows 上可以用 OpenSSL也可以用 PowerShell 的Get-PfxCertificate但我更習慣用 OpenSSL 看完整的鏈和有效期信息最全# 連上目標站點打印證書鏈和有效期 openssl s_client -connect www.example.com:443 -servername www.example.com /dev/null 2/dev/null \ | openssl x509 -noout -subject -issuer -dates -fingerprint -sha256輸出里重點看三項subject里的域名是否和預期一致、dates的到期時間是否是剛續(xù)期后的新日期、issuer是否是中間證書而不是根證書。如果s_client輸出里出現(xiàn)verify error: unable to get local issuer certificate說明服務端沒把中間證書一起發(fā)出來回到 3.3 節(jié)檢查是不是只配了站點證書沒配 fullchain。這條命令我一般放在續(xù)期腳本的最后一步自動跑一遍輸出寫進日志比事后靠用戶投訴發(fā)現(xiàn)要早得多。證書這東西配好那天是最可靠的之后可靠性只會一路下降。我現(xiàn)在的習慣是每次動過 web 服務器配置、改過防火墻、換過 DNS 服務商都強制跑一遍--list加一次 openssl 驗證確認鏈完整、日期正確、續(xù)期條目還在。多花三分鐘省掉的是某天早上被電話叫醒。這份 x64 自包含包解壓即用配置、日志、續(xù)期條目全部落在 ProgramData 下按照第 2 章的向導走一遍就能出第一張證書先把單域名的閉環(huán)跑通再往上疊批量和鉤子希望幫到你。本文還有配套的精品資源點擊獲取