简介win-acme.v2.2.9.1701.x64.pluggable.zip 是面向Windows平台网站管理员、个人站长与系统集成商的免费SSL证书自动化工具包主要解决证书申请、部署和续订流程繁琐的问题也适合官方渠道下载较慢时获取可用版本。压缩包共28个文件约35.58MB以PowerShell脚本和批处理文件为主辅以可执行程序、JSON/XML配置模板及说明文本覆盖证书导入、任务脚本、服务器配置与版本说明等用途。已有401人学习适合需要为IIS、nginx等站点配置SSL的中级用户参考。解压后可使用核心程序完成Lets Encrypt等证书的申请与更新并借助脚本和默认配置简化多场景部署与续订管理。对于希望低成本加固站点传输安全、减少手工操作和排错成本的运维人员这份工具包能提供较完整的自动化支撑。1. 每 90 天手导一次 PFX这个循环值得用 win-acme 掐断一个跑在 Windows 上的 nginx 反代站点从 3 个涨到 12 个之后续证书这件事就从「顺手」变成了「必须排进日程」。手工签发、下载、转格式、改配置、reload每个站点走一遍三个月一轮漏掉一个就是浏览器红色警告。win-acme 是 Windows 上的 ACME 协议客户端把「申请、域名验证、落盘、续期、续期后动作」串成一条能反复执行的链路免费 SSL 证书的整个生命周期交给计划任务托管。手上的 win-acme.v2.2.9.1701.x64.pluggable.zip 是 x64 插件化版本解压即用不依赖额外运行时。适合在 Windows 上维护 IIS 或 nginx、站点数量在个位数到几十个之间、又不想为每张证书单独走商业流程的人。2. 插件化拆解证书从哪来、存到哪两条插件链决定成败2.1 pluggable 版本意味着什么名字里的 pluggable 不是营销词而是这个版本的构建形态主程序wacs.exe只负责调度真正干活的是一组按能力分层的插件它们和主程序一起被打进同一个压缩包。带来的直接后果是——你在命令行里敲的每一个开关本质上都是在指定「用哪个插件」而不是在描述一个固定流程。这和很多把流程写死的证书工具不一样。固定流程的工具通常假设证书一定存进系统证书库、一定绑定 IIS 站点pluggable 版本把「从哪读域名」「用什么方式证明域名归属」「证书存成什么格式」「续完之后执行什么」拆成四段可替换的环节。好处是 nginx PEM 这种非 IIS 场景能原生支持坏处是参数一多选错一个插件照样能跑完、但产出物不是你想要的。我一般建议先用--help把当前版本实际注册了哪些插件列一遍比翻任何第三方教程都准因为小版本之间参数名偶有调整# 进入解压目录后执行重点看 source / validation / store / installation 四组可用值 cd C:\tools\win-acme .\wacs.exe --help | Select-String -Pattern source|validation|store|installation这段命令只做一件事把帮助输出里与四段管线相关的行过滤出来。Select-String是 PowerShell 的正则匹配-Pattern里用|表示或关系。跑完你会拿到一份属于你这个版本的「合法枚举值」清单后面的所有参数都以它为基准不要照着网上抄。2.2 四段管线Source → Validation → Store → Installationwin-acme 的执行模型可以拆成一条单向管线每一段都对应一个插件族阶段作用常见取值落地时的取舍Source域名从哪来iis、manualIIS 站点自动枚举省事手工站点必须用manual显式给--hostValidation怎么证明域名归属filesystem、selfhosting、dns、ftp有 nginx 站点目录就用filesystem最省事也最稳Store证书存成什么pemfiles、pfxfile、certificatestorenginx 只认 PEM直接选pemfiles不要先 pfx 再转Installation续完之后做什么script、none、iisnginx 场景选script让脚本去 reload四个阶段里最容易选错的是 Validation。selfhosting让 win-acme 自己在 80 端口起一个临时监听来接验证请求好处是不用管 webroot 路径坏处是必须先把占用 80 端口的 nginx 停掉否则端口冲突直接失败。filesystem反过来它把验证文件写进你指定的 webroot 目录下的.well-known/acme-challenge/让已经运行的 nginx 去返回不抢端口这也是我绝大多数场景下的默认选择。Store 这一段有个细节值得说pemfiles插件在续期时是覆盖写同名文件而不是新建目录。所以只要你第一次把--pemfilespath指向一个固定目录nginx 配置里的路径就永远不用改。这比「每次续期文件名都不一样、还得改配置」的方案省太多事。2.3 三种组合的选型对照把管线拼起来实际工作中反复出现的就是这三种组合选之前先确认自己的场景第一种IIS 一体式。--source iis--validation selfhosting--store certificatestore--installation iis全自动站点枚举和证书绑定都由插件完成适合纯 IIS 环境。第二种nginx 文件式也是这份压缩包最主要的用法--source manual--validation filesystem--store pemfiles--installation script每一步都要显式给参数但可控。第三种中央存储式--store centralssl多台机器共享一个证书目录适合有负载均衡、多节点跑同一批站点的架构。新手最容易踩的坑是把第一种的参数习惯带到第二种上——比如写了--installation iis结果机器上根本没有 IIS 站点命令跑完提示成功但 nginx 那边什么都没变。所以第 3 章开始整条命令我会一个参数一个参数地拆开写。3. 解压后的第一次握手命令行跑通一张证书3.1 目录、配置与前置自检解压到一个不带空格、不带中文的路径下比如C:\tools\win-acme。带空格的路径在计划任务和脚本调用里会引入额外的引号处理属于可以避免的麻烦。目录里的settings.json是全局配置第一次运行时由向导生成续期天数、日志目录、代理设置都在里面不要手工删它删了会退回默认值。跑之前先做三项自检80 端口当前被谁占着、webroot 目录是否真实存在、DNS 是否已经把域名解析到这台机器。前两项用命令确认第三项去解析记录里看# 1) 确认 80 端口归属看是不是 nginx 在监听 Get-NetTCPConnection -LocalPort 80 -State Listen | Select-Object LocalAddress, OwningProcess, {nProcess;e{(Get-Process -Id $_.OwningProcess).ProcessName}} # 2) 确认 webroot 存在且 .well-known 子目录可以创建 $webroot C:\nginx\html Test-Path $webroot New-Item -ItemType Directory -Force -Path $webroot\.well-known\acme-challenge | Out-Null # 3) 确认域名解析指向本机公网出口 Resolve-DnsName shop.example.com -Type A第一段用Get-NetTCPConnection找 80 端口的监听进程再用计算属性把 PID 翻译成进程名——这一步是为了确认「验证请求到达时是 nginx 在应答」。第二段建目录-Force让目录已存在时不报错这条命令可以安全重跑。第三段核解析Resolve-DnsName返回的 IP 必须和这台机器对外的出口 IP 一致否则后面所有验证都会失败而且失败信息不会告诉你「解析错了」只会告诉你「验证超时」。3.2 交互向导先建立一次成功的信心第一次别急着上命令行先跑一次交互向导。直接双击wacs.exe或者不带参数运行它会用问答方式引导你选源、选验证方式、选存储格式。向导的价值不在于省事而在于它会把你每一步的选择翻译成最终的命令行参数并打印在屏幕上。我习惯在向导跑完之后把屏幕上那行完整命令复制到一个文本文件里存着。原因很实际手工敲长命令时一个参数拼错比如--pemfilespath少个 s不会立刻报错而是走到一半才失败日志里还只写「无法写入目标」排查成本远高于抄一遍。向导过程中有三个地方要留意。验证方式那一步选「Save file to disk (webroot)」路径填 3.1 里那个 webroot存储那一步选「PEM encoded files」目录填一个独立路径比如C:\certs\shop.example.com不要塞进 nginx 的 conf 目录避免被误打包最后一步会问「是否创建计划任务」第一次跑先选否手动验证通过之后再补。3.3 参数化命令把流程固化成一行向导跑通一次之后换成参数化命令这才是能进脚本、进计划任务、进版本库的形态# 在 C:\tools\win-acme 目录下执行反引号是 PowerShell 的续行符 .\wacs.exe --source manual --host shop.example.com --validation filesystem --webroot C:\nginx\html --store pemfiles --pemfilespath C:\certs\shop.example.com --installation none --accepttos --emailaddress opsexample.com逐段说明。--source manual表示域名不由插件枚举而是完全由--host决定可以写多个--host也可以后面接--host加通配符走 DNS 验证时才用得上。--validation filesystem配合--webroot把验证文件写进C:\nginx\html\.well-known\acme-challenge\由已经在跑的 nginx 返回。--store pemfiles配合--pemfilespath落盘位置固定。--installation none在第一次跑时用意思是「证书存好就结束别做任何后续动作」——先确认证书本身没问题再去接后续动作这是排查顺序上的关键。--accepttos表示接受服务条款非交互模式下必须给。--emailaddress用在证书到期通知和账户找回上填一个团队邮箱而不是个人邮箱。第二次跑同一条命令时会发生什么这点要提前知道win-acme 会检测到这个域名已有未过期的证书默认跳过申请直接复用。想强制重签得加--force。这个行为在续期场景下是对的但在你刚改了验证方式、想验证新配置是否生效时会误导人——命令秒退、日志显示成功其实什么都没重新申请。3.4 验收四个文件、一条指纹、一次握手跑完之后去C:\certs\shop.example.com看产出。pemfiles插件通常会生成四个文件-crt.pem站点证书、-key.pem私钥、-chain.pem中间证书链、-chain-only.pem只有链、不含站点证书。四个文件的分工在下一章配 nginx 时很关键别混用。验收不靠肉眼看文件大小靠三条命令$dir C:\certs\shop.example.com Get-ChildItem $dir | Select-Object Name, Length, LastWriteTime # 看证书主体、有效期和签发链 openssl x509 -in $dir\shop.example.com-crt.pem -noout -subject -dates -issuer # 校验证书与私钥是否配对两边的模数哈希必须完全一致 openssl x509 -in $dir\shop.example.com-crt.pem -noout -modulus | openssl md5 openssl rsa -in $dir\shop.example.com-key.pem -noout -modulus | openssl md5第一条列文件重点看LastWriteTime是不是刚刚——如果时间是几小时前说明命令走了「复用已有证书」分支。第二条读证书的 subject、起止时间和签发者-noout阻止它把整个 PEM 内容打印出来。第三条是配对校验证书和私钥各自算出模数再取 MD5两个哈希相同才说明它们是一对。这一步看着多余但在「文件被手工替换过」「私钥和证书来自不同批次」的时候能立刻暴露问题比等 nginx 报错快得多。还有一个容易被忽略的验收点证书链是否完整。-crt.pem如果只装了站点证书、不含中间证书浏览器在部分客户端上会报链不完整。用下面这条确认能读到完整的链 openssl crl2pkcs7 -nocrl -certfile $dir\shop.example.com-chain.pem | openssl pkcs7 -print_certs -nooutcrl2pkcs7把 PEM 里的多张证书打包pkcs7 -print_certs再把它们逐一列出。正常应该看到至少一张中间证书只有一张的时候要警惕。4. nginx 侧落地PEM 落盘、reload 钩子与 SNI 多站点4.1 win-acme 导出的 PEM 到底是什么nginx 只认 PEM 格式这一点和 IIS 只认 PFX 正好相反。pemfiles插件产出的几份文件里配 nginx 实际只用两份一份「站点证书 中间证书」拼起来的完整链文件一份私钥。有些版本会把完整链直接写进-crt.pem有些版本把站点证书和链分开具体以openssl x509 -in ... -noout -subject读出来的内容为准。ssl_certificate指令指向的文件里应该包含站点证书在前、中间证书在后的顺序顺序反了部分客户端会握手失败。ssl_certificate_key指向私钥。私钥文件在 Windows 上还要额外确认一件事nginx 工作进程的运行账户必须有读权限否则 reload 会静默失败或者报「cannot load certificate key」。如果不确定-crt.pem里到底有几张证书用 3.4 最后那条pkcs7 -print_certs数一下。只有一张站点证书、没有中间证书时要么改用-chain.pem参与拼接要么用一条命令把两份文件合成一个新文件给 nginx 用。4.2 用 installation script 挂住 reload证书续好了但 nginx 不知道等于没续。这是所有证书自动化里最常见的断点。win-acme 的--installation script插件就是为这个断点准备的证书落盘成功后它调用你指定的脚本把本次续期的一些上下文作为参数传进去。先写脚本。脚本做三件事记录参数、做配置语法检查、平滑 reload# C:\scripts\nginx-reload.ps1 param( [string]$CacheFile, # 本次续期对应的缓存文件名 [string]$Thumbprint, # 新证书指纹 [string]$Subject # 证书主题通常是域名 ) $log C:\scripts\nginx-reload.log $stamp Get-Date -Format yyyy-MM-dd HH:mm:ss # 1) 先把收到的参数原样落日志参数顺序对不上时靠这段排查 Add-Content -Path $log -Value $stamp args: cache$CacheFile thumb$Thumbprint subject$Subject # 2) 语法检查失败就不 reload避免把线上打挂 C:\nginx\nginx.exe -p C:\nginx\ -t * $log if ($LASTEXITCODE -ne 0) { Add-Content -Path $log -Value $stamp nginx -t failed, skip reload exit 1 } # 3) 平滑重载已有连接不中断 C:\nginx\nginx.exe -p C:\nginx\ -s reload * $log Add-Content -Path $log -Value $stamp reload done, exit$LASTEXITCODE exit $LASTEXITCODE几个要点。param声明的是位置参数win-acme 调用脚本时按固定顺序传值不同小版本的参数个数可能不同所以第一步先把收到的值全写进日志——第一次接上之后去看一眼日志确认cache后面不是空字符串才说明参数接对了。nginx.exe -p指定 prefix 目录Windows 上不指定的话-s reload可能因为找不到logs/nginx.pid而失败这是很典型的一处翻车点。-t放在 reload 前面配置写错了就退出不会把线上带崩。*把标准输出和标准错误一起追加进日志省得丢了关键报错。脚本写好后把申请命令里的--installation none换成.\wacs.exe --source manual --host shop.example.com --validation filesystem --webroot C:\nginx\html --store pemfiles --pemfilespath C:\certs\shop.example.com --installation script --installationscript C:\scripts\nginx-reload.ps1 --accepttos --emailaddress opsexample.com--installation script选定插件--installationscript给出脚本绝对路径。路径里有空格时务必用双引号包起来。接好之后建议用--force强制重签一次让整条链路申请 → 落盘 → 调用脚本 → reload完整跑一遍而不是等 60 天后真的续期时才发现脚本根本没被执行。4.3 server 块与 SNI 多站点nginx 侧的配置不复杂但几个细节决定了多站点能不能共存# 每个站点一个 server 块listen 443 ssl 让 nginx 按 SNI 分发证书 server { listen 443 ssl; server_name shop.example.com; ssl_certificate C:/certs/shop.example.com/shop.example.com-crt.pem; ssl_certificate_key C:/certs/shop.example.com/shop.example.com-key.pem; ssl_protocols TLSv1.2 TLSv1.3; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } # 80 端口必须保留ACME 的 HTTP 验证要靠它应答 server { listen 80; server_name shop.example.com; location ^~ /.well-known/acme-challenge/ { root C:/nginx/html; default_type text/plain; } location / { return 301 https://$host$request_uri; } }路径统一用正斜杠Windows 上 nginx 也认避免反斜杠在某些上下文里被当成转义。location ^~ /.well-known/acme-challenge/必须排在跳转规则前面^~前缀匹配优先级高于普通前缀匹配能保证验证路径不被 301 到 https——一旦被跳转HTTP 验证就取不到文件这是最典型的失败原因之一。root指向的目录要和--webroot完全一致多一层少一层都不行。多站点共存的关键是server_name各不相同、各自带自己的证书nginx 会在 TLS 握手阶段按 SNI 挑证书。如果所有站点共用一个server块那张证书的 SAN 里必须包含全部域名否则部分域名会报证书不匹配。4.4 三条命令自证证书链配完不要只看浏览器绿锁用命令行验信息更全# 1) 本地语法检查 C:\nginx\nginx.exe -p C:\nginx\ -t # 2) 从外部视角看服务端实际下发的证书链-servername 触发 SNI openssl s_client -connect shop.example.com:443 -servername shop.example.com -showcerts | openssl x509 -noout -subject -dates # 3) 模拟一次验证请求确认 80 端口能返回 challenge 文件 Invoke-WebRequest -Uri http://shop.example.com/.well-known/acme-challenge/test.txt -UseBasicParsing第二条里的-servername不能省省了就不发 SNI 扩展多站点环境下大概率拿到默认站点的证书看到的是别人的域名然后误判成「证书配错了」。第三条是模拟 CA 的验证视角先在 webroot 的.well-known/acme-challenge/下放一个test.txt从公网侧请求它能拿到 200 和文件内容才说明验证路径通了。5. 避坑与排查五类最常翻车的现场5.1 现象验证阶段一直超时日志只有一句「Authorization failed」原因基本锁定在 HTTP-01 这条路上要么 80 端口从公网不可达安全组、防火墙、运营商拦截要么 nginx 把/.well-known/acme-challenge/的请求 301 到了 https要么--webroot指向的目录和 nginxroot指的不是同一个。还有一种隐蔽情况机器上有多个网卡或多个站点共用 80请求落到了默认站点的 server 块那个块的 root 里没有验证文件。解决办法按顺序排先用 4.4 第三条命令从公网侧请求一次能通说明 nginx 侧没问题问题在验证方式选错不通就把location ^~那段提到跳转规则之前nginx -t之后 reload仍然不通就临时改用--validation selfhosting把 nginx 停掉让 win-acme 自己起 80 监听能签出来就证明是 nginx 配置问题签不出来就是网络可达性问题。5.2 现象计划任务显示「上次运行成功」但证书文件时间没变这不是故障是设计行为。win-acme 默认只在证书剩余有效期低于阈值时才真正续期离到期还早的时候它会正常退出、返回成功什么都不做。看到「成功但没变化」先别改配置去日志里确认这条记录如果写的是跳过续期一切正常。真正需要注意的是另一种情况到期日已经很近了任务还是跳过。这时候查两个地方一是settings.json里的续期天数配置是不是被改大了二是有没有别的任务或人工操作把证书文件改成了只读。文件只读时续期会失败但失败信息往往被埋在详细日志里计划任务的摘要看不到。5.3 现象脚本手动跑没问题被 win-acme 调用时报「路径不存在」绝大多数是路径里带了空格或中文而调用方没有正确加引号。另一种是相对路径脚本里写C:\nginx\nginx.exe没问题但如果写成.\nginx.exe工作目录是 win-acme 的目录而不是 nginx 目录自然找不到。解决办法是把脚本里所有外部命令都改成绝对路径并且在param块之后立刻加一行Set-Location显式固定工作目录。另外注意 PowerShell 的执行策略服务账户下跑脚本时可能因为策略限制直接拒绝执行表现是「脚本一行都没跑」这种情况下要在调用时显式带上-ExecutionPolicy Bypass或者把策略配到机器级别。5.4 现象nginx -s reload返回 0但浏览器拿到的还是旧证书reload 成功不等于生效。两个原因一是 reload 只对新连接生效浏览器和中间层如果有连接复用或缓存短时间看到的还是旧证书二是 Windows 上 nginx 的 reload 依赖logs/nginx.pid用了-p指定 prefix 但 pid 文件路径和实际运行实例不一致时命令可能「成功」地发给了一个已经不存在的旧实例。验证方法很直接reload 之后立刻用 4.4 第二条命令看服务端下发的证书指纹和磁盘上-crt.pem的指纹对比。对不上就说明 reload 没打到正确实例用Get-Process nginx看实际有几个进程、启动时间是不是刚刚把多余的旧实例清掉再 reload。5.5 现象nginx 启动直接报SSL_CTX_use_PrivateKey ... key values mismatch证书和私钥不是一对。常见于手工替换文件时只换了其中一个或者两次申请分别落在不同目录、配置里指了混合来源。用 3.4 第三条那两条-modulus | md5一比就知道哈希不一致就是配错。还有一种变体两个哈希一致但 nginx 仍报错。这时候检查私钥文件是否被加密带口令的私钥 nginx 启动时需要交互输入非交互环境直接失败以及文件编码是不是被某个编辑器改成了带 BOM 的 UTF-8。PEM 文件必须是纯 ASCII、无 BOM用Format-Hex看前几个字节是不是2D 2D 2D 2D 2D也就是-----就能确认。6. 把续期做成可观测一个巡检脚本加三个阈值计划任务的「上次运行结果」只能告诉你进程退出码告诉不了你「证书还有几天到期」。真正让人半夜被叫起来的从来不是续期失败本身而是失败了没人知道直到证书过期当天浏览器报警。所以在自动化跑顺之后我一般会再加一层巡检每天读一次磁盘上证书的实际到期时间按剩余天数分级处理。# C:\scripts\cert-check.ps1 $targets ( { Nameshop; CertC:\certs\shop.example.com\shop.example.com-crt.pem }, { Nameapi; CertC:\certs\api.example.com\api.example.com-crt.pem } ) $warnDays 21 # 进入预警 $critDays 10 # 进入严重触发强制续期 foreach ($t in $targets) { if (-not (Test-Path $t.Cert)) { Write-EventLog -LogName Application -Source CertCheck -EventId 5101 -EntryType Error -Message $($t.Name) 证书文件缺失 continue } # openssl 输出形如 notAfterMay 1 12:00:00 2026 GMT先把多余空格压成一个 $raw ( openssl x509 -in $t.Cert -noout -enddate) -replace ^notAfter, -replace \s, $exp [datetime]::ParseExact($raw.Trim(), MMM d HH:mm:ss yyyy GMT, [Globalization.CultureInfo]::InvariantCulture) $days [math]::Floor(($exp.ToUniversalTime() - (Get-Date).ToUniversalTime()).TotalDays) $level if ($days -le $critDays) { Critical } elseif ($days -le $warnDays) { Warning } else { OK } Write-EventLog -LogName Application -Source CertCheck -EventId 5100 -EntryType Information -Message $($t.Name) 剩余 $days 天级别 $level if ($days -le $critDays) { # 强制走一次续期让整条链路自己去补救 C:\tools\win-acme\wacs.exe --renew --force * C:\scripts\cert-renew.log } }脚本的核心是「不信任任何中间状态只读最终产物」。openssl x509 -enddate读的是磁盘上真实的证书文件不依赖 win-acme 的日志、不依赖计划任务的返回值。-replace \s, 这步别省openssl 输出的日期里日字段可能是两位空格如May 1不归一化会让ParseExact直接抛异常而这个异常如果被 try/catch 吞掉巡检就变成了永远返回 OK 的摆设。阈值我一般定三档剩余 21 天进预警只写事件日志人工看到后确认续期任务是否正常剩余 10 天进严重脚本主动触发一次--renew --force把「计划任务没跑成」这条路径补上剩余 5 天还没有新证书说明强制续期也失败了这时该看的是验证配置而不是续期配置。三个阈值不要设成一样的否则预警和补救会挤在同一个时间点等于没有预警。提示Write-EventLog需要先注册事件源注册时要用管理员权限执行一次并且指定一个已存在的日志名。不确定事件源是否已注册时把写日志换成追加文本文件更省事排查时Get-Content -Tail也能看。从那以后我每次接一个新的 nginx 站点都会先把「证书目录固定、验证路径固定在 80 端口的^~位置、installation script 先记录参数再 reload」这三件事做完然后跑一次--force把整条链路走通最后才去配计划任务。顺序反过来的几乎都在两个月后的某一天被叫起来。希望帮到你。本文还有配套的精品资源点击获取
