自动续期解决了大多数问题，但在博客、NAS、自建服务和小团队场景里，证书到期仍然很容易被忽略。
一些运维中的小事你可能会觉得不入流，就譬如SSL 证书到期或许不是一个值得单独拿出手来讨论的问题。市面上的Let's Encrypt 已经很成熟，acme.sh、Certbot、Nginx Proxy Manager、群晖反向代理、各类云厂商和面板工具也都能处理证书申请与续期。常规来讲只要第一次配置好，后面理论上就可以交给自动化。但后来我发现，事情没有想象中那么爽利，任何事情不怕一万就怕万一，这也是墨菲定律的核心思想。
有些用户可能仅仅只有一个网站、一个域名、一个固定的部署环境，证书确实不太需要操心。可是当手里的服务慢慢变多以后，情况就会变得复杂：一个域名在云服务器上，一个入口挂在 NAS 反向代理后面，一个测试 API 放在 Docker 里，还有几个很久以前搭过、但一直没有下线的小工具站。这些服务零零碎碎的构成了你的技术生活的痕迹，但也因为分散，你或许都有些时候已经忘记哪一个服务是什么了？上一次打开它时什么时候？部署它的命令还记得吗？最后，你还记得它的后台登录地址吗？
那些服务有的靠面板续期，有的靠脚本续期，有的依赖 DNS API，有的只是当时手动处理了一次。平时它们都很安静，能打开，也不会提醒你什么。这个时期，你会觉得事情很顺，多一事不如少一事，技术就是要纯粹（偷懒）。
直到某一天，你访问时浏览器突然弹出证书错误。服务器没宕机，应用没崩，DNS 没问题，反向代理也还在工作。真正的问题只是证书过期了。然后你还在外面玩，或者只是聚餐时，向老友炫一下你的成果。又或者很尴尬的是：你在面试，正在向面试官展示你的project，然后浏览器防护等级较高，提示这是一个危险的网站！
从技术上看，这不是一个复杂故障。但从访问者的角度看，他看到的是一个很明确的安全警告。对个人博客、小团队网站、工具站或者自建服务来说，这种体验很尴尬。假如是面试的场景，那就是脚趾头扣地了，准备不充分，也不能怪谁了。
这些因素就是我后来做 SSL Reminder 的原因，当然我没有在面试时遇到这么悲伤的经历，但是这的确是一个警示案例，居安思危防范于未来，攻城狮们。
自动续期很省事，但它不是永远不用看
大多数证书自动续期本身没问题，我也一直在用。真正的问题是，自动续期背后依赖的东西并不少。定时任务要正常跑，DNS API 权限要有效，容器不能异常停止，面板要能正确写入证书，反向代理也要确实绑定到新证书。
可能有时候证书已经续下来了，但服务仍然指向旧证书（未成功部署新证书）；有时候续期脚本失败了，但你没有收到通知；还有些临时服务后来变成了长期服务，但证书管理方式还是当初那个临时方案，备胎转正，却没有享受应有的待遇，你有啥想法没。
这些事儿发生的概率很低，所以更经常容易被忽略。你会记得夏天穿短裤出门遛弯被蚊子叮咬，又红又痒，但是呢？假如你一年到头都生活在南极，你从来不知道有一种蚊虫叫蚊子，靠吸食人血为生，那么你来南方的夏天，你就什么防护都不做，然后你就会刻骨铭心的记住，南方的蚊子真的很大一叮一大包。
很多家庭环境基础设施里的小问题都是这样：平时没有存在感，一旦被用户看见，就已经晚了一步。SSL 证书到期就是其中很典型的一类。
我为什么没有直接用完整监控平台解决
事实上，这件事可以用完整监控平台解决，就看你想不想。Uptime Kuma、Prometheus、Grafana、云监控、企业告警平台，都可以做证书状态检查。对于生产环境或者团队服务来说，这些方案也更完整。但若你只是一个家庭用户，杀鸡用牛刀，这把刀太大了，可能还没地方放，毕竟以上那些自建服务都是需要7*24运行的，存储+计算+网络+电费，一样都不能少。这是我想解决的一个轻量级应用场景的根源思考。
有些人只是维护几个公网域名、一个博客、几个 API、一个 NAS 反代入口，或者一些长期运行的小工具站。不是每一个用户都是专业的IT，所以即使他完成了部署一个应用，不代表也能接来下部署一套监控规则，或许对他们来说，甚至都不了解SSL证书有收费和免费的区别，一句话概括为能用就行。对于我来讲：构建一个轻便的架构、简洁的界面、提供适当的额度，开放给有需要的用户，让他们和我一样打开iPhone能看到哪些证书正常，哪些快到期，哪些检查失败。平时不打扰，快出问题时提醒一下，这是一件很有成就感的事情。
所以 SSL Reminder 一开始就不是按完整监控平台来设计的。它只做一件事：记录 SSL/TLS 证书目标，并在证书快到期或检查失败时提醒你。
SSL Reminder 的开发进度
到目前为止，SSL Reminder 已经更新到第三个版本，运行稳定，不占内存，秒开免费。它目前支持添加最多 15 个证书目标，采用云端检查的方式，每天检查公网 SSL/TLS 证书状态，并在证书快过期或检查失败时通过 iPhone 推送提醒。
在 App 里，可以看到证书的剩余天数、状态、签发者、主体信息和一个简单的健康报告。它不需要注册账号，也没有广告，目标数据支持导入、导出和删除。
我把它构造的比较精炼，也就是把它做得比较轻。证书提醒这件事本身不应该变成另一个需要维护的系统。在实际应用场景，对个人用户来说，只要能把几个重要证书看护住，就已经够用了。15 个目标看起来不算多，但对个人站长、独立开发者、NAS 用户或者小团队来说，通常足够覆盖主站、博客、API、反向代理入口、工具站和少数几个长期运行的服务。
运作机制的概述
软件当前采用云端检查，所以它更适合公网可访问的 HTTPS 服务。如果用户的服务只在局域网、VPN 或私有网络里访问，云端检查器可能无法访问到它。这并不代表证书一定有问题，只是外部检查服务连不到这个地址。所以，内网 NAS、PVE 后台、路由器管理页这类服务，如果没有公网入口，就不适合用这种云端方式检查。但是缺失内网监测这个不是功能缺陷，这是软件架构设计，如果用户有理由上内网检测需求，可以参考OpsHome NOC方案。
做这个小工具后的一个感受
经历过真实的基础设施问题，次数多了，我个人越来越觉得，次数多的反而并不是那种天崩地裂的大故障。更多时候，是一些小东西在后台慢慢变质了。譬如：面板定时任务停了，域名指向旧环境，备份很久没检查，证书快过期了，一个很少访问的服务，因为一些原因突然被频繁访问起来又变得重要了。这些事情平时都不显眼，但一旦被用户看见，就会变成明确的问题，家庭环境的部署应用，它的生命周期有时候很长有时候很短，完全取决于用户的使用频率。作为应用的底层支持组件的SSL证书，在互联网上的证书千千万万，属于用户的证书也就那么几个，请看护好自己的数字资产，用免费的IOS软件去看护免费的SSL证书，这刚刚好，体现了够用就行的极简原则。
SSL Reminder 只解决其中很小的一件事。它不会替代完整监控平台，也不想替代。但如果它能让一个人提前发现证书快过期，而不是等浏览器替他提醒用户，我觉得这个小工具就有价值。
写在最后
假如你已经有完整的监控系统，SSL Reminder 可能不是刚需。你完全可以继续用现有方案，而且完整监控平台在复杂场景下一定更强。
但如果你只是维护几个公网网站、博客、API、NAS 反向代理入口或者小工具站，不想额外部署一套服务，只想用手机简单盯一下证书状态，它应该能省一点心。
App 目前已经上架 App Store，感兴趣的话可以搜索 SSL Reminder，或者通过下面的链接查看：
https://apps.apple.com/app/ssl-reminder/id6786519365
