[BUG] tls bug in v2.1.2, but ok in 2.1.1

[Zhang21]

Environment (please complete the following information):

• OS: Linux
• EaseProbe Version: v2.1.2

Describe the bug use tls to check k8s apiserver cert((signed by unknown authority), the cert expiration date is incorrect, use the default 0001-01-01 00:00:00 +0000 UTC.

tls checks insecure_skip_verify cert(signed by unknown authority) will be incorrect about prometheus metric EaseProbe_tls_earliest_cert_expiry。

such as tls checks k8s apiserver cert（127.0.0.1:6443）。

cert signed by known authority is ok（www.baidu.com:443）!

# v2.1.2
# 127.0.0.1:6443
EaseProbe_tls_earliest_cert_expiry
# 0001-01-01 00:00:00 +0000 UTC
-62135596800

Expected behavior The result is the tls x509 cert.NotAfter.Before timestamp.

# v2.1.1
# 127.0.0.1:6443
EaseProbe_tls_earliest_cert_expiry
# 2032-07-03 06:42:46 +0000 UTC
# Earliest Certificate Expiry: 2032-07-03 06:42:46 +0000 UTC
1972449766

[Zhang21]

codes change in v2.1.2

[Zhang21]

codes: https://github.com/megaease/easeprobe/blob/main/probe/tls/metrics.go#L46C1-L54C2

time.Time{}.Unix() is -62135596800.

[suchen-sci]

It seems in this pr https://github.com/megaease/easeprobe/pull/386/files#diff-f4ba94b6ceb9d73b8797e5ca558f756010112d0d6b71ca4ffcdf3da10fbe2c1f, the author add constant labels and change LatChainExpiryTimestampSeconds to EarliestExpiry by mistake, as a result there are two EarliestExpiry?

If you change it back, will the problem be solved? If it is solved, could you make a pr to fix it?

[Zhang21]

yes, double t.metrics.EarliestCertExpiry here. the 2nd t.metrics.EarliestCertExpiry rewrite LastChainExpiryTimestampSeconds to EarliestCertExpiry.

[Zhang21]

@qdongxu You need to fix it.