简介win-acme.v2.2.9.1701.x64.pluggable.zip 是一款面向 Windows 平台的免费 SSL 证书自动获取与部署工具适合网站管理员、系统集成商以及希望低成本加固网站安全的用户。它支持从 Lets Encrypt 等机构自动申请证书并可部署到 IIS、nginx 等常见 Web 服务器尤其适合官方下载缓慢、需要快速获取工具包的场景。压缩包共 28 个文件约 35.58MB核心组件包括 wacs.exe 主程序、settings_default.json 配置文件和 Web_Config.xml 服务器配置模板另有 21 个 PowerShell 脚本和 2 个批处理文件用于对接 Exchange、RD Gateway、Kemp、Azure 等环境的证书导入与自动化续期。包内 public_suffix_list.dat、version.txt 等辅助文件便于域名列表管理与版本核对。已有 376 人学习下载随包附带专家撰写的安装使用教程链接可帮助用户掌握参数配置、定时续订等实操方法节省逐项摸索的时间。1. win-acme.v2.2.9.1701.x64.pluggable.zipWindows 上把证书续期变成自动挡的工具拿到win-acme.v2.2.9.1701.x64.pluggable.zip这个压缩包先别急着解压。它是一位跑在 Windows 上的 ACME 客户端替你把 SSL 证书的申请、验证、下载、装回证书库、绑到站点这套流程全部自动化。你真正省下的是那个最烦人的动作——每 90 天盯着证书到期日手动复制粘贴一堆东西。这个包里的pluggable后缀意味着它带了完整插件体系验证方式、证书存储都能按需扩展。适合所有人手上有 Windows Server、跑着 IIS 或 Windows 服务的运维、开发、甚至兼职管服务器的前端。这篇我把部署、首次签发、自动续期和最常见的几个翻车点按我的习惯讲一遍纯命令行可复现。2. 部署前的准备目录结构、配置文件与运行账号2.1 解压后先看目录哪些是核心哪些是插件pluggable版本和基础版的差别说白了就是多了一整套插件目录。解压后我一般先用tree或资源管理器把目录过一遍心里有张地图再动手。# 在解压目录里执行Windows 下可以用 git bash 或 cmd 的 tree /F tree /Fwin-acme/ ├─ win-acme.exe # 主程序所有操作都通过它 ├─ readme.txt # 版本说明与快速上手 ├─ settings.json # 首次运行后生成的全局配置 ├─ options.json # 首次运行后生成的签发选项 ├─ plugins/ # 插件 dllpluggable 版本的核心 │ ├─ xxxxx.validation.dll # 各种验证插件http、dns、tlsalpn │ └─ xxxxx.store.dll # 各种存储插件证书库、iis、pem ├─ logs/ # 运行日志排查问题的第一现场 └─ backup/ # 每张证书的 renew 配置续期全靠它目录结构核心就一句话:exe 负责干活plugins决定它能怎么干活logs和backup是它留下的脚印。settings.json和options.json 第一次运行后才会生成压缩包里的如果存在多半是程序自带的默认样例别直接拿来当生产配置。逻辑上正式使用前你应该确认plugins目录里插件文件齐全尤其是你要用的验证插件。pluggable版相对于基础版的优势就在这一步体现基础版只带内置的 HTTP 验证和证书库存储而插件版把 DNS 厂商 API、PEM 文件输出这些扩展能力都放进来了。缺哪个插件后面配 DNS 验证时会直接报找不到插件那种错误最容易让人误判成网络问题。2.2 settings.json 与 options.json两个配置文件各自管什么这个工具把配置拆成两层很多人第一次上手会在这懵到底改哪个文件。我的习惯是记住一句话——settings.json管客户端本身怎么跑options.json管每一张证书怎么签。settings.json是全局的包含 UI 语言、日志级别、默认联系邮箱、默认续期提前天数、默认 ACME 服务地址这些。第一次运行向导会让你选语言、填邮箱它就把结果写进这里。options.json则是签发参数包括目标站点、验证方式、存储方式、要签的域名列表。当你在命令行里复用一张旧证书的配置程序读的就是backup目录里对应那份 json。我用 PowerShell 把生成的配置展开来看比用记事本翻更直观# 查看全局配置字段名以你本机生成的为准 Get-Content .\settings.json | ConvertFrom-Json | ConvertTo-Json -Depth 5# 查看默认签发选项重点是 Source / Validation / Store 三段 Get-Content .\options.json | ConvertFrom-Json | ConvertTo-Json -Depth 8这里有个参数值得关注RenewalDays。它决定证书在到期前多少天开始续期默认 55 天——公共 ACME 服务商签发的证书有效期 90 天55 天意味着你有大概一个月时间处理失败这个值我一般不动除非你的证书有效期不是 90 天。LogLevel默认是 info排查问题时临时改成verbose再跑一轮能拿到验证请求的完整细节。注意不同小版本的字段命名可能有差异比如RenewalDays在个别版本里叫RenewDays。正确做法是先让程序自己生成一份基线再改字段不要拿网上的配置直接覆盖。2.3 用哪个账号跑服务账号与权限边界选运行账号是部署里最容易被低估的一步。我的建议分三种情况交互式跑一次试验直接当前管理员账号没问题要长期自动续期优先用专用服务账号嫌麻烦就用计划任务默认的 SYSTEM。但权限边界必须清楚。程序要干三件事账号就得有三类权限写本地证书库LocalMachine\My改 IIS 站点绑定访问 ACME 服务的 80/443 出网。这三个缺一个轻则续期失败重则证书更新了但服务没绑上线上照样报证书错误那种事故最坑。查计划任务是否建好我习惯用 PowerShell 确认状态和上次运行结果# 列出与 win-acme 相关的计划任务 Get-ScheduledTask | Where-Object TaskName -like *win-acme* | Select-Object TaskName, State # 查看上次运行时间和结果代码0 表示成功 Get-ScheduledTaskInfo -TaskName win-acme renew | Select-Object LastRunTime, LastTaskResult注意LastTaskResult的判定0 是成功非 0 要看具体错误码。如果你用专用账号跑还要额外给这个账号授予对backup目录的写权限否则续期配置写不进去程序会在日志里报权限相关异常。DNS 验证插件需要保存 API 密钥时我一般单独建账号并限制它只能访问指定目录别用管理员大而全的权限这是给自己留的后悔药。3. 首次签发证书最小命令行跑通全流程3.1 最小签发命令从 staging 到生产一条命令走完第一次上手最稳的路径不是直接签生产证书而是先对 staging 环境跑一遍。公共 ACME 服务都有测试端点签出来的证书浏览器不认但能完整验证你的命令、端口、权限都通不通。命令如下# 对测试环境签发验证流程是否跑通 # --test 表示使用测试端点证书不受信任 win-acme.exe --test \ --source manual \ --host mail.example.com \ --validation http \ --store certificate \ --accepttos \ --emailaddress opsexample.com逐段说下参数--source manual表示证书不绑定具体 IIS 站点域名由--host直接指定适合给非站点场景比如 Windows 服务、反向代理用--validation http走 HTTP-01 验证需要在 80 端口上完成挑战--store certificate把证书装进 Windows 证书库--accepttos表示接受服务条款脚本化运行必须带--emailaddress是注册账号邮箱证书快到期时的提醒发到这里。如果这一步输出里有绿色的成功标志并且logs目录生成了当天的日志文件说明链路通了。把--test去掉再跑一遍拿到的就是受信任的生产证书。这里有个经验生产命令我一般会加上--quiet把输出压到最少日志全部留给文件避免计划任务运行时弹出一堆窗口。提示如果你的目标域名要同时签多个用逗号分隔写进--host例如--host mail.example.com,www.example.com。别写成空格分隔程序会把第二段当成未知参数。3.2 验证方式怎么挑HTTP、TLS-ALPN、DNS 三张牌对比验证方式是整个签发流程的咽喉。选错了后面所有排错都是在浪费时间。三个选项的本质区别可以看这张对比表验证方式需要开的端口支持通配符典型场景失败时最常见原因HTTP-0180否IIS 站点、普通 Web 服务80 端口被占、防火墙拦截、验证目录不可写TLS-ALPN-01443否已有 HTTPS 站点的自动续期443 被其他服务占用、IIS 绑定冲突DNS-01无入站端口是通配符证书、无公网 Web 服务DNS 厂商 API 权限不足、TXT 记录传播慢原理上HTTP-01 是 ACME 服务来访问你域名下 80 端口的一个临时路径程序把验证文件放进去服务端抓到内容就通过TLS-ALPN-01 是在 443 端口上做一个带特殊扩展的 TLS 握手DNS-01 则是让你在域名解析里加一条 TXT 记录。端口和通配符支持这两个约束基本决定了你选谁。我的选择习惯是这样跑着 IIS 而且 80 端口空闲无脑 HTTP-01配置最简单80 被公司内网系统占了改不掉那就 TLS-ALPN-01 走 443但必须保证 443 上没有别的服务抢着监听要签*.example.com这种通配符只能 DNS-01而且需要你手里有 DNS 服务商的 API 密钥。pluggable包的价值在第三种场景最明显各家 DNS 的验证插件都在plugins目录里基础版想用 DNS 验证还得自己折腾。3.3 证书存到哪证书库、站点绑定还是 PEM 文件签发流程最后一步是存。--store参数决定证书落点这也是不少人续期成功后站点还报错的根源——不是没续上是存的位置没对。三种常见存储方式certificate存进 Windows 证书库的LocalMachine\My适合 Windows 服务、远程桌面这类从证书库取证书的场景iis会把证书直接绑定到指定站点适合 IIS 站点pemfiles输出 PEM 格式文件适合给非 Windows 组件用。它们可以组合以逗号分隔写在同一个参数里。给 IIS 站点签证书我一般这么写# 为 IIS 站点签发并同时写入证书库和站点绑定 win-acme.exe \ --source iis \ --siteid 1 \ --host portal.example.com \ --validation http \ --store certificate,iis \ --accepttos \ --quiet--source iis配合--siteid 1程序会去读对应 IIS 站点的绑定和主机名--store certificate,iis意味着证书既进证书库又自动挂到站点上。为什么两个都要因为很多运维场景里站点绑定只是消费方之一之后你可能还要给别的服务从证书库里读同一个证书。签发完立刻验证落位这是我每台机器必做的一步# 查看证书库中最近到期的证书 Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Subject -match portal.example.com } | Select-Object Subject, Thumbprint, NotAfter看到NotAfter是今天之后的大约 90 天说明存储成功。这一步可以在签完证、还没配置自动续期之前做确保手动能跑通这个前提先成立。4. 自动续期与常见问题排查三个容易翻车的坑4.1 自动续期的两种姿势计划任务与服务模式证书签成功只是开始真正的目标是以后再也不管它。win-acme 提供两条自动续期路径计划任务和 Windows 服务。交互式向导默认会创建一个计划任务这也是我推荐绝大多数人用的方式。它每天跑一次检查所有证书是否进入续期窗口是的话就续不是就退出轻量又直观。服务模式适合证书数量多、希望常驻内存的场景但它会一直占一个进程出了问题更难感知。两者对比如下对比项计划任务Windows 服务资源占用每天短暂运行后退出常驻后台故障可见性看任务上次运行结果看服务状态和日志适用规模几台机器、几十张证书证书量大、需要集中管理排查难度直观结果码清晰需查服务日志手动创建计划任务的命令大概长这样注册成每天上午 9 点运行一次# 注册每日计划任务运行续期命令 schtasks /Create /TN win-acme renew /TR C:\tools\win-acme\win-acme.exe --renew --quiet /SC DAILY /ST 09:00 /RU SYSTEM /RL HIGHEST注意/RU SYSTEM用的是系统账号和向导默认一致。程序内部自己会做随机延迟避免大量机器在同一时刻挤向 ACME 服务所以任务时间不用刻意错峰。--renew参数让程序进入续期检查模式只处理到期前RenewalDays天内的证书不做新增。三个最容易翻车的坑按我排障的真实频率排个序基本都在下面。4.2 坑一HTTP 验证报 404日志里没有任何有效线索现象--validation http跑签发或续期日志里出现类似 404 或 could not fetch 的错误验证一直失败。程序日志行数不少但翻来覆去就是那几句看不出具体卡在哪。原因八成是 80 端口上跑的并不是你以为的那个服务。要么是另一个 Web 服务占着 80ACME 服务端的验证请求打到了别的程序上返回 404要么是程序在站点根目录下创建验证临时目录时没有写权限文件没生成成功。这两类问题日志里都不会有明确提示因为它只能看到拿不到该拿的内容。解决先确认 80 端口监听者是谁。netstat -ano | findstr :80看最后一列 PID去任务管理器确认这个进程是不是预期中的 Web 服务。如果不是停掉冲突服务或换成 TLS-ALPN-01 验证绕开 80。如果是 IIS再确认验证目录权限——程序默认会在站点根目录放临时验证文件IIS 应用池账号需要有写权限。我在真实环境踩过最隐蔽的一版杀毒软件把验证文件当可疑文件隔离了导致验证时 404折腾半天才在隔离区里找到文件。遇到 404 且网络、端口都正常时记得看一眼安全软件的隔离列表。4.3 坑二DNS 验证总是超时TXT 记录却已经存在现象用 DNS-01 验证程序报超时或者提示找不到挑战记录。你手工去域名解析里看TXT 记录明明已经在了解析也查得到就是验证不过。原因这是 DNS 验证里最像玄学的一种情况。常见根因有三个第一用的 DNS 插件和你的服务商对不上或者插件版本太老提交 TXT 记录时用的是另一个 API 端点第二API 密钥权限不足能读域名信息但不能写记录程序误以为提交成功了第三验证超时设置太短TXT 记录从提交到全球生效需要时间程序在超时时间内没等到它出现。解决先确认插件确实加载了。pluggable包的好处是插件齐全但齐全不代表自动选中交互式配置时会让你选 DNS 服务商脚本化时要确保options.json里写的是你服务商的插件名而不是默认的另一个。然后检查 API 密钥权限至少要有该域名的解析记录读写权限。最后把验证超时时间调大一些这个参数在不同版本里叫法不太一样查--help输出里的 timeout 相关项。注意有些服务商修改记录后几秒就能查到有些要一两分钟。遇到超时别反复重试同一个命令先手工加一条 TXT 记录测一下生效速度心里有底再跑。4.4 坑三续期成功了IIS 站点的绑定还是旧证书现象证书库里的证书已经更新NotAfter是新的日期但打开 IIS 站点绑定看证书哈希还是旧的那串。用户访问站点时浏览器提示证书过期。续期明明显示成功线上却在报错。原因这是存储方式没配对的问题。续期时程序会用之前保存的签发配置如果最初签发时--store只有certificate续期就不会去动 IIS 绑定证书库更新了站点绑定的还是旧证书。还有一种情况是站点有多个绑定http 和 https 各一条或者多个域名各自绑定程序只更新了其中一个其他绑定的证书哈希没有跟着刷新。解决两手都做。第一把签发配置里的存储改成组合方式让后续续期同时更新证书库和 IIS 绑定# 强制更新证书并写入证书库 IIS 绑定 win-acme.exe --renew --force --store certificate,iis --quiet第二检查该站点的全部绑定把漏掉的补上Import-Module WebAdministration Get-WebBinding -Name Default Web Site | Select-Object protocol, bindingInformation, certificateHash如果确认所有绑定都指向新证书但客户端还是报错多半是浏览器缓存或中间层缓存了旧证书链刷新或等缓存过期即可。最极端的兜底手段是iisreset重启整个 Web 服务但这是最后一个招别一上来就用生产环境重启的动静太大。5. 进阶用法插件扩展、批量签发与验证习惯5.1 插件的边界pluggable 比基础版多了什么pluggable的插件目录决定了工具的能力边界。除了前文用到的 HTTP 验证和证书库存储这里还能装输出格式插件和更多验证插件。比如把证书输出成 PEM 给非 Windows 服务用或者对接各种 DNS 服务商的 API。理解插件机制后你会明白一个关键点插件的存在是为了让这套工具适配你已有的基础设施而不是让你去迁就工具。选插件时先确认你手里的 API 密钥类型和插件文档对得上这是避免交付时翻车的最后一道防线。5.2 批量签发的脚本姿势循环调用与配置复用机器多了以后一张张交互式签发不现实。我的做法是把站点清单写进数组循环调用# 批量签发定义站点清单后循环调用 $targets ( { SiteId 1; Hosts mail.example.com }, { SiteId 2; Hosts portal.example.com,www.example.com } ) foreach ($t in $targets) { .\win-acme.exe --source iis --siteid $t.SiteId --host $t.Hosts --validation http --store certificate,iis --accepttos --quiet }逻辑很简单每次循环针对一个站点发起签发--source iis让它自动读取站点绑定存储用certificate,iis组合。跑完一批后程序会把每张证书的续期配置写进backup目录之后全局那一个计划任务会统一接管所有证书的续期不需要为每张证书单独建任务。这个设计是它最省心的地方。5.3 我的验证习惯三分钟确认续期真的跑通自动化之后我每个季度会做一次三分钟巡检看计划任务上次运行结果是不是 0看logs目录有没有异常堆栈抽查一两张证书的NotAfter是否已经滚动到新周期。整套命令就三行跑完心里就有底。多年养成的习惯是每次批量操作前先看一眼backup目录里配置文件的修改时间确认续期不是静默失败升级版本前先备份settings.json和整个backup目录这是唯一不会让你后悔的准备工作。希望帮到你。本文还有配套的精品资源点击获取