前阵子几个平台的公告邮件几乎同时进来内容都指向同一件事SSL证书的签发时长要调整了。有的写着“新签发证书有效期调整为90天”有的写着“免费证书支持自动续期”看着像例行通知实际操作起来才发现影响不小。很多技术群里也在讨论“以后是不是每个季度都得换一次证书”“手动续期还忙得过来吗”说实话这确实是这些年SSL证书领域最值得关注的一次规则变化。这篇文章打算把“SSL证书签发时长调整”这件事从头到尾拆开讲。它调整了什么、为什么这么调、对我们手里的站点和业务会产生哪些影响以及证书续期周期变短之后申请、部署、自动化、排错这些环节应该怎么跟着改。不管你是个人站点的管理员还是公司里管着一批服务器的运维这篇文章都应该能帮你少踩几个坑。1. 签发时长调整到底调了什么从一年期到90天的行业逻辑1.1 通知背后是行业规则在变不只是平台行为很多人看到“SSL证书签发时长调整通知”时第一反应是“某个平台又改规则了”。实际上这是整个互联网证书信任体系在同步往前走。过去这些年公开信任的SSL/TLS证书有效期一直在缩短很早以前证书可以用好几年后来CA/Browser Forum浏览器证书标准组织通过投票把公开信任证书的最长期限压到398天也就是大家常说的13个月再到现在各大CA和服务商开始把新签证书的有效期往90天方向推。你收到通知说明你的证书服务商正在跟进这套节奏。这不是一家公司的决定而是浏览器厂商、CA机构、云服务商共同推动的结果。如果做网站的人对证书有效期没有概念这里先打个比方SSL证书就像是你网站的“身份证”浏览器访问网站时先验证这张证是否在有效期内是否由可信机构签发。以前这张证能用一年甚至更久现在慢慢变成只能用三个月过期就得重新办。实际操作中这意味着以前一年只要操心一次的事情以后每个季度都要处理一次。如果手里只有一两个域名还好要是管着几十个域名靠人力去记、去续很快会出乱子。1.2 为什么证书有效期越短反而越安全把有效期缩短到90天表面上看是增加麻烦背后其实是安全逻辑在推动。第一私钥泄漏风险被压缩。证书的安全取决于对应私钥是否保密。有效期越长私钥一旦泄漏攻击者能利用这个证书“合法伪装”的时间窗口就越长。短有效期相当于给私钥加了一个自动失效机制就算私钥被偷最坏也只有三个月左右的利用期而不是一年。第二吊销机制本身有滞后性。现在常用的CRL证书吊销列表和OCSP在线证书状态协议都不是实时生效的存在缓存和同步窗口。短有效期能在吊销机制跟不上的时候用自然过期来兜底。第三自动化签发已经成熟。Lets Encrypt这类CA把ACME协议带起来之后证书申请、验证、签发、部署全流程都能自动完成。有效期缩短在自动化面前不算负担反而让整个生态可以更频繁地轮换密钥安全水位自然更高。1.3 这次调整对不同角色的影响范围这次调整不是一刀切不同角色的感受差异很大。CA厂商调整的是签发策略从签发策略源头把有效期卡死。云厂商跟进的是产品策略比如免费证书从1年变成3个月同时把自动续期功能补上。对于企业和个人站长来说影响最直接证书续期频率变高了如果之前是纯手工续期就必须认真考虑自动化工具否则很容易漏掉某个域名导致网站突然打不开。这里多说一句有不少人很关心“阿里云SSL证书免费续期”这类操作。确实免费证书有效期缩短后云厂商一般会提供自动续期入口但前提是你得提前把域名验证配置好否则到了续期窗口一样会失败。不要把“自动续期”理解成“什么都不用管”它只负责在你配置正确的基础上自动执行配置错误它不会帮你纠正。2. 证书签发周期变短后生命周期管理必须改的3个细节2.1 有效期、续期窗口、信任链这三个参数先搞清楚在讨论怎么应对90天周期之前有几个证书基本参数必须重新理一遍。有效期Validity是证书合法使用的时间段由签发时CA设置目前主流是90天或398天。续期窗口不是所有CA都叫这个名字但大致是指“允许你申请新证书替换旧证书”的时间范围比如Lets Encrypt允许在证书过期前30天内续期有些商业CA会放宽到60天。信任链则是指根证书、中间证书、叶子证书的层级关系部署证书时只把叶子证书放上去是不够的中间证书必须完整配置否则客户端会报“证书链不完整”。这里有一个很常见的误区以为证书快到期才需要处理。实际上如果你用的是90天证书最好在过期前15天左右就完成续期动作留出足够时间处理突发问题。我把新旧周期对比放这里一眼就能看出差别对比项一年期证书90天证书签发时最长有效期398天左右90天建议续期提前量30天左右15天左右是否适合纯手工维护勉强可以基本不现实对自动化工具依赖度低高私钥泄漏风险窗口较长较短吊销机制兜底效果一般更好2.2 证书生命周期管理到底在管什么很多运维同学平时说“证书管理”其实就是“到期换个证书”这是把生命周期管理想窄了。完整的证书生命周期至少包含五件事签发、部署、监控、续期/替换、吊销。签发阶段要完成域名所有权验证常见的有HTTP验证和DNS验证。部署阶段要把证书安装到Nginx、Apache、IIS、负载均衡、K8s Ingress、CDN等不同入口。监控阶段要能提前发现“证书快过期了”“证书链不完整”“证书和域名不匹配”等问题。续期/替换阶段要保证新旧证书平滑切换不中断线上服务。吊销阶段则是遇到私钥泄漏、域名废弃、证书误签发等情况时主动让CA撤销这张证书。这五个环节里最容易出问题的是监控。因为签发、部署、续期都有明确动作做完就结束了唯独监控是持续性的。90天周期下监控的粒度要从“按月看”变成“按周看”最好是直接上自动化告警证书剩余天数低于阈值就提醒。2.3 台账和提醒机制得跟着改造以前一年期证书时代很多团队的做法是搞一个Excel表把域名、到期时间、证书类型记下来快到期时手动去平台续一下。这套办法在证书数量少、有效期长的时候还能跑但进入90天周期之后基本撑不住。我建议把台账字段升级成这些域名、证书类型、签发CA、签发时间、到期时间、部署位置、验证方式、当前状态、负责人、备注。每个字段都有存在的意义尤其是“验证方式”和“部署位置”90天周期下一次续期可能涉及多个入口验证方式没记录清楚到续期窗口就得重新排查。提醒机制也别只依赖邮件了证书到期告警可以接到钉钉、企业微信、Slack这类即时通讯工具甚至可以接到监控系统里。我见过不少团队因为证书告警邮件被埋没在垃圾邮件堆里结果域名过期几小时才发现用户访问直接报安全警告损失很被动。3. 90天证书怎么落地自动续期、Nginx部署与校验实操3.1 用ACME协议搭建自动续期告别手工换证书谈到90天证书的应对方案我最推荐的做法是全面转向ACME协议自动签发。ACME全称是Automated Certificate Management Environment是一个用于证书自动申请、续期、吊销的标准化协议。现在主流的免费CA基本都支持Lets Encrypt、ZeroSSL、Google Trust Services都在用。以acme.sh为例它是我用过最顺手的ACME客户端之一安装只需要一行命令curl https://get.acme.sh | sh -s emailyourexample.com安装完成后申请证书最常用的是DNS验证方式。DNS验证的优势在于可以签发泛域名证书也就是一张证书覆盖example.com和*.example.com。如果你的域名DNS托管在阿里云可以这样写acme.sh --issue --dns dns_ali -d example.com -d *.example.com这里的dns_ali是acme.sh内置的阿里云DNS API插件使用前需要先导出阿里云的AccessKey ID和Secretexport Ali_Key你的AccessKey ID export Ali_Secret你的AccessKey Secret使用DNS API方式有一个很大的好处不需要在服务器上开放80端口也不会被防火墙拦截纯靠DNS解析记录完成验证。对安全性要求高的生产环境这是最稳的路径。证书签发完成后acme.sh会把证书文件放到~/.acme.sh/域名/目录下里面通常有fullchain.cer和域名.key两个核心文件。部署到Nginx时把这两个文件路径配好就行。3.2 Nginx下证书更新后的平滑重载证书签发好之后Nginx配置是重头戏。我直接给一个最简配置示例server { listen 443 ssl http2; server_name example.com; ssl_certificate /root/.acme.sh/example.com/fullchain.cer; ssl_certificate_key /root/.acme.sh/example.com/example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; }配置完成后先用nginx -t检查语法确认无误再执行nginx -s reload。这里有一个我踩过的坑acme.sh自动续期后默认会执行--reloadcmd但如果你没配置这个参数新证书文件虽然已经生成Nginx还在用旧证书。所以安装证书时最好带上重载命令或者单独设置acme.sh --install-cert -d example.com \ --key-file /etc/nginx/ssl/example.com.key \ --fullchain-file /etc/nginx/ssl/example.com.pem \ --reloadcmd nginx -s reload这样每次自动续期完成后Nginx会自动重载证书不需要人工干预。acme.sh安装时默认会配置一个crontab定时任务每天检查一次证书有效期发现快到期就自动续期。可以用crontab -l确认任务存在0 0 * * * /root/.acme.sh/acme.sh --cron --home /root/.acme.sh /dev/null3.3 用openssl快速校验证书有效期和信任链证书部署完成后第一时间要做校验别等用户访问报了错再处理。我最常用的校验命令有两个。查本地证书有效期openssl x509 -in /etc/nginx/ssl/example.com.pem -noout -dates查线上站点正在使用的证书有效期echo | openssl s_client -connect example.com:443 -servername example.com 2/dev/null | openssl x509 -noout -dates校验证书链是否完整openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt /etc/nginx/ssl/example.com.pem如果返回OK说明证书链没问题。如果返回unable to get local issuer certificate说明中间证书没配全需要把CA下发的中间证书拼到fullchain里。这一步非常关键很多证书信任报错都是这个原因引起的。3.4 测试环境和抓包工具的证书处理证书周期变短影响的还不只是线上服务器。本地开发、测试、抓包调试环境里的证书问题也会变得密集。我在实践里经常被问到这几个工具的问题这里一并说清楚。JMeter做HTTPS接口压测时如果服务端使用的是自签名证书或内部CA证书JMeter会报SSL证书验证失败之类的问题。解决方式有两个一是把服务端CA证书导入Java的cacerts信任库二是在JMeter的HTTP Request Sampler里勾选Use preemptive authentication并配置客户端证书。对于验证服务端证书的场景我建议走导入信任库的方式不要简单粗暴地关掉认证。Charles和Fiddler是抓包利器但它们的核心机制是在本地生成一个CA根证书再动态为每个HTTPS域名签发临时证书。如果你在手机上抓包发现“证书不受信任”通常就是手机没安装Charles或Fiddler的根证书。浏览器抓包时提示证书错误可能是你忘了把根证书安装到系统信任区而不是“抓包工具坏了”。Burp Suite在Android上抓HTTPS包时需要把Burp的CA证书导出成DER格式然后传到手机里安装。这里有个坑Android 7以上系统默认不信任用户安装的CA证书只信任系统证书。如果只是调试普通App安装到用户信任区通常够用要是App做了SSL Pinning证书固定那就得另想办法比如用Frida绕过或修改App逻辑这属于攻防范畴不在本文讨论范围内。mitmproxy安装证书的路径比较统一启动mitmproxy后手机或浏览器访问mitm.it按平台下载对应证书安装即可。vCenter证书过期也是高频问题。vCenter的机器证书、STS证书过期后登录vSphere Client会直接报证书错误升级或调整vCenter时都容易触发。处理思路是先备份配置再通过vCenter Certificate Manager重新生成或续签相关证书注意每个组件的证书要按顺序处理别漏了。4. 证书调整期间最常见的报错与排查思路4.1 证书验证失败类报错怎么定位证书有效期缩短后很多人会频繁遇到各种报错。我把实际处理过的高频错误整理一下。exception in invoking authentication handler [ssl: certificate_verify_failed]这类报错集中出现在Java应用、Git客户端、Jenkins等工具访问HTTPS服务时。原因通常是信任库不完整或者服务端证书链有问题。排查时先确认浏览器访问是否正常如果浏览器正常但Java报错说明Java的cacerts里没有对应CA如果浏览器也报错那就是服务端证书链不完整。openssl: error:0A000126: ssl routines::unexpected eof while reading这个报错看着吓人实际多数是TLS握手过程中连接被强制断开。常见原因有客户端和服务端的TLS版本不匹配、服务端配置了过高的加密套件要求、中间防火墙或负载均衡主动断连。排查时先看Nginx错误日志再确认客户端支持的最低TLS版本。SSL recv:服务器断开连接, errorcode: 6这和上面类似多半出现在Windows或某些老客户端访问新配置的TLS服务时。原因大多指向TLS版本过旧比如客户端只支持TLS 1.0而服务端只开放TLS 1.2以上。小程序显示客户端ssl握手失败小程序对服务端TLS配置要求比较严格常见原因是服务端只支持TLS 1.0/1.1、证书链不完整、使用了不支持的加密套件。我处理过的案例中90%都是证书链不完整或TLS版本过低把Nginx配置改成只启用TLS 1.2和TLS 1.3后问题基本消失。4.2 自动续期和部署的典型问题90天周期下自动续期能不能跑通直接决定你是在“喝茶”还是在“救火”。下面这几个问题我几乎每个季度都会遇到。自动续期静默失败。acme.sh的cron任务如果没被正确配置或者DNS API凭据过期续期会在后台静默失败到证书快过期了才被发现。解决方式在监控系统里加上证书剩余有效期检查不要只依赖ACME客户端的日志。DNS验证记录被误删。DNS API方式申请证书时acme.sh会自动添加一条TXT记录验证完成后自动删除。但如果你同时用着CDN、DNS解析管理工具可能会把这条TXT记录误判为“多余记录”清理掉导致续期失败。建议在crontab任务跑完后检查一下域名解析记录确认没有残留TXT记录被误加或误删。证书更新了但业务还是旧证书。这种情况多发生在证书文件被复制到了多个位置。比如Nginx用的/etc/nginx/ssl/下的证书但实际配置里写的是另一个路径。排查方法很简单ls -l对比Nginx配置中的路径和acme.sh实际生成文件的时间戳确认是否同一份文件。Windows下证书文件被占用。IIS或某些Windows服务会长期锁住证书文件导致更新时无法覆盖。解决办法是先停掉对应站点替换证书文件再启动站点或者使用IIS的“导入”功能更新证书不要直接覆盖文件。Git客户端报error setting certificate file: d:/git/mingw64/etc/ssl/certs/ca-bundle.crt。这个报错看着是“证书文件路径不对”实际是Git for Windows自带的CA证书库太旧或缺失。解决办法是更新Git for Windows或者用git config --global http.sslCAInfo指定新的CA证书路径。如果是在Windows上操作还经常伴随ssl send error:00002746这类错误多半是代理设置或防火墙做了TLS拦截检查系统代理设置能省很多时间。Linux下Java应用报disabling truststore since ssl support is missing。这个报错通常是JRE缺少cacerts信任库或路径配置不对。最直接的解决办法是确认JAVA_HOME指向的JRE镜像里确实有lib/security/cacerts文件没有就从JDK里拷贝一份再keytool -list验证。4.3 排查速查表报错/现象常见原因处理思路certificate_verify_failed证书链不完整、信任库缺少CA补全中间证书导入CA到信任库unexpected eof while readingTLS版本/加密套件不匹配统一TLS 1.2以上查看Nginx日志SSL recv:服务器断开连接 errorcode 6客户端TLS版本过旧升级客户端或调服务端兼容性小程序SSL握手失败证书链不完整或TLS版本低配置完整链启用TLS 1.2/1.3证书更新后业务仍显示旧证书证书文件路径不对或未reload检查路径、执行nginx -s reload自动续期静默失败cron未运行、DNS API凭据失效检查crontab增加有效期监控Git报ca-bundle.crt错误Git自带CA库缺失或过期更新Git for Windows重设http.sslCAInfoJava报disabling truststorecacerts路径错误检查JAVA_HOME补齐cacerts文件Windows Server严重警告代码70TLS协议参数不匹配检查组策略中的TLS版本和密码套件证书使用弱哈希算法证书签名算法为SHA-1向CA申请重新签发SHA-256证书4.4 关于CVE-2005-4900和弱哈希算法修复最后补充一个容易混淆的点。检测类工具经常会报“SSL证书使用了弱Hash算法(CVE-2005-4900)”这其实是证书签名算法用了SHA-1的问题。SHA-1算法早在多年前就被证明存在碰撞风险主流CA早就停止签发基于SHA-1的证书了。但如果你的服务端证书是那种很老的自签名证书或者某些内部系统里旧证书还在用SHA-1签名安全检测就会报这个漏洞。修复方式不复杂用openssl生成新私钥和证书签名请求改用SHA-256签名然后让CA重新签发证书或者对于自签名证书直接用SHA-256生成新的自签证书。生成CSR时使用openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr这里默认使用的摘要算法已经是SHA-256不用担心再踩SHA-1的坑。我个人在实际处理这几个季度的证书调整中的体会是90天证书周期并不会带来想象中那么大的运维负担前提是你愿意在前两周把自动化链条搭起来。第一次把acme.sh、DNS API、Nginx reload、监控告警串起来之后后面每个季度基本就是看一轮告警、确认一下续期结果而已。如果你现在还在用“一年一续”的旧思路建议从最近一次证书到期开始就切换到自动续期模式别等到通知里写明的调整日期临近再临时抱佛脚。这个内容后续还可以这样扩展如果你的业务里有很多不同平台的证书可以考虑在统一监控里加上证书到期指标比如用Prometheus的blackbox_exporter定时探测HTTPS端点的证书剩余天数到期前自动告警。这样就算CA把有效期继续缩短到45天甚至更短证书轮换也会变成一个无需人工关心的后台任务你的注意力可以放在真正需要判断的业务问题上。
SSL证书90天有效期调整：自动续期与运维实战指南
前阵子几个平台的公告邮件几乎同时进来内容都指向同一件事SSL证书的签发时长要调整了。有的写着“新签发证书有效期调整为90天”有的写着“免费证书支持自动续期”看着像例行通知实际操作起来才发现影响不小。很多技术群里也在讨论“以后是不是每个季度都得换一次证书”“手动续期还忙得过来吗”说实话这确实是这些年SSL证书领域最值得关注的一次规则变化。这篇文章打算把“SSL证书签发时长调整”这件事从头到尾拆开讲。它调整了什么、为什么这么调、对我们手里的站点和业务会产生哪些影响以及证书续期周期变短之后申请、部署、自动化、排错这些环节应该怎么跟着改。不管你是个人站点的管理员还是公司里管着一批服务器的运维这篇文章都应该能帮你少踩几个坑。1. 签发时长调整到底调了什么从一年期到90天的行业逻辑1.1 通知背后是行业规则在变不只是平台行为很多人看到“SSL证书签发时长调整通知”时第一反应是“某个平台又改规则了”。实际上这是整个互联网证书信任体系在同步往前走。过去这些年公开信任的SSL/TLS证书有效期一直在缩短很早以前证书可以用好几年后来CA/Browser Forum浏览器证书标准组织通过投票把公开信任证书的最长期限压到398天也就是大家常说的13个月再到现在各大CA和服务商开始把新签证书的有效期往90天方向推。你收到通知说明你的证书服务商正在跟进这套节奏。这不是一家公司的决定而是浏览器厂商、CA机构、云服务商共同推动的结果。如果做网站的人对证书有效期没有概念这里先打个比方SSL证书就像是你网站的“身份证”浏览器访问网站时先验证这张证是否在有效期内是否由可信机构签发。以前这张证能用一年甚至更久现在慢慢变成只能用三个月过期就得重新办。实际操作中这意味着以前一年只要操心一次的事情以后每个季度都要处理一次。如果手里只有一两个域名还好要是管着几十个域名靠人力去记、去续很快会出乱子。1.2 为什么证书有效期越短反而越安全把有效期缩短到90天表面上看是增加麻烦背后其实是安全逻辑在推动。第一私钥泄漏风险被压缩。证书的安全取决于对应私钥是否保密。有效期越长私钥一旦泄漏攻击者能利用这个证书“合法伪装”的时间窗口就越长。短有效期相当于给私钥加了一个自动失效机制就算私钥被偷最坏也只有三个月左右的利用期而不是一年。第二吊销机制本身有滞后性。现在常用的CRL证书吊销列表和OCSP在线证书状态协议都不是实时生效的存在缓存和同步窗口。短有效期能在吊销机制跟不上的时候用自然过期来兜底。第三自动化签发已经成熟。Lets Encrypt这类CA把ACME协议带起来之后证书申请、验证、签发、部署全流程都能自动完成。有效期缩短在自动化面前不算负担反而让整个生态可以更频繁地轮换密钥安全水位自然更高。1.3 这次调整对不同角色的影响范围这次调整不是一刀切不同角色的感受差异很大。CA厂商调整的是签发策略从签发策略源头把有效期卡死。云厂商跟进的是产品策略比如免费证书从1年变成3个月同时把自动续期功能补上。对于企业和个人站长来说影响最直接证书续期频率变高了如果之前是纯手工续期就必须认真考虑自动化工具否则很容易漏掉某个域名导致网站突然打不开。这里多说一句有不少人很关心“阿里云SSL证书免费续期”这类操作。确实免费证书有效期缩短后云厂商一般会提供自动续期入口但前提是你得提前把域名验证配置好否则到了续期窗口一样会失败。不要把“自动续期”理解成“什么都不用管”它只负责在你配置正确的基础上自动执行配置错误它不会帮你纠正。2. 证书签发周期变短后生命周期管理必须改的3个细节2.1 有效期、续期窗口、信任链这三个参数先搞清楚在讨论怎么应对90天周期之前有几个证书基本参数必须重新理一遍。有效期Validity是证书合法使用的时间段由签发时CA设置目前主流是90天或398天。续期窗口不是所有CA都叫这个名字但大致是指“允许你申请新证书替换旧证书”的时间范围比如Lets Encrypt允许在证书过期前30天内续期有些商业CA会放宽到60天。信任链则是指根证书、中间证书、叶子证书的层级关系部署证书时只把叶子证书放上去是不够的中间证书必须完整配置否则客户端会报“证书链不完整”。这里有一个很常见的误区以为证书快到期才需要处理。实际上如果你用的是90天证书最好在过期前15天左右就完成续期动作留出足够时间处理突发问题。我把新旧周期对比放这里一眼就能看出差别对比项一年期证书90天证书签发时最长有效期398天左右90天建议续期提前量30天左右15天左右是否适合纯手工维护勉强可以基本不现实对自动化工具依赖度低高私钥泄漏风险窗口较长较短吊销机制兜底效果一般更好2.2 证书生命周期管理到底在管什么很多运维同学平时说“证书管理”其实就是“到期换个证书”这是把生命周期管理想窄了。完整的证书生命周期至少包含五件事签发、部署、监控、续期/替换、吊销。签发阶段要完成域名所有权验证常见的有HTTP验证和DNS验证。部署阶段要把证书安装到Nginx、Apache、IIS、负载均衡、K8s Ingress、CDN等不同入口。监控阶段要能提前发现“证书快过期了”“证书链不完整”“证书和域名不匹配”等问题。续期/替换阶段要保证新旧证书平滑切换不中断线上服务。吊销阶段则是遇到私钥泄漏、域名废弃、证书误签发等情况时主动让CA撤销这张证书。这五个环节里最容易出问题的是监控。因为签发、部署、续期都有明确动作做完就结束了唯独监控是持续性的。90天周期下监控的粒度要从“按月看”变成“按周看”最好是直接上自动化告警证书剩余天数低于阈值就提醒。2.3 台账和提醒机制得跟着改造以前一年期证书时代很多团队的做法是搞一个Excel表把域名、到期时间、证书类型记下来快到期时手动去平台续一下。这套办法在证书数量少、有效期长的时候还能跑但进入90天周期之后基本撑不住。我建议把台账字段升级成这些域名、证书类型、签发CA、签发时间、到期时间、部署位置、验证方式、当前状态、负责人、备注。每个字段都有存在的意义尤其是“验证方式”和“部署位置”90天周期下一次续期可能涉及多个入口验证方式没记录清楚到续期窗口就得重新排查。提醒机制也别只依赖邮件了证书到期告警可以接到钉钉、企业微信、Slack这类即时通讯工具甚至可以接到监控系统里。我见过不少团队因为证书告警邮件被埋没在垃圾邮件堆里结果域名过期几小时才发现用户访问直接报安全警告损失很被动。3. 90天证书怎么落地自动续期、Nginx部署与校验实操3.1 用ACME协议搭建自动续期告别手工换证书谈到90天证书的应对方案我最推荐的做法是全面转向ACME协议自动签发。ACME全称是Automated Certificate Management Environment是一个用于证书自动申请、续期、吊销的标准化协议。现在主流的免费CA基本都支持Lets Encrypt、ZeroSSL、Google Trust Services都在用。以acme.sh为例它是我用过最顺手的ACME客户端之一安装只需要一行命令curl https://get.acme.sh | sh -s emailyourexample.com安装完成后申请证书最常用的是DNS验证方式。DNS验证的优势在于可以签发泛域名证书也就是一张证书覆盖example.com和*.example.com。如果你的域名DNS托管在阿里云可以这样写acme.sh --issue --dns dns_ali -d example.com -d *.example.com这里的dns_ali是acme.sh内置的阿里云DNS API插件使用前需要先导出阿里云的AccessKey ID和Secretexport Ali_Key你的AccessKey ID export Ali_Secret你的AccessKey Secret使用DNS API方式有一个很大的好处不需要在服务器上开放80端口也不会被防火墙拦截纯靠DNS解析记录完成验证。对安全性要求高的生产环境这是最稳的路径。证书签发完成后acme.sh会把证书文件放到~/.acme.sh/域名/目录下里面通常有fullchain.cer和域名.key两个核心文件。部署到Nginx时把这两个文件路径配好就行。3.2 Nginx下证书更新后的平滑重载证书签发好之后Nginx配置是重头戏。我直接给一个最简配置示例server { listen 443 ssl http2; server_name example.com; ssl_certificate /root/.acme.sh/example.com/fullchain.cer; ssl_certificate_key /root/.acme.sh/example.com/example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; }配置完成后先用nginx -t检查语法确认无误再执行nginx -s reload。这里有一个我踩过的坑acme.sh自动续期后默认会执行--reloadcmd但如果你没配置这个参数新证书文件虽然已经生成Nginx还在用旧证书。所以安装证书时最好带上重载命令或者单独设置acme.sh --install-cert -d example.com \ --key-file /etc/nginx/ssl/example.com.key \ --fullchain-file /etc/nginx/ssl/example.com.pem \ --reloadcmd nginx -s reload这样每次自动续期完成后Nginx会自动重载证书不需要人工干预。acme.sh安装时默认会配置一个crontab定时任务每天检查一次证书有效期发现快到期就自动续期。可以用crontab -l确认任务存在0 0 * * * /root/.acme.sh/acme.sh --cron --home /root/.acme.sh /dev/null3.3 用openssl快速校验证书有效期和信任链证书部署完成后第一时间要做校验别等用户访问报了错再处理。我最常用的校验命令有两个。查本地证书有效期openssl x509 -in /etc/nginx/ssl/example.com.pem -noout -dates查线上站点正在使用的证书有效期echo | openssl s_client -connect example.com:443 -servername example.com 2/dev/null | openssl x509 -noout -dates校验证书链是否完整openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt /etc/nginx/ssl/example.com.pem如果返回OK说明证书链没问题。如果返回unable to get local issuer certificate说明中间证书没配全需要把CA下发的中间证书拼到fullchain里。这一步非常关键很多证书信任报错都是这个原因引起的。3.4 测试环境和抓包工具的证书处理证书周期变短影响的还不只是线上服务器。本地开发、测试、抓包调试环境里的证书问题也会变得密集。我在实践里经常被问到这几个工具的问题这里一并说清楚。JMeter做HTTPS接口压测时如果服务端使用的是自签名证书或内部CA证书JMeter会报SSL证书验证失败之类的问题。解决方式有两个一是把服务端CA证书导入Java的cacerts信任库二是在JMeter的HTTP Request Sampler里勾选Use preemptive authentication并配置客户端证书。对于验证服务端证书的场景我建议走导入信任库的方式不要简单粗暴地关掉认证。Charles和Fiddler是抓包利器但它们的核心机制是在本地生成一个CA根证书再动态为每个HTTPS域名签发临时证书。如果你在手机上抓包发现“证书不受信任”通常就是手机没安装Charles或Fiddler的根证书。浏览器抓包时提示证书错误可能是你忘了把根证书安装到系统信任区而不是“抓包工具坏了”。Burp Suite在Android上抓HTTPS包时需要把Burp的CA证书导出成DER格式然后传到手机里安装。这里有个坑Android 7以上系统默认不信任用户安装的CA证书只信任系统证书。如果只是调试普通App安装到用户信任区通常够用要是App做了SSL Pinning证书固定那就得另想办法比如用Frida绕过或修改App逻辑这属于攻防范畴不在本文讨论范围内。mitmproxy安装证书的路径比较统一启动mitmproxy后手机或浏览器访问mitm.it按平台下载对应证书安装即可。vCenter证书过期也是高频问题。vCenter的机器证书、STS证书过期后登录vSphere Client会直接报证书错误升级或调整vCenter时都容易触发。处理思路是先备份配置再通过vCenter Certificate Manager重新生成或续签相关证书注意每个组件的证书要按顺序处理别漏了。4. 证书调整期间最常见的报错与排查思路4.1 证书验证失败类报错怎么定位证书有效期缩短后很多人会频繁遇到各种报错。我把实际处理过的高频错误整理一下。exception in invoking authentication handler [ssl: certificate_verify_failed]这类报错集中出现在Java应用、Git客户端、Jenkins等工具访问HTTPS服务时。原因通常是信任库不完整或者服务端证书链有问题。排查时先确认浏览器访问是否正常如果浏览器正常但Java报错说明Java的cacerts里没有对应CA如果浏览器也报错那就是服务端证书链不完整。openssl: error:0A000126: ssl routines::unexpected eof while reading这个报错看着吓人实际多数是TLS握手过程中连接被强制断开。常见原因有客户端和服务端的TLS版本不匹配、服务端配置了过高的加密套件要求、中间防火墙或负载均衡主动断连。排查时先看Nginx错误日志再确认客户端支持的最低TLS版本。SSL recv:服务器断开连接, errorcode: 6这和上面类似多半出现在Windows或某些老客户端访问新配置的TLS服务时。原因大多指向TLS版本过旧比如客户端只支持TLS 1.0而服务端只开放TLS 1.2以上。小程序显示客户端ssl握手失败小程序对服务端TLS配置要求比较严格常见原因是服务端只支持TLS 1.0/1.1、证书链不完整、使用了不支持的加密套件。我处理过的案例中90%都是证书链不完整或TLS版本过低把Nginx配置改成只启用TLS 1.2和TLS 1.3后问题基本消失。4.2 自动续期和部署的典型问题90天周期下自动续期能不能跑通直接决定你是在“喝茶”还是在“救火”。下面这几个问题我几乎每个季度都会遇到。自动续期静默失败。acme.sh的cron任务如果没被正确配置或者DNS API凭据过期续期会在后台静默失败到证书快过期了才被发现。解决方式在监控系统里加上证书剩余有效期检查不要只依赖ACME客户端的日志。DNS验证记录被误删。DNS API方式申请证书时acme.sh会自动添加一条TXT记录验证完成后自动删除。但如果你同时用着CDN、DNS解析管理工具可能会把这条TXT记录误判为“多余记录”清理掉导致续期失败。建议在crontab任务跑完后检查一下域名解析记录确认没有残留TXT记录被误加或误删。证书更新了但业务还是旧证书。这种情况多发生在证书文件被复制到了多个位置。比如Nginx用的/etc/nginx/ssl/下的证书但实际配置里写的是另一个路径。排查方法很简单ls -l对比Nginx配置中的路径和acme.sh实际生成文件的时间戳确认是否同一份文件。Windows下证书文件被占用。IIS或某些Windows服务会长期锁住证书文件导致更新时无法覆盖。解决办法是先停掉对应站点替换证书文件再启动站点或者使用IIS的“导入”功能更新证书不要直接覆盖文件。Git客户端报error setting certificate file: d:/git/mingw64/etc/ssl/certs/ca-bundle.crt。这个报错看着是“证书文件路径不对”实际是Git for Windows自带的CA证书库太旧或缺失。解决办法是更新Git for Windows或者用git config --global http.sslCAInfo指定新的CA证书路径。如果是在Windows上操作还经常伴随ssl send error:00002746这类错误多半是代理设置或防火墙做了TLS拦截检查系统代理设置能省很多时间。Linux下Java应用报disabling truststore since ssl support is missing。这个报错通常是JRE缺少cacerts信任库或路径配置不对。最直接的解决办法是确认JAVA_HOME指向的JRE镜像里确实有lib/security/cacerts文件没有就从JDK里拷贝一份再keytool -list验证。4.3 排查速查表报错/现象常见原因处理思路certificate_verify_failed证书链不完整、信任库缺少CA补全中间证书导入CA到信任库unexpected eof while readingTLS版本/加密套件不匹配统一TLS 1.2以上查看Nginx日志SSL recv:服务器断开连接 errorcode 6客户端TLS版本过旧升级客户端或调服务端兼容性小程序SSL握手失败证书链不完整或TLS版本低配置完整链启用TLS 1.2/1.3证书更新后业务仍显示旧证书证书文件路径不对或未reload检查路径、执行nginx -s reload自动续期静默失败cron未运行、DNS API凭据失效检查crontab增加有效期监控Git报ca-bundle.crt错误Git自带CA库缺失或过期更新Git for Windows重设http.sslCAInfoJava报disabling truststorecacerts路径错误检查JAVA_HOME补齐cacerts文件Windows Server严重警告代码70TLS协议参数不匹配检查组策略中的TLS版本和密码套件证书使用弱哈希算法证书签名算法为SHA-1向CA申请重新签发SHA-256证书4.4 关于CVE-2005-4900和弱哈希算法修复最后补充一个容易混淆的点。检测类工具经常会报“SSL证书使用了弱Hash算法(CVE-2005-4900)”这其实是证书签名算法用了SHA-1的问题。SHA-1算法早在多年前就被证明存在碰撞风险主流CA早就停止签发基于SHA-1的证书了。但如果你的服务端证书是那种很老的自签名证书或者某些内部系统里旧证书还在用SHA-1签名安全检测就会报这个漏洞。修复方式不复杂用openssl生成新私钥和证书签名请求改用SHA-256签名然后让CA重新签发证书或者对于自签名证书直接用SHA-256生成新的自签证书。生成CSR时使用openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr这里默认使用的摘要算法已经是SHA-256不用担心再踩SHA-1的坑。我个人在实际处理这几个季度的证书调整中的体会是90天证书周期并不会带来想象中那么大的运维负担前提是你愿意在前两周把自动化链条搭起来。第一次把acme.sh、DNS API、Nginx reload、监控告警串起来之后后面每个季度基本就是看一轮告警、确认一下续期结果而已。如果你现在还在用“一年一续”的旧思路建议从最近一次证书到期开始就切换到自动续期模式别等到通知里写明的调整日期临近再临时抱佛脚。这个内容后续还可以这样扩展如果你的业务里有很多不同平台的证书可以考虑在统一监控里加上证书到期指标比如用Prometheus的blackbox_exporter定时探测HTTPS端点的证书剩余天数到期前自动告警。这样就算CA把有效期继续缩短到45天甚至更短证书轮换也会变成一个无需人工关心的后台任务你的注意力可以放在真正需要判断的业务问题上。
