#吐槽In reply to nevent1q…28sq_________________________但说实话, 就算无法改变事实真的实施了, 这个激进地缩短证书有效期的操作给的过渡时间太短了, 很多依赖 SSL 证书的业务应用和系统都没准备好应对这种变化, 三年真的够某些系统改造完成添加适应证书自动化更新的特性吗?刚刚在群里, 群友在抱怨 poste.io (一个轻量的电子邮件服务器)无法热重载而让他不能放心地推送证书更新, 如果使用完全重载, 那就只能祈祷这几秒钟的时间里不会收到邮件消息入站了, 否则直接丢失邮件. 这还是目前证书普遍有 90 天的状况.邮件系统是比较特殊的, 这是真正的古董级别消息系统, 内部依赖的 SSL/TLS 是和反向代理不兼容的(至少在我的认知里), MX 邮件服务器直接使用 SMTP 和其他服务器通讯, 反向代理的软件大多是设计给 Web 服务使用的, 而 SMTP 是直接的 TCP 协议, 使用反向代理在邮件服务器实践里面就是不标准的做法. (主要是我也还不会在 TCP 包的转发出现问题的时候 debug)除非, 对邮件服务器在内的这些无法适应的直接改造软件使其适应, 或者切换为集群部署, 但后者在大多数的中小型组织里是很少见的. 某些组织里面改造这些需要的时间和资源大概率也无法适应 "三年之期".via Nostr@cxplay

#吐槽

In reply to nevent1q…28sq
_________________________

但说实话, 就算无法改变事实真的实施了, 这个激进地缩短证书有效期的操作给的过渡时间太短了, 很多依赖 SSL 证书的业务应用和系统都没准备好应对这种变化, 三年真的够某些系统改造完成添加适应证书自动化更新的特性吗?

刚刚在群里, 群友在抱怨 poste.io (一个轻量的电子邮件服务器)无法热重载而让他不能放心地推送证书更新, 如果使用完全重载, 那就只能祈祷这几秒钟的时间里不会收到邮件消息入站了, 否则直接丢失邮件. 这还是目前证书普遍有 90 天的状况.
邮件系统是比较特殊的, 这是真正的古董级别消息系统, 内部依赖的 SSL/TLS 是和反向代理不兼容的(至少在我的认知里), MX 邮件服务器直接使用 SMTP 和其他服务器通讯, 反向代理的软件大多是设计给 Web 服务使用的, 而 SMTP 是直接的 TCP 协议, 使用反向代理在邮件服务器实践里面就是不标准的做法. (主要是我也还不会在 TCP 包的转发出现问题的时候 debug)

除非, 对邮件服务器在内的这些无法适应的直接改造软件使其适应, 或者切换为集群部署, 但后者在大多数的中小型组织里是很少见的. 某些组织里面改造这些需要的时间和资源大概率也无法适应 "三年之期".

via Nostr@cxplay