-f option not working (when running on a server without ssl on port 443)

[cstsw]

Since the commit from last friday (2020-01-17) the file-option is not working for me.

ssl-cert-check tries to connect to the local server (via it's dns name) on port 443 and get's a connection refused (since the server from which the script is running does not listen for https-connections on port 443).

If I provide a port on which my server is listening for https-connections via -p the script switches to interactive mode.

Apart from the port number: IMHO the script should not depend on an https-listener running on the server from which the script is executed.

[Matty9191]

How are you calling ssl-cert-check? The file checking option works OK for me:

$ ./ssl-cert-check -c prefetch.net.pem Host Status Expires Days

---

FILE:prefetch.net.pem Valid Apr 13, 2020 84

[Matty9191]

I also verified the "-f" option is working as expected. The following article has several examples which run OK on my laptop:

https://prefetch.net/articles/checkcertificate.html

[cstsw]

After a git checkout from your repo I just call (via Jenkins once per week):

ssl-cert-check -f (file containing server:port entries linewise)

The file hasn't changed for the last few months, hence it can't be the issue.

I observe the aforementioned behaviour even with no parameters at all (e.g. if I do './ssl-cert-check' via shell in the same directory).

[Matty9191]

Can you send me the file you are using? I've tried numerous permutations and can't re-produce this. :(

[cstsw]

The attachment contains the publicly accessible servers from the file I am using.

serverlist-42.txt

Even this reduced version of my serverlist shows the problem described above, i.e. when I call ./ssl-cert-check -f serverlist-42.txt

... I get the following output:

Host                                            Status       Expires      Days
----------------------------------------------- ------------ ------------ ----
s0001351:443                                    Connection refused Unknown  0,    0    0

(s0001351 is the server on which ssl-cert-check is executed. It actually listens for SSL-Connections—which IMHO should not be a necessity for the script to work—but not on port 443.)

[Matty9191]

The latest versions runs OK against the file you provided:

$ ssl-cert-check -f serverlist-42.txt -i

Host Issuer Status Expires Days

---

www.munzinger.de:443 Let's Encrypt Valid Mar 8 2020 46 beta.munzinger.de:443 Let's Encrypt Valid Mar 1 2020 39

Do you have a firewall or system configuration that is preventing you from connecting to TCP port 443? What happens if you run $(nc -v beta.munzinger.de 443)? Does it connect?

[cstsw]

The connection to TCP Port 443 on the hosts www.munzinger.de and beta.munzinger.de works.

nc -v beta.munzinger.de 443 results in

Connection to beta.munzinger.de 443 port [tcp/https] succeeded!

[cstsw]

Thanks for your tests and your patience, Matty!

As the issue seems to depend on my environment I'll try to find out for myself why the script tries to connect to it's own host (as soon as I have time to).

I'll report my results here which hopefully help to make the script more robust.

[cstsw]

I just found the reason for the problem mentioned above and as expected it is related to my environment: the variable HOST is set in my environment variables during the startup of my server.

In https://github.com/Matty9191/ssl-cert-check/blob/master/ssl-cert-check#L901 this variable is checked, assuming that it was provided via the -s parameter, though in my case it is already set before the ssl-cert-check script is invoked.

I can work around this issue by unsetting HOST before the script is invoked. Or maybe ssl-cert-check can be made more robust by initially unsetting the variables it uses so that they don't interfere with environment variables.