2

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?

Andy
  • 307
  • 2
  • 5
  • 16
  • How old is your ssl-cert-check? Older versions didn't have support for SNI, resulting in the wrong certificate to be fetched if you have multiple domains on the same IP. This should be fixed with versions [later than 2014-08-20](https://raimue.blog/tag/ssl-cert-check/) – Gerald Schneider Jan 05 '17 at 12:20
  • 1
    Oh, the tool I linked to seems to be a different one than the one shipped with ubuntu. Still, I'd assume an SNI problem. – Gerald Schneider Jan 05 '17 at 12:23
  • 1
    what distribution are you using? As far as I can see the version of the script that is shipped with Ubuntu 14.04 and 16.04 is bugged. – Gerald Schneider Jan 05 '17 at 12:54
  • Its 14.04 and it looks like a bug because now it's retrieving them all with the date 5th April 2017 (nothing has changed in system setup). – Andy Jan 05 '17 at 12:59
  • If you make your comment an answer I'll accept it. It hadn't occurred to me to RTFS and when I replaced the script with the current version linked in the source it works properly. Thanks for the help! – Andy Jan 05 '17 at 13:02

1 Answers1

2

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:

TLSSERVERNAME="FALSE"

and:

if [ "${TLSSERVERNAME}" = "TRUE" ]
then
     TLSFLAG="${TLSFLAG} -servername $1"
fi

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:

if ${OPENSSL} s_client -h 2>&1 | grep '-servername' > /dev/null
then
    TLSSERVERNAME="TRUE"
else
    TLSSERVERNAME="FALSE"
fi

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.

Gerald Schneider
  • 19,757
  • 8
  • 52
  • 79