Fails to extract expiry date from cert

[im-erikjohansson]

Thank you very much for the release of 0.13.0, awesome work! However, I´m experiencing some issues after the upgrade to 0.13.0. I'm using letsencrypt.

2019/09/30 11:34:10 [error] 17#17: *24188 [lua] renewal.lua:102: renew_check_cert(): auto-ssl: failed to extract expiry date from cert: Executing command failed (exit code 1): date --date="$(openssl x509 -enddate -noout -in "/etc/resty-auto-ssl/tmp/extract-expiry-www.mydomain.com"|cut -d= -f 2)" +%s 2>&1
Output: date: invalid date 'Nov 30 04:31:45 2019 GMT'

I ran the command manualy on the server and got the same error:

bash-4.4# date --date "$(openssl x509 -enddate -noout -in cert.pem | cut -d= -f 2)" +"%s"
date: invalid date 'Nov 30 04:31:45 2019 GMT'

According to the man-page for Date it only recognizes these time formats:

Recognized TIME formats:
hh:mm[:ss]
[YYYY.]MM.DD-hh:mm[:ss]
YYYY-MM-DD hh:mm[:ss]
[[[[[YY]YY]MM]DD]hh]mm[.ss]
'date TIME' form accepts MMDDhhmm[[YY]YY][.ss] instead

I don't know, perhaps this is an issue only with letsencrypt certs?

[GUI]

@im-erikjohansson: Sorry for the trouble! Can you let me know what operating system you're on, and what date --version reports?

[GUI]

Oh, actually I see this might be related to the Alpine/BusyBox version of date. I believe if you install the coreutils package (apk add coreutils), this should provide a compatible version of the date command. However, this is good to know about, since if we've introduced an extra dependency in v0.13.0 that may not have been intentional. So as a quick fix, hopefully installing coreutils will fix this, but I can also look into whether we can get this working against the BusyBox version of the date command too.

[im-erikjohansson]

Thanks for the fast reply @GUI
I'm running on the docker image openresty:1.13.6.2-2-alpine-fat with BusyBox v1.28.4

Upgrading to the latest release of Openresty will give me BusyBox v1.29.3 still gives the same error it seems.

bash-4.4# date --date "Nov 30 04:31:45 2019 GMT" +"%s"
date: invalid date 'Nov 30 04:31:45 2019 GMT'

Your proposed fix of adding coreutils seems to do the trick:

bash-4.4# date --date "Nov 30 04:31:45 2019 GMT" +"%s"
1575088305

[GUI]

Good deal, thanks for confirming.

For more context, if other people are running into this, I don't believe this error in the error log should necessarily affect the primary behavior of lua-resty-auto-ssl. The error may keep showing up, since we'll keep trying to extract and store this expiry date from existing certs, but I think most everything should continue working despite this error. It actually looks like we added a dependency on the GNU version of date in the v0.12.0 release due to #111 However, that error may not have gotten logged to the nginx log file, so it may have been silently being ignored. I believe things should have continued to work fine, just less efficiently, since without the expiry being stored in our own storage, we'd attempt renewals more frequently. What changed in v0.13.0 was we'd make additional attempts to extract the expiry dates on each renewal loop due to the changes in #128. If the expiry date extraction fails in the new pieces of code, then this is now getting logged in a more obvious place. So in some way, this was more of a silent issue with v0.12.0 that just became more obvious in v0.13.0.

I believe this will also be an issue on FreeBSD or other BSDs, due to the different behavior of date on BSD systems. However, I'm not sure if installing coreutils will fix it on those systems, since I don't believe installing that package takes over the primary date utility.

Anyway, while installing coreutils on alpine-based images does fix this, I will try to get get a v0.13.1 release out soon that removes this GNU date dependency (by shifting the date parsing to Lua) for better cross-platform compatibility.

Thanks for reporting this!

[GUI]

v0.13.1 is now out and should work in Alpine without the coreutils package installed (or in other OS variants without the GNU version of date). Let me know if you're seeing any issues with the new version, but thanks again for reporting this!