证书透明日志实测131个站：CAA记录只有18个是自己写的

摘要：把131个英文大牌站点的HTTPS证书逐张取下来解析，里面嵌着298条公开日志签名，一张漏网的都没有——证书能不能被全世界看到，签发方案里根本没有这个选项。反过来看另一头：能约束谁可以给这个域名签证书的CAA记录，131个站里只有18个是品牌自己写的。另有13个站查出来确实有CAA，但那份名单属于Shopify和Vercel，不属于品牌自己。

做技术审计久了会养成一个习惯：先分清哪些东西是你写的，哪些是别人替你写的。页面上的文案是你写的，响应头有一半不是，第三方脚本拉进来的域名基本都不是。

证书这件事更极端一点。它装在你自己的服务器上，密钥只有你有，可上面记的每一笔都由别人保管着一份副本，而且那份副本是公开的、可搜索的、你删不掉的。

这一轮把131个英文大牌站点的证书全部握手取下来，逐个字段解析，再用DNS over HTTPS逐级查它们的CAA记录，最后两边对账。结论比预想的干净，也比预想的难看。

一张证书刚签出来，有多少人已经知道了？

至少两家，通常三家。而且都不是你选的。

把131张证书的扩展字段摊开，每一张里面都躺着一段叫SCT的东西，全称是签名证书时间戳。它是某个公开日志在收下这张证书时回签的一张回执，意思是这份记录我收了，编号在此。131张证书里，带2条回执的95张，带3条的36张，一条都没有的，零张。

这不是巧合，是道硬门槛。Chrome的证书透明度政策规定，一张公开信任的证书必须携带来自不同运营者的日志签名，数量不够浏览器直接判定不合规。换句话说，签发机构想给你签一张不进日志的证书在技术上做得到，但那张证书在主流浏览器里打不开，等于废纸一张。整套机制的标准文本写在RFC 9162里。

所以真实情况是这样的：你的运维在凌晨两点点了续期按钮，几秒钟之内，这张证书上的域名、组织名、有效期、序列号，就被抄进了两三本谁都能读的账本，永久留存。你没被问过要不要，也没有地方可以撤回。

回执上的时间，比证书本身还早

把每条SCT的时间戳和证书的生效时间相减，中位数是3511秒，差不多一小时。最长的一条在notino.com上，81151秒，超过22小时——日志先收到记录，将近一天之后这张证书才正式生效。298条回执里，没有一条晚于证书生效时间。

这个顺序不是意外，是流程本身决定的：签发机构要先把预证书交给日志换回执，再把回执嵌进正式证书里签出来。登记在前，生效在后。先斩后奏这个词在这里得反过来用，是先奏后斩。

为什么非得是不同的运营者

政策要的不是两条签名，是两个不同的人签的名。这条限制的用意很直接：如果只要求两条，同一家运营者签两次就能满足，那么这家一旦作恶或者被攻破，整条证据链就一起没了。要求来自不同运营者，等于让两家互不隶属的机构同时留底，谁想抹掉记录都得说服另一家。

日志本身用的是可追加的树状结构，新记录只能往后加，改动历史会让整棵树的校验值对不上。这套设计让删除变成了一件在数学上会留下痕迹的事。做SEO的人对这种结构不陌生，它和内容指纹、缓存校验是同一类思路，哈希在ETag和SRI上的用法也是这个路子：不防你改，只让你改完藏不住。

替你记这本账的，都是哪几家？

298条回执按运营者拆开，分布是这样的：

前五家是意料之中的角色。真正值得停一下的是第六和第七行。

IPng GmbH和Geomys加起来替这批国际大牌记了48条账，比Let's Encrypt自己还多。这两家都不是巨头，规模跟前面几家完全不在一个量级。它们的日志分片名字也很有生活气息：Gouda是荷兰豪达奶酪，Halloumi是塞浦路斯烤奶酪，Tuscolo是罗马郊外的一处古城。相比之下Google那边的Argon、Xenon一股元素周期表味，DigiCert的Sphinx、Wyvern则是狮身人面像和飞龙。

名字叫什么无所谓。要紧的是这件事的形状：你的证书记在哪几本账上，是签发机构挑的，不是你挑的。你可以换CA，但换不了日志；你甚至不会在任何一封续期通知邮件里看到这两个名字。有一天某个日志被撤销信任、整批记录需要重新提交，你也是从别人的公告里知道的。

运营者的两两组合有规律。DigiCert加Google的组合出现在14个站上，Google加IPng 11个，DigiCert加Let's Encrypt 11个，Cloudflare加Google 10个。正是那条运营者必须不同的要求，把这些搭配固定了下来——它防的是单点作恶，代价是每张证书至少要在两个陌生人那里留底。

那条唯一的TrustAsia回执落在一张中国出海品牌的证书上。这家的日志分片里有一本叫HETU，河图。上面这些归属关系不是猜的，是照着Apple维护的那份公开日志清单逐条比对出来的，整份清单读下来，像在翻一本各国工程师给自己项目起名字的册子。

能管住谁给你签证书的那条记录，有多少人真写了？

前面说的是事后的账本。事前那道闸门叫CAA，写在RFC 8659里，形式是一条DNS记录，内容大意是只有这几家机构可以给我这个域名签证书。签发机构在签之前必须查这条记录，查到了发现自己不在名单上，就得拒绝这单生意。

这是整个Web PKI里少数几件完全由域名持有人说了算的事。成本是在DNS面板上加一行，收益是把全世界任何一家公开信任的CA都能给你签证书这个默认状态，收窄成一份白名单。

131个站里，能查到CAA记录的有31个。

先别急着算百分比。这个数字后面藏着本轮最大的一次判据翻车，下一节专门说。先把没有的那一头讲完：100个站，一条CAA都没有。包括aliexpress、anker、dji、shein、uniqlo、zalando、nespresso、decathlon，也包括arcteryx、bellroy、on.com、peakdesign这些技术口碑相当不错的品牌。名单里还有shopify.com自己：它的shops.myshopify.com上挂着一份CAA，被11个客户站顺路读了去，而它自己的主域是空的。

没有CAA的后果不是立刻会出事。它的意思是：假如某一天某家CA的域名验证流程被绕过了，或者有人拿到了你DNS的临时控制权，签发这一步不会有任何东西拦一下。有CAA的站，攻击者还得先改掉那条记录，而改记录这个动作是有痕迹的；没有的站，这一步直接跳过。

这个逻辑和支付页那道内容安全策略是一回事：平时它什么也不做，只在出事那一刻决定损失有多大。区别是CSP至少还会在浏览器控制台里刷点动静，CAA连动静都没有，它工作的时候你在睡觉。

那13份授权名单，为什么长得一模一样？

把31份CAA的授权名单排开，一眼就看出问题：有11个站的名单一个字都不差，都是这五家——digicert.com、globalsign.com、letsencrypt.org、pki.goog、ssl.com。

allbirds、brooklinen、everlane、dollarshaveclub、dreametech、fiskars、awaytravel、baseus、bollandbranch、chubbiesshorts、avocadogreenmattress。这11个分属不同国家、不同品类、不同团队的品牌，在一份安全配置上给出了逐字相同的答案，这个概率低到不值得算。

顺着CNAME摸过去

CAA的查询规则里有一条容易被忽略的细节：查询要从待签发的那个名字开始逐级向上找，而且遇到CNAME要跟着跳过去。这11个站的CAA全都出现在www那一层，根域反而是空的，这就很可疑了。

挨个查CNAME，答案立刻清楚：

• www.allbirds.com指向shops.myshopify.com，而allbirds.com根域没有任何CAA
• www.brooklinen.com指向shops.myshopify.com，同上
• us.dollarshaveclub.com指向shops.myshopify.com，同上

再直接查shops.myshopify.com：五条CAA，digicert、globalsign、letsencrypt、pki.goog、ssl.com，与那11个站查到的完全一致。

这份名单不是这11个品牌写的，是Shopify写在自己域名上的，通过一条CNAME被顺带读到了。品牌自己的根域上，一条记录都没有。

另外两个站是同一个套路的另一个版本：www.traeger.com和www.buckmason.com都指向vercel-dns的地址，读回来的四家名单——globalsign、letsencrypt、pki.goog、sectigo——是Vercel的。

把这13个站从配了CAA里拿掉，真实数字是131个站里18个自己写了CAA，13.7%。原来那个23.7%，量到的是平台的配置水平，不是品牌的。

这个形状之前见过。清点平台声明文件那一轮，48个站对手机系统说了同一句话，那句话也不是它们写的。只要一个配置项可以由平台代答，它的覆盖率数字就一定被平台抬高过，量之前得先问一句这是谁写的。

还有一个站，两份名单

taylorstitch.com那份更有意思。

它的根域上确实有一份自己写的CAA，四家：globalsign、letsencrypt、pki.goog、sectigo，而且issue和issuewild两种标签都写全了，看得出是懂行的人配的。但它对外服务的www.taylorstitch.com指向shops.myshopify.com，那一层读到的是Shopify那份五家名单。

两份名单不一样。digicert和ssl.com在品牌自己那份里是不被允许的，在实际承载流量的那个名字上却是允许的。这个站的团队认认真真收窄了一次签发权限，收窄的是一个没多少人访问的名字。

名单越写越长，是更安全还是更松？

剩下18份自己写的名单里，另一个方向的问题浮出来了：名单在变长。

casper授权了10家机构，实际在用的是1家。ikea授权9家——amazon系四个域名，加上digicert、globalsign、letsencrypt、pki.goog、sectigo——用的是其中1家。philips那份里甚至有日本的cybertrust和荷兰的kpn，一份名单读下来能大致还原出这家公司过去十几年的证书采购史。

这是很典型的组织行为：一条记录由安全团队起草，各个业务线提需求，我们这边可能要用AWS的证书，我们海外站在用DigiCert，谁都不想被卡，于是名单只增不减。可CAA的价值恰恰来自它有多短。授权9家，等于说这9家里任何一家的验证流程出问题，我都认。

18份名单里有一份只授权了2家，写法干净利落。也有一份把选项开到了10家，看着像一份采购备选清单，不像一道闸门。

顺便交出去的两样东西

CAA还有个iodef标签，用来告诉CA：有人试图违规给我签证书时，往这个地址报警。8个站写了，写的都是真实邮箱：

• ikea.com写的是caa@inter.IKEA.com，大小写混着来，能看出是从内部文档里复制过来的
• philips.com是ca.administrator@philips.com
• swarovski.com是internet.domain.admin@swarovski.com
• madewell.com是cert-notification@jcrew.com，报警发到母公司J.Crew的域名上
• notino.com是admin@notino.com.，末尾多了一个点

这些邮箱是公开可查的，谁都能拿去做定向钓鱼的素材。写iodef本身是好事，代价是又一个内部联系人被挂到了公网上。这跟域名验证记录那件事是同一个道理：域名根上挂着的每一条记录都在对外说话，只是没人拿它当对外发言。

另一样东西藏在casper、glossier、italic、notino、theordinary这五个站的CAA里，参数写着cansignhttpexchanges=yes。这是在授权特定机构签发签名HTTP交换证书，也就是SXG。它跟SEO直接相关——SXG是让页面能以你的域名身份从第三方缓存里分发的机制。这五个站在一条DNS记录里透露了自己在做什么级别的分发优化，而这条信息在页面上是看不出来的。

证书上印着的名字，只有你想让人看的那些吗？

证书里的SAN字段列着这张证书保护的全部域名。中位数是1，78个站的证书上只有一个名字，干净利落。均值是4.4，被少数几张撑了起来。

数量本身没有对错，一张证书带几十个名字在多国站点上是常规做法。有意思的是名字本身。

aliexpress那张，92个名字

这张证书是本轮SAN最多的一张，读下来像一份内部系统清单。除了各语种站点和各国域名之外，里面还有*.workstation.aliexpress.com、*.siteadmin.aliexpress.com、*.fortress.aliexpress.ru、*.prepub.aliexpress.com、*.pre-sycm.aliexpress.com、*.dev.aliexpress.ru。

工作站、站点管理、堡垒机、预发布。还有一条*.trendyol.aliexpress.com，把与土耳其电商Trendyol的对接关系也一并写在了上面。这些名字没有一个是打算给消费者看的，但它们和消费者天天访问的那个域名共用一张证书，于是一起进了公开日志。

dji那张，12个注册域

更值得看的是跨注册域的情况。dji.com的证书上除了dji.com、dji.net、djicdn.com这些能猜到的，还印着dbeta.me、djiops.com、djiag.com、djigate.com、aasky.net、fffsky.net。

beta、ops、gate，这些名字的用途几乎写在脸上。而aasky.net和fffsky.net这种域名，单看根本猜不到跟大疆有关系——直到它们和dji.com一起出现在同一张证书上，关系就公开了。把一堆URL批量提成根域做盘点是常规动作，而证书这条路径给的是另一种东西：它直接给出了归属关系，不用你去推。

还有几张，讲的是别的故事

• bellroy.com一张证书21个注册域，除了各国站点，还挂着slim.ninja、slimninjas.com、sultansofslim.com、slimyourwallet.com、day1day1000.com。这家做薄款钱包，这几个域名一看就是历年营销活动留下的，全都跟着主站证书一起续到了今天。
• rapha.cc和raphadev.cc共用一张证书。开发环境的域名，和生产环境同证。
• quince.com的通配符里有*.preview-prod.quince.com和*.preview.quince.com，预览环境两套。
• rab.equipment和lowealpine.com同证书。这是两个户外品牌，同属一家母公司，证书把这层关系摊开了。
• vuoriclothing.com和vuori.com、madewell.com和madewell1937.com、prose.com和prosehair.com，都是主域加备用域同证。

之前那一轮做子域名清点，用的是拿一份常见名字挨个敲门的笨办法，敲中了才知道存在。证书这条路子完全不同：它不需要猜，是对方自己把名字写上去，还请第三方公证了一遍。像dbeta.me这种名字，字典枚举一万年也敲不出来。

要说明的是，这两条路各有各的盲区。字典枚举能发现那些没有证书的名字，证书日志只能看见申请过公开信任证书的那些。一个内部系统如果用私有CA或者干脆跑在HTTP上，它在这本账上是隐形的。

这些证书是谁签的，又签成了什么等级？

签发机构的分布，是本轮最能说明行业变化的一组数字：

免费证书拿下了将近60%的国际大牌站点。这个结果放在十年前不可想象，那时候一张商业证书要走采购流程，报价单上还印着保额。

这张表里有个坑值得单独说：原始数据里的机构名有14种不同写法。DigiCert出现过DigiCert Inc和DigiCert, Inc.两种，GoDaddy有GoDaddy.com和GoDaddy.com, Inc.，SSL.com那家在证书里一会儿是SSL Corp一会儿是SSL Corporation。不做归一化直接分组，DigiCert会被拆成13和2两行，排名当场就错。

EV证书只剩一张了

按CA/Browser Forum的策略标识分类，131张证书里DV域名验证113张、OV组织验证17张、EV扩展验证1张。

那唯一一张EV属于arcteryx.com，组织名写着Arc'teryx Equipment (Amer Sports Canada Inc)，由SSL Corp签发。

EV证书当年是卖点，浏览器地址栏会显示绿色的公司名，销售话术里管这叫信任背书。各家浏览器陆续取消那个显示之后，它就只剩价格没剩优势了。131个国际大牌里还留着一张，这个数字比任何评论文章都说明问题。

OV证书里印着的是法律实体名

17张OV证书里的组织名，是被签发机构核验过的注册主体，其中几个对做出海的人特别有画面感：

• ecoflow.com是深圳市正浩创新科技股份有限公司
• insta360.com是影石创新科技股份有限公司
• narwal.com是云鲸智能创新（深圳）有限公司
• shein.com是ROADGET BUSINESS PTE. LTD.
• aliexpress.com是Alibaba (China) Technology Co., Ltd.
• braun.com是The Procter & Gamble Co

之前量过一轮网站页脚署的公司名能不能查到，结论是116个站里只有11个给得出可核验的注册编号。页脚是自己写的，写什么都行；OV证书上这一行是花钱请人核过的，两边对不上的时候，该信哪边不用犹豫。中国团队做海外品牌，往往刻意不在页面上露出国内主体，而证书这一层是藏不住的——只要买的是OV或者EV。用DV证书的那113个站，这一格是空的，这也是DV占绝大多数的原因之一。

证书里那行吊销地址，为什么一半的站已经没有了？

解析扩展字段的时候撞见一个干净得反常的分裂：131张证书里，带OCSP地址的只有38张。按签发机构拆开之后，规律清楚得像刀切的：

不是比例问题，是有和无的问题。查Let's Encrypt的公告能对上：它在2024年12月宣布了停用OCSP的时间表，2025年5月7日起从证书里去掉OCSP地址、同时补上CRL地址，2025年8月6日关闭OCSP响应服务。

我这边量到的是：131张证书里129张带CRL分发点，OCSP只剩38张，而且缺的那批一张不差全是Let's Encrypt和Google Trust Services签的。官方公告写的那一天，在真实世界里就是这么落地的。

这件事的直接后果，是很多教程里那行ssl_stapling on;现在在一部分站上什么也不做——装订的是OCSP响应，证书里连地址都没有了，还装订什么。证书有效期砍向47天那篇里推演过这个变化，这次是把它量出来了。顺带一提，131张证书里must-staple扩展一张都没有，零。这个扩展的意思是强制要求装订，一旦服务器拿不到响应就直接拒绝握手，安全性最高，代价是任何一次响应服务抖动都会让整站打不开。没人敢用，很合理。

新规半年了，存量证书换完了吗？

公开信任证书的最长有效期正在分阶段收紧，CA/Browser Forum的SC-081表决把这条路线写死了：从398天起步，2026年3月开始降，2029年3月落到47天。

131张证书的有效期中位数是90天，这个数字由Let's Encrypt的默认值决定。真正要看的是长尾：

有效期超过200天的证书有14张。这14张的签发日期，全部早于2026年3月15日——一张例外都没有。

规则只约束新签发的证书，不追溯已经签出去的。所以这批长证书会一直跑到自然到期为止，最晚的一张是ouraring那张，2027年3月10日才退场。想知道一条规则真正生效需要多久，看这一列日期就够了：表决通过是一回事，最后一张老证书退休是另一回事，中间隔着将近三年。

另一头是新规之下的实际选择。有21个站的证书有效期落在198到199天这一档，正好贴着200天的上限往下压一到两天。这一档不是巧合，签发方要留出时区和签发瞬间的误差余量，卡在整数上有极小概率越界，而越界意味着这张证书不合规、必须重签。实测里198天比199天还多，说明有的机构比同行还保守一天。

最短的一张在underarmour.com上，30天，由Certainly签发——这家是Fastly的证书机构。131个站里，有效期已经短于47天的，只有这一个。换句话说，99.2%的站还没进入47天时代的节奏。

顺手看了一眼剩余寿命：中位数61.6天，没有一个站的证书会在15天内到期，说明自动续期这件事在这个量级的站点上基本不成问题。用掉的寿命比例中位数是0.39，最紧张的是assos.com，96%的寿命已经走完，只剩17.5天。它那张是397天的老证书，续期时会自动落进新规的短周期里，那一刻才是它的运维流程真正被考验的时候。这类把续期、备份、缓存清理交给定时任务的活儿，值得在周期变短之前先跑通一遍演练。

密钥算法这一格，换代已经完成

131张证书里，91张用椭圆曲线密钥，38张RSA-2048，2张RSA-4096。椭圆曲线占了69.5%。签名算法那一格，74张ecdsa-with-SHA384、43张sha256WithRSAEncryption、14张ecdsa-with-SHA256。传输层版本上TLS 1.3有122个站，剩下9个还在TLS 1.2。

椭圆曲线的证书更小、握手更省，对首字节时间有实打实的好处。这类收益单看很微小，但它发生在每一个新连接上，累积起来就进了TTFB那本账。已经有69.5%用上了，剩下那三成里，有一部分是被长有效期的老证书锁住的。

这一轮实测，我的尺子错了四次

数据摆出来之前，得先交代它被改过几次。这四条里有三条改变了结论方向，如果不查，文章里会出现三个错误的数字。

第一条和第二条的共同点，是我一开始把CAA当成了域名的属性。它不是。CAA是查询过程的结果，取决于你从哪个名字开始查、路上有没有CNAME。同一个品牌，从根域查和从www查，能拿到两份不同的名单，taylorstitch就是活样本。

还有一条经验值得单独记下来：第一版就跑出一组特别整齐的数字，几乎一定是把一批不同的东西粗暴地归进了同一格。11个站的名单逐字相同，这种整齐本身就是警报。做响应头自相矛盾那一轮时也是同样的教训，判据越是一次成型，越要回头抽样看看原始值。

自己域名的这本账，该怎么查？

整套动作不需要买工具，三步，十分钟能跑完一个域名。

第一步，看看账本上有你多少条

公开日志是可以直接搜的，搜索界面输入自己的注册域，会列出历史上所有签发过的证书，包括早就废弃的子域、临时用过的测试环境，以及所有和你共用过一张证书的名字。

盘的时候盯三样：有没有你不认识的名字；有没有dev、beta、staging、admin、ops这类不该对外的名字；有没有已经不用了但证书还在续的名字。第三种最常见——服务早就下线了，续期脚本还在忠实工作，每90天给一个404续一次命。这些名字如果还能解析、还能打开，就该顺手接上死链与重定向链的排查一起处理掉。

第二步，查自己有没有CAA，以及查的是哪个名字

命令行一条就够：

dig CAA example.com +short
dig CAA www.example.com +short
dig CNAME www.example.com +short

三条都要跑。只查根域会漏掉平台那份，只查www会把平台的当成自己的。如果www是CNAME到Shopify、Vercel、Cloudflare Pages这类平台，那一层的名单就不是你能决定的，你能控制的只有根域那一份。

想看服务器上正在用的那张证书是谁签的、有效期多长、SAN里都有谁：

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -issuer -dates -ext subjectAltName

这条命令在排查海外访问异常时也用得上，它能确认你连到的那个节点递给你的到底是哪张证书——同一个域名在不同地区落到不同节点的情况并不少见，从DNS到线路再到CDN的网络层排障里，证书是最容易被跳过的一环。

第三步，决定要不要写，以及写多短

配CAA的判断很简单：

写的时候有两个具体的坑。一是issuewild：不写的话，issue的名单同时管通配符；写了的话，通配符只认issuewild那一份。本轮18个自己配CAA的站里有一批只写了issue，等于让通配符沿用同一份名单，这在多数场景下是对的，但要知道自己是在依赖默认行为，而不是自己做了决定。二是iodef：写真实邮箱意味着把一个内部联系人挂上公网，用一个专门的收件地址，比用某个同事的邮箱稳妥得多。

这本账还能反过来用

盘完自己的，这套方法对着别人也一样跑得动，而且完全合规——所有数据本来就是公开的。

能看出来的东西包括：一家竞品最近有没有上新的业务子域，从名字往往能猜到方向；它的证书是哪家签的、有效期多长，能看出运维的自动化程度；一张证书上如果同时出现两个看起来无关的品牌，那两家大概率是同一个母公司或者同一个服务商在管。本文里rab.equipment和lowealpine.com就是这么被串起来的。

对做外链和竞品调研的人，这是一条很少有人走的信息通道。它的可信度还特别高——页面上的文案可以随时改，证书上的名字改不了，因为那份记录不在他们手上。

顺手能做的一件事

公开日志有订阅服务，可以在有人给你的域名签发新证书时收到通知。这是一道很便宜的监控：正常情况下你自己的续期是有节奏的，突然冒出一张不在计划里的证书，说明要么有人在你不知情的情况下动了DNS，要么有个团队自己申了一张。两种都值得立刻问一句。

做过robots声明与实际投放的对账、响应头字段清点、第三方域依赖排查这几轮之后，保哥的体会是：这类工作的价值不在于每次都能挖出事故，而在于把我以为的配置和机器眼里的配置摆到一起对一次。证书这本账的特殊之处在于，它是唯一一份由第三方替你保管、你还改不掉的记录——别人早就在看了，你自己一次没看过。

常见问题解答

不配CAA会被搜索引擎降权吗？

不会。CAA不是排名信号，搜索引擎不读这条记录。它防的是错误签发，属于安全边界而不是SEO项。真正会影响收录的是证书本身出问题——过期、域名不匹配、证书链不完整，这些会让抓取直接失败。从HTTP迁到HTTPS那篇里说的那些排名保住的前提，第一条就是证书别出事。

证书透明日志会把我的内部域名暴露给竞争对手吗？

会，而且这是设计使然，不是漏洞。只要一个名字出现在公开信任的证书上，它就会进入公开日志。想让内部系统不上榜有两条路：一是用通配符证书，让具体的子域名不单独出现；二是内部系统用私有CA签发，不进公开信任体系。第一条更常见，代价是通配符私钥的分发范围变大，得配套管好。

为什么我的站查不到CAA，证书却照样签出来了？

这是正常的。CAA的规则是查到了就必须遵守，查不到就放行。没有记录等于没有限制，不等于禁止签发。所以缺CAA从来不会导致签发失败，只会让签发这件事少一道闸门——这也正是它容易被无限期搁置的原因：不配也不报错，没有任何东西提醒你。

用Shopify或者Vercel这类平台，还有必要自己配CAA吗？

有必要，但要清楚它管到哪。平台承载的那个名字，通常是www或者某个业务子域，走的是平台的CAA，你配不了也改不了。你的根域、邮件用的子域、自建服务用的子域，这些还在你手上，该配。本轮那13个站的毛病不在于用了平台的名单，在于根域上一片空白。

有效期397天的老证书，需要提前换掉吗？

不需要主动换，但要确认续期流程已经改造完。这批证书到期时，续下来的会自动落进当前的短周期。风险不在这张证书上，在续期这个动作的自动化程度上——一年一次的手工流程，换成一年好几次之后就撑不住了，这才是要提前处理的事。

OCSP地址没了，会影响用户访问吗？

不会影响正常访问。吊销状态改由CRL提供，浏览器有自己的分发机制。要检查的是服务器配置里那些针对OCSP的选项，它们现在可能在空转；以及任何依赖OCSP查询做健康检查的监控脚本，需要改到别的判据上。

权威参考资料