EaseProbe v2.1.2 TLS证书校验问题分析

在EaseProbe v2.1.2版本中，用户发现了一个与TLS证书校验相关的关键问题。当使用TLS检查Kubernetes API服务器证书（由未知机构签发）时，系统会错误地显示证书过期时间为默认值"0001-01-01 00:00:00 +0000 UTC"，而不是实际的证书过期时间。

问题现象

该问题主要出现在以下场景：

1. 当检查由未知CA签发的证书时（如自签名的Kubernetes API服务器证书）
2. 启用了insecure_skip_verify选项
3. 在Prometheus指标EaseProbe_tls_earliest_cert_expiry中显示错误的时间戳

相比之下，检查由已知CA签发的证书（如baidu.com的证书）则表现正常。

问题根源

通过代码分析发现，这个问题源于v2.1.2版本中metrics.go文件的修改。具体来说：

1. 在PR #386中，开发者添加了常量标签
2. 同时错误地将LastChainExpiryTimestampSeconds重命名为EarliestExpiry
3. 导致代码中出现了两个EarliestCertExpiry赋值语句
4. 第二个赋值语句覆盖了第一个的结果，将有效的时间戳重置为time.Time{}的默认值（Unix时间戳-62135596800）

技术影响

这个bug会导致以下技术影响：

1. 监控系统无法正确获取自签名证书的实际过期时间
2. 可能影响基于证书过期时间的告警机制
3. 对于Kubernetes集群监控特别重要，因为大多数Kubernetes API服务器使用自签名证书

解决方案

修复方案相对简单：

1. 恢复正确的指标名称LastChainExpiryTimestampSeconds
2. 确保不重复赋值EarliestCertExpiry
3. 保持与v2.1.1版本一致的行为

最佳实践建议

在使用EaseProbe进行TLS检查时，建议：

1. 对于生产环境，尽量使用由可信CA签发的证书
2. 如果必须使用自签名证书，考虑暂时回退到v2.1.1版本
3. 定期验证监控系统报告的证书过期时间是否准确
4. 对于关键系统，实施多层证书过期监控机制

这个问题已在后续版本中得到修复，用户升级到最新版本即可解决。