这几天证书过期这种草台班子，怎么没人从流量 sni 层面去做黑盒告警

[guanzhangzhang]

在公司测试环境的出口网络设备上，给流量镜像下，大致下面

• 镜像出口流量（ SPAN / iptables TEE / eBPF / AF_PACKET ）
• 只看 TCP 443
• 不解密 TLS
• 解析 ClientHello 的 SNI 拿到“真实被使用的域名”
• 匹配自家域名（含通配符）
• 主动发 HTTPS 请求
• 读取证书 NotAfter
• 告警

即使某些公司存在一些冷门业务在跑，而该域名没记录到 cmdb 里，这样也能抓到

设想下，假如你是一名安卓开发，然后入职接手了项目，引入了一堆 sdk 啥的，某天某个 sdk 由于证书错误直接造成 app 无法使用或者闪退故障，最后你背锅，你服气吗。
如果有类似轮子，你平时让测试人员的网络出口整个这个检测到🤔

发现很多人怎么这么一根筋，首先我只是提出想法和角度，又不是直接发布了一个完成品推荐大家去用，只是一个思路和作为备用手段。
希望提出来给一些人做网络流量清洗厂家能搜到和看到，说不定这些人以后能做出更牛逼的东西或者集成到某个适合的场景设备上。

[Ljcbaby]

不是所有业务都在自有机房吧

[1145148964]

擦屁股的话，没有大的收益。

[guanzhangzhang]

@Ljcbaby 能被广大程序员看到的大厂草台班子新闻，这些厂不可能没有这种单独的测试网络环境

[vfs]

"匹配自家域名（含通配符）": 你自己的域名，你自己肯定知道。 所以直接写一个定时任务，过一阵子把你的域名都挨个 https 请求一遍， 检查证书 NotAfter ， 告警就行了。 前面步骤可以都省了

[guanzhangzhang]

@vfs 控制域名解析的资产归属和运维不一定是一个部门，特别大厂里分工太明细了，你看去年和今年，为啥年年有大厂证书过期

[ajaxfunction]

吃一截长一智的事，和规模没关系。

[fionasit007]

听说这次腾讯直接续签了 100 年，但是证书有效期不是一年嘛，就算他 100 年每年还是需要换的，或者说他们和证书机构直接有对接，可以搞不用替换的？

[stinkytofux]

@fionasit007 #7 可能是自有证书, 只用来跟游戏客户端通讯加密用的. 不需要浏览器信任.

[salmon5]

然后证书过期的锅就全是你的了，别人高高兴兴乱用证书，反正锅都是你的

[salmon5]

事实上你造了一个屎山一样的没意义的轮子

[guanzhangzhang]

@salmon5 #10 又不是告诉公司，而是运维自己偷偷用，给自己兜底

[salmon5]

@guanzhangzhang #11 你这个方案太重了，并且 TLS 证书用的地方很多，文档签名、代码签名、mysql 、pgsql 、mongo 等等都会用到证书，你这所谓的小小的运维能管的过来吗？

[guanzhangzhang]

@salmon5 #12 1.首先，只是 https 的 sni ，又不是双向 ssl 和那些纯 tcp 的 ssl 服务，其次流量出口镜像下有啥难度和侵入性，我开发个 app 或者运行在 socks 代理也能实现一个透明代理层面监控，https://github.com/zhangguanzhang/appproxy

[pckillers]

楼主可能不知道 HTTP2 的一个 TCP 包里可能有多个域名的请求。 更不要说 QUIC 这种走 UDP 的协议了。 最后正式不一定是 https 的，很多私有协议也会有证书。

[niubilewodev]

上了这套系统。
10 年可能起不到一次作用。
只要 1 次没起作用，锅就归你背。
没人愿意上。

[guanzhangzhang]

@pckillers 逐一扩展，而且不是有 ebpf 项目能抓 https 的吗，我只是问为何没人从这方面去整下，作为备用手段

[guanzhangzhang]

@niubilewodev 是备用又不是完全靠这个，没有这个的情况下，为啥这么多大厂还出现这种草台事情

[AkinoKaedeChan]

@guanzhangzhang eBPF 抓 TLS 那个可是要 Hook TLS 库的……

[guanzhangzhang]

@AkinoKaedeChan 我这是提出一个方向想法，万一有大佬做出一个牛逼的，测试环境上的 agent 和 server 部署监控，以及公司出口流量上网行为审计继承 https sni 层面监控，支持不同场景的不同模式，还有 dns 解析 mirror 啥的，设计抽象好支持更多扩展

[jiangzm]

你这是没事找事，还镜像网络设备流量这蠢蠢给自己埋雷。

作为运维/开发你只要监控自家服务端的 https 证书即可，使用客户端完全不需要管别人的 https 证书。

如果能收集自家的证书随便加个提醒即可，如果是其他部门管理那就定时监控 HTTPS 服务状态，比如用 uptime-kuma 同时监控服务状态和证书到期提醒。

[qwertooo]

没意义，大公司不会用，小公司不会买。

[jiangzm]

@guanzhangzhang #17 google 都出过域名到期没续费的情况，别动不动就到处给人家扣什么草台班子的帽子。 先问下你自己是不是菜鸡。

[sampeng]

@ajaxfunction 是啊。。。问题是你以为 10 年这个数字怎么来的。。因为他 10 年前已经发生过一次。。。

[94]

我们这边就一个域名，然后是 1 年的证书。每年证书到期前的运维部门会提前发全体 IT 的邮件通知。过期前一个月的每个周一都会发，一直发到旧证书过期的那一周。
如果过期了都还没发现说明用的人少就不用管了 😂

[sagnitude]

一个 openssl 脚本就能干的事情，搞这么复杂，指定几个监听 URL ，crontab 一下，发现不对直接给管理层群发邮件和短信，给负责人发短信钉钉消息，最高优先级，结束

[Q980q48Jgj6pRXoO]

要考虑成本问题

[chunjilikafa1456]

我们这专门成立了一个 ssl 卸载层的平台，不负责管理证书，但会提醒证书有效期

[Rickkkkkkk]

最有可能的情况下，这个证书是 LOL 公司还很小的时候就有的，流程啥的都没有。然后最开始就是申请到现在过期。

[guanzhangzhang]

@sagnitude 你的意思是之前苹果音乐，谷歌，LOL ，罗技都写不了 openssl 脚本吗，你说的脚本场景是知道有哪些证书的前提下，但是大多数工作中处于交接导致遗漏逃逸，所以需要思路是从黑盒层面作为兜底避免

[invictus0741]

馆长的场子还是要站一站。

[guanzhangzhang]

@Rickkkkkkk 所以就是需要黑盒层面用技术手段兜底，毕竟很多都是交接情况埋了很多坑

[guanzhangzhang]

@94 这种统一管理基本不会发生这种场景的，但是比如 LOL 那种陈年和多次交接的就不一定具备这种统一管理条件了

[Rickkkkkkk]

@guanzhangzhang 就没做呗。这个东西可能十年前就存在的，最早负责这块的人也早就离职了。然后一直能跑也不会有人去关心。

[guanzhangzhang]

@usn 看要做到那种地步了，自己偷偷用作为兜底手段可以快速 ai 整一个工具出来

[guanzhangzhang]

@jiangzm #20 按照你的说法，我看了你的贴子，你用 containerd 还单节点 k8s ，不是蠢蠢给自己找事，既要 docker 的便利性又被 containerd 的 nerdctr 和 ctr 折磨，为啥不用 cri-dockerd

[guanzhangzhang]

@chunjilikafa1456 纯软件方案还是硬件方案

[COW]

不懂，证书管理不是通过 cert-manager 、pki 自动化弄吗，自动续期失败了就自动告警呗，跟 SNI 有什么关系。。。SNI 只会找域名，有些证书还是纯 IP 的呢。

[DHCPv6]

Panabit NTM 免费版是有类似功能，旁路嗅探证书并推送过期消息，只是不太想用他们的产品，记得是网卡 Polling 模式用户态处理。

[guanzhangzhang]

@COW 你这是 k8s 层面考虑，我意思是看每年证书过期的曝出来在程序员群里流传的，基本都是 web 的 https 证书过期。
从终端到访问 web 中间链路上做黑盒检测，相信大厂内部的上网审计设备流量 mirror 扩展或者自己纯软件层面开发 agent 在内部测试环境做 hook 。你看 27 楼和 38 楼他们说的

[qwx]

对于私自签的证书，自己应该管理严格，对于公开证书，我觉得可以去证书透明日志里做监控，接流量+探测太重了，当你知道你管理的出入口有好几个 G 流量的时候，你就知道监控要多少的算力了。

[DHCPv6]

@qwx 透明日志也不错，不过几个 G 的话 NTM 普通 x86 机器也能应付，或者做流镜像。个人感觉做好 PKI 管理与黑盒检测并不冲突，角色不同顾虑不同，对于权限和管理混乱的环境，黑盒检测确有一定帮助。

期待 HTTP/3 与 ECH 大规模运用，逐步架空上网审计设备（

[sagnitude]

@guanzhangzhang 你也说了是管理问题，如果按你这些措施下来，到最后一步，收告警的人不去处理，和我说的有区别吗

[COW]

@guanzhangzhang 哦，我懂你意思了，其实这是个管理问题，不是技术问题。不如搞个各业务线证书自查流程，上报后统一入 CMDB ，遗漏的、出问题的让各业务线自己负责就行了。

[sagnitude]

最简单的，openssl 脚本触发钉钉接口，给全体管理人员发钉钉任务，每天早上八点群发短信，一星期未解决给公司全体成员群发邮件，到期未解决，全员连坐，当年绩效全部扣除

[chunjilikafa1456]

@guanzhangzhang #36 硬件，信创国密要求不能搞软件的

[jiangzm]

@guanzhangzhang #35 你这有点离题了，作为一个开发把家里的电脑做宿主机弄个单节点 k8s 做测试不是很正常吗，同时又有 docker 应用部署也很正常。不管用哪个工具能达到目的就好。

[mizuki9]

再过 3 年，证书最长有效期缩短至 47 天，不就没问题了。现在就是证书时间太长了没人管

[leehaoze98]

没太搞懂你说的测试环境的出口网络设备是啥意思。如果我没理解错的话，是镜像出口流量，拿到真的有被用的域名，然后去发请求看域名过期没过期。

对于大厂，镜像流量的成本过高，机房也很分散，多地域多机房加这个有点复杂。实际的操作里，证书其实是公司级别的流量入口处，收敛起来统一管理和续期的，流量到了我们业务这里已经是解密后的 HTTP 流量了，证书过期前的预警和续期都是标准化的操作，点两下就完成了。

不过实际中还是会出现证书过期的情况，一些老业务，没有使用公司统一的域名，这种的证书还是业务自己管，就有可能忘了续期。

[pingdog]

这种只能架构师搭建的时候考虑，后来人是极难推动任何跨多业务的改动
除了在一个追求完美架构的公司，否则只会吃力不讨好

[guanzhangzhang]

@leehaoze98 思路和 38 楼那个差不多，那个应该是支持更多扩展

[eryajf]

支持馆长。
我这个小工具，也是在尝试辅助解决这个场景的一些问题： https://github.com/opsre/cloud_dns_exporter

[yungyu]

这个事情你自己就可以做啊
openssl 命令就可以解析证书，你配置一个域名名单，都不用每天跑。
存量跑一次记录下过期时间，后面就只要在过期时间之前半个月啥的再回访确认下就行。

名单需要逐步的维护好，可以先维护 主流程、强依赖的域名

[7yu]

苹果也干过这事，世界就事草台班子

[yungyu]

echo | openssl s_client -connect baidu.com:443 2>/dev/null | openssl x509 -noout -dates

linux 上试试

[edsion996]

我理解没有一个人或部门能管理所有“自家域名”。因为没法确定哪个域名还在用、新申请的域名是否提交给你进行监控。

[dmanbu]

不用那么麻烦，一个 blackbox_exporter 就能实现证书过期告警
但问题是现在很多团队没运维了，没人专门搞这些

[strobber16]

我上家就有。tls 端口被监控系统主动探测。因为是做 saas 的，除了自己域名还有客户域名。每次客户域名快到期了我们还得去催客户提供新的证书

[hackroad]

正规公司对于业务相关的域名 SNI 检测监控是有的，当然也有很多人为原因忽略了，运维的“锅”

[deepzz]

推一波： https://cm.myssl.com

[RexKang]

证书：我真的还想再活五百年

[guanzhangzhang]

@yungyu #54 看看 38 楼

[guanzhangzhang]

@dmanbu LOL 前几天那个证书就是上古遗留交接来交接去的遗漏的，我指的是这种未知的，从黑盒未知角度上探测的，你说的都是基于已知和统一管理的，但是现实情况千奇百怪，需要有一些兜底手段

[guanzhangzhang]

@edsion996 是的，各种交接情况和历史遗留因素造成了大厂的个别域名 https 证书过期

[guanzhangzhang]

@yungyu #52 LOL 前几天那个证书就是上古遗留交接来交接去的遗漏的，我指的是这种未知的，从黑盒未知角度上探测的，你说的都是基于已知和统一管理的，但是现实情况千奇百怪，需要有一些兜底手段。你可以看下 38 楼的评论

[rb6221]

大公司+基建完善，基本上不会出问题，出问题也很快解决。
小公司+基建不完善，其一是业务少、实际影响范围并不大，其二是业务简单、修复起来也很快，而且小公司一个电话随便摇人，修复也不需要走繁琐流程。
大公司+基建不完善，这种情况少之又少。这次只是被你遇到了而已。就像上面说的，成本问题。

[salmon5]

端口镜像你不知道要多少成本吧？ 1G/10G/40G 端口镜像，成百上千的出口设备都做镜像到专用的服务器？运行你的所谓的分析程序，就为了分析一个证书到期问题？

[salmon5]

我觉得可以打通地球南半球和北半球，这样地球一年四季如春，都比你这方案靠谱

[salmon5]

你这黑盒也是马后炮，实际中就是管理问题，当时这个程序员没有做好测试和验证，没有考虑到证书到期问题，他的 leader 也没考虑到

[salmon5]

https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-28.html
2019-10-14 发布，DBA 习惯二进制安装，默认启用了 SSL ，默认有效期 10 年；
2029-10-14 后会有陆陆续续的证书过期问题，导致数据库连接失败

你是不是再来一个方案，镜像所有数据库的流量？

[ihciah]

@salmon5 > 端口镜像你不知道要多少成本吧？ 1G/10G/40G 端口镜像，成百上千的出口设备都做镜像到专用的服务器？
假设客户端一定有走 TLS 协议的，那么就只需要抓 TCP 443 的前几个包就够用了。

[MacsedProtoss]

你搁这搞笑呢，罗技是 developer 证书挂了，又不是 ssl 证书，在这立个假靶子？

[mintongcn]

发现证书过期方式很多，过期后怎么处理麻烦。

[yungyu]

@guanzhangzhang #64 你这种 roi 很低的，因为一些边缘的、冷门的流量，去镜像处理所有流量。有点 大炮打蚊子 的意思。不过可以短暂跑一阵，把没有录入 cmdb 的域名收集起来，作为后续运维、监控的蓝本。
给自己手上的东西做好配套的稳定性保障手段就行吧，我感觉不会有公司像你这么玩的，除非那种全站 qps 几百上千的可能会，但是这点流量的小公司也不至于那么混乱吧。

[ofyann]

最开始没做，后面的人也不会去做这类没收益的事。

[hanyuwei70]

uptime-kuma 里面已经自带此类功能了啊，过期前甚至可以给你提报警。运维自己不加告警怪得了谁？

[Daybyedream]

真在意写个监控项然后快到期了告警就行了。
没人说呀，屁大点事。

[Lee2019]

老哥你方案太重了。
https://github.com/enix/x509-certificate-exporter + https://github.com/prometheus/blackbox_exporter
这哥俩一个把 k8s 集群里用的证书监控了，一个把域名的证书监控了
如果怕域名监控不全，写个脚本定期去抓一下，然后改配置文件就齐活了

要是还有别的证书过期了不知道，就认栽吧。

[dcdlove]

一个 ssl 证书 让这些云服务商和国产化的片子赚得满嘴流油

[wzy44944]

往前几年可能是没有监控告警的问题，发展到现在，这种问题一般是域名分散在很多部门，历史上又有交接，会出现收到告警的人和实际负责人不一致，收到告警没人处理等等各种非技术问题，实际上是公司资产统一管理的问题