I'm using ssl-cert-check to track a list of my domains certificates.
In my crontab I set it to run quietly and email me expiring domains, but the command that I'm using to debug is:
ssl-cert-check -f ssldomains.txt -x 21 -i
It is correctly reading the file and retrieving the certificates for the entire list, but it does not appear to be getting the correct expiry date for certificates issued by LetsEncrypt.org
Other certificate providers do not seem to be affected by this problem.
For example a certificate that is expiring on 24 March 2017 when I inspect it in my browser is reported to be expiring on 15 Jan 2017.
I'm serving with nginx.
Why would the CLI tool be retrieving the wrong expiry date and how can I correct this?
This seems to be an SNI problem. If you provide multiple SSL certificates on the same IP the client sends the host name along with the initial request, so the server can provide the correct certificate. Older versions of ssl-cert-check don't do that, the feature was introduced with version 3.27.
Both Ubuntu versions 14.04 and 16.04 ship version 3.27, but it seems like the feature is bugged in this version. There are basically two lines of code that are relevant:
and:
As you can see, the variable is set to FALSE and later it is checked for TRUE, but it is never changed.
The current version on GitHub (3.30) has an additional code block:
This checks the installed openssl version for the servername support. When I add this block into the script on my local Ubuntu installation the result is fine, without the block I get the wrong certificate, just like you.
So, this is a bug, which has been fixed by the author, but hasn't found it's way yet into the Ubuntu repository. You can fix it yourself and hope after the next update the repo contains a fixed version, or you use the script from github instead.