Closed
Description
Overview
To illustrate, this is the result when specifying the server value as an IP Address and the DNS Name as a valid host value associated with the certificate:
$ go build ./cmd/lscert && ./lscert.exe --server 142.251.45.228 --dns-name www.google.com
======================
CERTIFICATES | SUMMARY
======================
- OK: 1 certs retrieved for service running on 142.251.45.228 at port 443
- CRITICAL: Hostname validation using value "www.google.com" failed for first cert in chain
- OK: SANs List validation ignored: 0 SANs entries specified, 0 SANs entries on root cert [0 EXPECTED, 0 MISSING, 0 UNEXPECTED]
- OK: Expiration validation successful: root cert "invalid2.invalid" expires next with 2526d 13h remaining (until 2030-01-01 00:00:00 +0000 UTC) [EXPIRED: 0, EXPIRING: 0, OK: 1]
============================
CERTIFICATES | CHAIN DETAILS
============================
Certificate 1 of 1 (root):
Name: CN=invalid2.invalid,OU=No SNI provided\; please fix your client.
SANs entries: []
Issuer: CN=invalid2.invalid,OU=No SNI provided\; please fix your client.
Serial: 90:76:89:18:E9:33:93:A0
Issued On: 2015-01-01 00:00:00 +0000 UTC
Expiration: 2030-01-01 00:00:00 +0000 UTC
Status: [OK] 2526d 13h remainingThis was fixed for the check_cert plugin with atc0005/check-cert-old#460, but not for lscert. At the time the perceived scope of the fix was just properly noting which host value was used to retrieve the certificate, not also fixing the lack of a host value in the cert retrieval attempt.
The lscert tool requires the same fix (since this portion of the logic is not yet shared).