每个人都可以，
拥有SSL证书

AWS ACM发了一则不算太意外的公告：公共证书续期的邮件域名控制验证，也就是邮件DCV，要在2027年9月30日前永久停用。

往前翻时间表，2027年1月1日起新开的AWS区域先限制，3月31日起所有区域的新申请证书直接禁止邮件验证，9月底彻底切断基于邮件的自动续期。

这个动作不是AWS单方面拍脑袋。CA/B论坛2025年11月已经投票决定淘汰公共TLS证书的邮件验证，2028年3月15日起主流浏览器会停止信任所有经邮件验证签发的公共证书。AWS的时间表比浏览器最后通牒早了半年，留出迁移窗口。

邮件验证被淘汰的原因，运维同行应该不陌生。

MX路由本身可能被攻破，验证链接在传输路径上存在拦截空间，更常见的是WHOIS管理联系人过期后，验证邮件发到了不再受控的邮箱。这类风险在供应链攻击场景里被反复利用过，证书签发环节的域控验证一旦失守，后续整个TLS信任链都是空中楼阁。

这次公告里值得注意的细节是UpdateCertificateOptions API的行为变化。管理员可以在不中断线上流量的前提下，把活动证书的验证方式从邮件原地切换成DNS，不需要重签证书，不需要重新配置负载均衡，ARN也不变。操作流程是ACM生成一条客户专属的CNAME记录，企业有72小时窗口完成DNS传播。

Route 53用户可以在控制台里一键添加，其他DNS托管服务商需要手动添加。

72小时这个窗口期，比常规DNS变更的容忍度宽一些，但考虑到企业DNS变更审批流程可能涉及多部门，实际留给运维的执行时间没想象中充裕。

尤其是一些大型组织的DNS管理权限和证书管理权限分离，证书团队未必有权限直接操作DNS记录。

CloudFront场景还支持基于HTTP的令牌验证作为替代自动化方案。这适合DNS操作受限但Web服务器配置可控的情况，令牌文件放在指定路径下即可完成验证。

说到底，邮件验证的退场本质上是证书验证方式从“低可信手动确认”向“高可信自动化确认”的迁移。DNS验证和HTTP验证的核心逻辑都是：你能修改域名的解析记录，或者你能在域名指向的Web服务器上放置指定文件，本身就证明了域控权。

这块自动化做得好不好，直接影响证书续期的稳定性和人力成本。手动添加DNS记录、等待传播、确认验证状态、签发后部署到负载均衡，这套流程如果全靠人工，72小时窗口内处理几十张证书不是轻松事。

lcjmSSL这类平台做的事情就是把ACME协议的能力铺开。ACME协议本身就是为了让证书申请、验证、续期全部自动化而设计的，基于Let's Encrypt、Google Trust Services、ZeroSSL这些可信CA。

平台封装了多域名、泛域名、IP证书的支持，提供API接口，意味着DNS-01验证的流程可以通过程序自动完成，包括添加TXT记录或CNAME记录、等待传播、完成验证、拿到证书、部署到目标节点。

对运维团队来说，把证书验证方式从邮件迁移到DNS，不是一次性的手工操作，而是一次把证书管理流程彻底自动化的机会。

2027年9月30日之后，邮件DCV这条路彻底堵死，届时还在靠人工处理证书续期的团队，面临的不是迁移窗口，而是业务连续性风险。