Is the '25' in 606025 intentional to give a bit more margin or should it just have been 24?

Ha, I guess I made a typo when I wrote the script 6 months ago. At least I cannot remember that I had some clever idea back then, why a day should have 25 hours.

Fixed now. Thanks.

Always have days having 25 hours... for DST.

Don't call it from tests though, call it from a monitoring system!

In case anyone is looking for a good option, I've had great success with InfluxDB's telegraph utility which automatically checks both uptime and certificates for HTTPS endpoints, combined with a grafana dashboard that sends alerts when the deadline approaches.

What shell are you running this under? Unquoted exclamation marks will do things that may be outside your intent for this script. It’ll still fail, just perhaps not in the way you expect.

You mean due to history substitution? If so: I have never seen that kick in in a script. Only in interactive shells.

Hmm, if I copy/paste this, I get a different output:

    ~  ~/certdays.sh google.com 14
    date: illegal time format
    usage: date [-jnRu] [-d dst] [-r seconds] [-t west] [- 
    v[+|-]val[ymwdHMS]] ...
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] 
    [+format]
    google.com: -18568
    -n Lasts longer then 14 days?
    NO!!!!!!!!!!!!!!

You can brew install coreutils and edit it to use gdate instead of date.

Are you running it on macOS or something non-Linux?

Ah, yes I am running it on macOS Mojave

Works for me. In Bash? Maybe copy/paste gone wrong?

I have put it into a Github repo now and put the link into the post. Does that work for you?

We can also use ssl-cert-check cli tool. `ssl-cert-check -s avilpage.com -p 443 -x 30` will return if the certificate will expire in 30 days.

We can use this command in CI pipeline or setup a cron job to monitor it.

Thanks awesome script!