证书过期告警邮件躺在邮箱里三天了，后台工单也挂着，我估计有不少人跟我一样，是看到浏览器那把红色小锁才想起来动手。SSL证书续签这事儿，说难不难，但每次做都能遇到点新状况，要么DNS验证卡住，要么替换完Nginx忘了重启，要么证书链不完整被安全体检扫出来。这篇就把阿里云SSL证书从续签到替换的完整流程拆开讲一遍，包括我在实操里踩过的坑和总结出来的排查思路，给同样被证书到期逼到头大的你一份可以直接照做的指南。
1. 续签前先搞清楚三件事，能少走一半弯路
1.1 你的证书到底是哪种类型
很多人打开控制台看到“SSL证书”那个菜单就点进去申请，结果发现能选的证书类型五花八门，一脸懵。这里先跟你捋清楚阿里云证书服务的几个常见类型，因为这直接决定了你续签的路径和周期。
阿里云上能申请的证书大致分三类：免费证书、付费DV证书、付费OV/EV证书。免费证书一般是单域名或通配符域名，有效期最长一年（实际发放时常见的是3个月或1年，取决于当时的活动规则），只能做域名验证（DV），不能申请OV/EV这种带企业身份审核的证书。付费DV证书同样是域名验证，但可以选更长的有效期、支持自动续签、还能开托管部署。OV和EV证书需要提交企业资料做人工审核，有效期可以到一年以上，适合对安全等级有要求的业务系统。
这个分类为什么重要？因为免费证书和付费证书的续签机制完全不同。免费证书到期后不能直接“续签”，只能重新申请一张新证书，然后把旧证书替换掉。付费证书如果开了自动续签，会提前30天左右自动申请新证书并完成验证，你只需要在到期前把新证书下载下来部署即可。我在第3章会详细讲免费证书的重新申请流程，那是大多数中小站点最常用的路径。
1.2 免费证书和付费证书的续签差别
直接上结论：免费证书的“续签”本质是重买，不是延长。因为你无法对一张已签发的证书做“续期”操作，证书有效期是CA机构一次性签发死的，到期即失效。所以阿里云控制台里对免费证书的续签操作，实际流程是：提交一个新的证书申请 → 完成域名验证 → 等待签发 → 下载新证书 → 部署替换。
付费证书则多了一个选项：托管服务。你可以在购买时勾选开启，证书到期前自动完成新证书的申请和验证，省去手工操作。但这个服务不包含“自动部署”，也就是说新证书签发后，你还是需要手动去服务器或负载均衡上替换。别以为开了托管就一劳永逸，我当时第一次用托管服务，到期前几天新证书确实自动签了，但我忘了去OSS和CDN那边更新，结果网站图片服务先报了证书错误，这个教训后面细说。
1.3 续签时间线的最佳规划
我的建议是：不要等到证书到期前一周才动手。原因很简单，免费证书从提交申请到签发，顺利的话几十分钟就下来了，但DNS验证如果加了新的解析记录，生效时间受TTL影响可能长达几分钟到几个小时。更麻烦的是，有些环境你改完DNS还想让解析商的缓存尽快过期，这些都是不确定因素。
我自己习惯的做法是：证书到期前30天就在日历上标好提醒。如果用的是免费证书，到期前15天提交新申请；如果用的是付费证书且开了自动续签，到期前10天检查一下托管状态；到期前3天必须完成新证书的下载和替换。这样即便中途遇到验证失败、审核驳回、服务器配置出错，也有足够的缓冲时间。千万别卡着最后两天弄，一旦某个环节卡壳，网站就真的要在用户面前裸奔了。
2. 续签前的准备工作：域名、服务器、备份一个都别少
2.1 先盘清楚域名和服务器信息
在打开控制台之前，我强烈建议你先花十分钟盘一下手头的资源。你要确认的信息包括：证书对应的域名列表（单域名还是多个域名）、这些域名当前解析到了哪台服务器（IP是不是有变动）、服务器上跑的Web服务是Nginx还是Apache还是IIS、以及证书文件当前存放在哪个路径。
为什么要把这些信息先列出来？因为续签过程中最消耗时间的往往不是申请本身，而是申请完之后的部署环节。我见过太多人证书申请下来之后，在服务器上翻了好半天才找到旧证书放哪儿了，甚至有人同时管着好几台服务器，搞混了证书和域名的对应关系，把A站点的证书部署到了B站点上，排查了大半天才发现。提前列一个清单，写清楚“哪个域名 → 哪台服务器 → 哪个Web服务 → 证书文件路径”，能帮你省下大量时间。
另外，要特别确认一下域名的DNS解析是不是还能正常管理。如果你用的是阿里云域名，直接在云解析DNS控制台操作就行。如果域名是在别家注册的，你需要确保自己还有权限登录那个DNS管理后台，因为后续验证域名所有权要新增TXT记录或修改CNAME记录。
2.2 DNS验证记录的准备
阿里云证书的域名验证主要有两种方式：自动DNS验证和手动DNS验证，部分场景还支持文件验证。
自动DNS验证是前提条件最苛刻但也最省事的方式——要求域名解析托管在阿里云，且当前登录账号对域名有管理权限。满足这两个条件的话，提交申请后阿里云会自动添加一条验证记录，你只需要等待验证通过。不满足条件的话，系统会给你一条TXT记录值，让你手动去DNS服务商处添加。TXT记录的格式大概是_dnsauth前缀 + 一串随机字符串，比如_dnsauth.example.com对应的值为一段字母数字组合。
这里有个很多人容易忽略的细节：TXT记录添加完后，验证生效时间取决于你域名的TTL设置。如果你之前把TTL调到了24小时，那么改了DNS后最快也可能要等很久才开始生效。所以在续签前，我建议你提前把相关域名的TTL临时改成300秒，验证完再调回去。这个操作在阿里云云解析里就是改一下解析记录的TTL值，非常简单，但能显著缩短你等验证的时间。
2.3 备份旧证书是个好习惯
很多人没有备份旧证书的习惯，觉得反正要换新的了，旧的没用了。但实际经验告诉我：旧证书至少要保留到新证书部署验证成功之后。
原因有两点。第一，如果你在新证书部署过程中操作失误导致服务起不来（比如格式写错、路径配错），你还能快速回滚到旧证书，让网站先恢复正常。第二，有些第三方服务的证书上传审核比较慢，比如某些支付接口或企业微信回调配置，你提前替换新证书会导致调用失败，这时候你需要旧证书继续顶着直到新证书在对方那边完成校验。
备份的方法也很简单：在服务器上把证书目录整个打包，命名带上日期后缀，比如cert-backup-20250115.tar.gz。你要是怕麻烦，直接把.key、.pem、.crt这几个文件复制一份到/root/cert_backup/目录下也行。别嫌这一步多余，真到回滚的时候你就知道有多重要了。
3. 控制台续签实操：从申请到签发全流程
3.1 进入证书服务控制台
登录阿里云控制台后，在页面顶部的搜索框直接输入“SSL证书”，就能跳转到证书服务的管理页面。左侧菜单里找到“证书管理”，这里会列出你账号下所有的证书申请记录，包括已签发、已过期、审核中、验证失败等状态。
筛选出你要续签的那个域名，点击“申请”或“续签”按钮。需要说明的是，不同时期控制台的界面按钮叫法略有差异，有的版本叫“续费”，有的叫“重新申请”，但实际都是创建一个新的证书订单。你不用担心旧证书还没到期不能申请——证书申请和生效是两回事，新证书的签发日期是你申请通过的那天，有效期从那天开始算一年，跟旧证书的到期日没有关系。所以理论上你提前30天申请也没问题，新证书会提前生效，旧证书的剩余天数并不会叠加。
3.2 提交申请与域名验证
进入申请页面后，首先要确认域名信息。如果你申请的是通配符证书，这里填的是*.example.com的格式，注意通配符只能匹配一级子域名，比如www.example.com、blog.example.com都能覆盖，但a.b.example.com这种多级子域名是覆盖不了的。这是很多人理解上的误区，申请完才发现二级子域名的证书不对。
接下来是选择验证方式。刚才提过，如果你的域名解析就在阿里云，直接选“自动DNS验证”，系统会自动完成记录添加，省心。如果你的域名在别处解析，选“手动DNS验证”，系统会给你生成一条TXT记录，拿着这条记录去你的DNS服务商后台添加。添加的时候注意：有些DNS服务商要求你填主机记录时直接写域名，有些要求只写前缀，比如_dnsauth，这个细节要是填错了，验证就会一直失败。
提交之后，状态会变成“验证中”。自动验证一般几分钟内就有结果，手动验证取决于你DNS生效的速度。验证通过后进入CA签发排队，快的话十几分钟，慢的话可能几个小时。签发成功之后，状态会变为“已签发”，你就可以下载证书了。
3.3 下载证书文件
证书签发后，在证书管理列表找到对应的记录，点击“下载”，会进入一个选择服务器类型的页面。这里列出了Nginx、Apache、IIS、Tomcat等常见Web服务器的选项，你选择对应的类型，下载下来的是一个压缩包。
这里我要特别提醒：如果你用的是Nginx，选Nginx类型下载，里面包含的是证书名.pem和证书名.key两个文件；如果你选的是其他类型，可能会多出证书名-chain.pem或.jks、.pfx这类不同格式。不同格式对应不同服务器，别下载错了。比如你服务器跑的是Tomcat，需要的是.jks或.pfx格式，你下载个.pem过去就只能干瞪眼。
下载完成后，用SFTP或SSH把文件传到服务器上，准备替换。我习惯放在/etc/ssl/certs/或者Nginx配置里指定的证书目录，路径保持和旧证书一致，这样改配置文件时只需要替换文件内容，不用改路径。
4. 证书替换部署：Nginx、Apache、IIS和负载均衡的实操差异
4.1 Nginx替换步骤（最常见，也最容易出问题）
Nginx是现在用得最广的Web服务，先讲它。整个替换过程分三步：备份、替换文件、重载服务。
第一步，备份。把旧的example.com.pem和example.com.key复制一份到备份目录，命令大概是cp /etc/ssl/example.com.pem /root/cert_backup/，key文件同理。
第二步，替换。把下载的新证书文件上传到服务器后，覆盖到Nginx配置里ssl_certificate和ssl_certificate_key指令指向的路径。注意，如果你的Nginx配置里指向的是/etc/nginx/ssl/example.com.pem，那你一定要把新文件放到这个路径下，文件名也最好保持一致。我之前偷懒把新证书放在临时目录，结果配置里路径还是旧的，改了半天配置才意识到文件压根没放到位。
第三步，验证配置并重载。执行nginx -t检查配置语法是否正确，这一步很重要，能提前发现文件路径错误、证书key不匹配等问题。输出syntax is ok和test is successful之后，再执行systemctl reload nginx或nginx -s reload让配置生效。这里用reload而不是restart，因为reload是平滑重载，不会中断现有连接，生产环境推荐这种方式。
重载完成后，用浏览器无痕窗口访问你的站点，点击地址栏的小锁图标查看证书信息，确认证书的新有效期是否正确。还可以用curl -v https://example.com 2>&1 | grep "expire date"或openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates这类命令在服务器上直接验证证书生效情况。
4.2 Apache、IIS和Tomcat替换要点
Apache的替换逻辑和Nginx类似，但配置指令不一样。Apache用的是SSLCertificateFile和SSLCertificateKeyFile，如果是同时包含了中间证书链的场景，还需要配置SSLCertificateChainFile。替换后在Apache 2.4以上的版本里，执行apachectl configtest检查语法，然后systemctl reload httpd或apachectl graceful平滑重载。
IIS相对特殊一点，它不像Nginx那样直接放PEM文件，而是把证书导入到Windows证书存储里，然后在站点绑定的地方选择证书。替换路径是：打开IIS管理器 → 服务器证书 → 导入新证书（如果是PFX格式需要输入密码） → 站点绑定 → 编辑 → 重新选择证书 → 停止并启动站点。IIS最常见的坑是“证书不能被删除，因为它正被使用”，那是旧证书还绑在站点上，先改绑定再删旧证书就行。
Tomcat用的是JKS或PKCS12格式。如果你拿到的是PFX格式，需要先转换成JKS才能给Tomcat用，转换工具可以用JDK自带的keytool。核心命令是keytool -importkeystore -srckeystore yourcert.pfx -srcstoretype PKCS12 -destkeystore yourcert.jks -deststoretype JKS，过程中需要设置新的密钥库密码。转换完把JKS放在Tomcat的conf目录，然后在server.xml里配置keystoreFile和keystorePass，重启Tomcat生效。
4.3 负载均衡和CDN场景下的证书更新
如果你的站点前面挂了阿里云的SLB负载均衡，证书要先去负载均衡控制台里做替换，而不是直接改后端服务器。操作路径是：SLB实例 → 证书管理 → 上传新证书 → 监听配置 → 更换证书。这个操作是即时的，但要注意SLB上的证书有时会同步到CDN，如果你的站点同时开了CDN加速，CDN那边的证书也要一起更新。
更稳妥的做法是在阿里云的“证书管理”服务里给证书开启自动关联，这样在证书签发后可以直接推送到关联的SLB、CDN、OSS等云产品上。但如前所述，自动推送并不覆盖所有场景，我那次OSS证书过期就是因为开通了托管但没把OSS列入自动部署范围，导致更新链断了。所以我的建议是：证书签发后，打开“部署”功能，把当前需要用这张证书的产品全部勾选一遍，手动确认每个关联资源都是最新状态。
5. 常见问题与排查实录
5.1 DNS验证失败的几种原因和排查思路
DNS验证失败是续签过程中遇到最多的问题。我把它归结为四类：
第一类是TXT记录没生效。排查办法是到DNS服务商的解析列表中确认记录确实存在，然后在命令行用nslookup -type=TXT _dnsauth.example.com或dig TXT _dnsauth.example.com查一下权威DNS返回的结果。如果查不到，先检查记录的主机记录和值是否填反了，这种低级错误出现过很多次。
第二类是TTL缓存问题。如果之前TTL设置得很大，解析结果会在各层缓存很长时间。这时要么手动等待更长时间，要么把TTL改小后强制刷新本地DNS缓存。Windows上是ipconfig /flushdns，Linux上重启systemd-resolved服务或者直接指定权威DNS去查询来验证实际情况。
第三类是域名前缀填错。前面提过，主机记录有时要填_dnsauth，有时要填完整的_dnsauth.example.com，不同DNS服务商的规则不同。添加前先看看服务商给的示例，或者咨询客服确认格式。
第四类是验证服务器和你的DNS服务商之间存在解析同步延迟。这种情况比较少见，但确实遇到过——记录明明添加正确，阿里云那边过了一个多小时还是验证失败。我的处理办法是把手动验证改成文件验证，也就是在网站根目录放一个指定内容的验证文件，让CA通过HTTP访问来确认域名所有权。这个方法绕开了DNS同步的问题，在某些场景下比调DNS更快。
5.2 证书已签发但网站还是提示不安全
证书显示“已签发”，部署也完成了，但浏览器访问还是提示不安全，这个问题排队率也不低。我的排查顺序是这样的：
第一步，确认你访问的域名确实在证书里。如果你申请的是www.example.com的证书，但用户是通过example.com访问的，那浏览器肯定会报错。解决方法是申请证书时同时覆盖主域名和www域名，或者配置301跳转把裸域名跳到www子域。
第二步，检查证书文件是否完整。用cat查看PEM文件内容，确保里面包含了你的证书和中间证书链。Nginx配置里通常需要把服务器证书和CA中间证书写到同一个PEM文件中。如果只有服务器证书没有中间证书，一些严格的客户端（比如iOS设备）会报“certificate chain incomplete”错误。
第三步，确认部署后服务是否真的重载了。不少人替换了文件但忘了执行reload，服务还在用旧证书。执行systemctl status nginx看看进程启动时间就知道有没有重载成功。
第四步，检查服务器时间。这个很少见但确实存在，服务器系统时间如果偏差过大，证书验证会因为“证书尚未生效”或“证书已过期”而失败。执行date命令对一下时间，必要时同步NTP。
5.3 证书链不全和浏览器兼容性问题的处理
证书链不全是比较隐蔽的问题。你部署完证书后，用Chrome访问可能一切正常，因为Chrome会自动补全缺失的中间证书。但用某些移动端浏览器、邮件客户端、或一些老旧系统访问时，就可能因为无法获取完整的证书链而报错。
我的建议是不要依赖客户端自动补全，直接在服务器端把证书链拼好。具体做法是：把下载的证书名.pem和 CA证书（通常叫chain.crt或ca-bundle.crt）合并到同一个文件里，合并顺序是“服务器证书放前面，CA证书放后面”，用cat命令拼起来。Nginx的ssl_certificate指令可以直接指向这个合并文件。
合并之后用openssl s_client -connect example.com:443 -showcerts命令检查，看输出的证书链是否完整——应该能看到至少两个证书：站点证书和CA中间证书，最后到根证书。
浏览器兼容性的另一个常见问题是证书算法。目前主流CA签发的证书都用的是SHA-256签名算法，如果遇到老设备不兼容，那可能是设备系统太旧本身不支持SHA-256，只能建议用户升级设备。但在部署前，你可以用openssl x509 -in yourcert.pem -text -noout | grep "Signature Algorithm"确认一下签名算法，避免买到了过时算法签发的证书。
5.4 关于自动续签的那些隐藏坑
阿里云付费证书的托管自动续签功能，初衷是好的，但我用下来发现有几个坑值得留意。
第一，自动续签触发后，你需要去证书列表检查新证书是否真的申请成功了。我遇到过一次自动续签失败，原因是域名所有权验证那一步因为DNS解析变动而失败，但系统没有发告警邮件。如果你没主动去查，到期后网站就光了。所以即使开了自动续签，我也建议你在到期前10天左右手动看一眼证书状态。
第二，自动续签签发的证书不会自动部署。它只是在CA那边签了一张新证书，你的服务器、SLB、CDN上挂着的还是旧证书。一定要在到期前手动把新证书下载下来，替换到所有在用证书的资源上。
第三，免费证书不能开自动续签，所以你只能每年手动操作一次。如果你嫌麻烦，可以考虑升级到付费DV证书，或者配置脚本实现证书到期自动续签——但那通常需要调用API和配置自动化流程，复杂度会高不少，适合有运维能力的团队。
6. 实操心得：续签这件事，怎么才能越做越省心
写到这里，把整个续签流程的技术细节都讲了一遍。最后分享几个我在多次实操后总结的习惯，希望对你有参考价值。
第一个习惯是给证书续签做一个固定的“操作清单”，每次照着走一遍。我的清单很简单：检查到期时间 → 备份旧证书 → 申请新证书并验证 → 下载证书 → 替换到服务器 → reload服务 → 浏览器和命令行双重验证 → 更新所有关联资源（SLB/CDN/OSS等） → 清理临时文件。这套流程走熟了之后，每次续签大概只需要20分钟，不用临时想下一步干嘛。
第二个习惯是在日历上设置两个提醒节点：到期前30天和到期前7天。到期前30天的提醒是让我有充足的时间处理申请中可能出的幺蛾子，到期前7天的提醒是确保新证书已经部署完毕并验证通过。说实话，追着做比被到期告警追着做，体验完全不同。
第三个习惯是域名验证相关的信息要单独记录。域名在哪个服务商、DNS解析账号是什么、验证记录是怎么加的、TTL设置了多少，这些信息散落在各个控制台里，时间一长很容易忘记。我一般在项目文档里维护一张表，每次续签后更新一次，下次直接调出来看，省去了登录各种后台翻找的时间。
SSL证书续签本质上是件周期性、重复性很强的事，它的难点不在于技术有多深，而在于你是否有一套完整的流程和足够的细心。只要把流程理清楚、把坑提前避开，这件事就能从“每年提心吊胆一次”变成“按部就班二十分钟搞定”。希望这份指南能帮你把续签这件事做得更顺，也欢迎你把自己的经验和踩坑记录分享出来，互相补全这套操作手册。
