auto-ssl: failed to parse expiry date: could not parse openssl time string

[luuk-ou]

Hi,

A week ago I updated our servers to openresty/1.19.3.1 (from openresty/1.17.x.x), compiled with OpenSSL 1.1.1f to enable support for TLS1.3. I subsequently ran into the OCSP stapling issue #239. Still not sure if the openresty update is the cause of this, as I never had the OCSP stapling issues before.

I then applied the work around to remove the "due to expire" certs from redis (w/ openresty restart) as per #239. However I am now faced with the error message of:
2020/12/23 18:01:18 [error] 27666#0: *1431520 [lua] hook.lua:49: server(): auto-ssl: failed to parse expiry date: could not parse openssl time string: 1616518875, client: 127.0.0.1, server: , request: "POST /deploy-cert HTTP/1.1", host: "127.0.0.1:8999"
This message seems to indicate that the cert expiry timestamp is now retrieved in unix time format instead of the expected date format of "MMM DD HH:MM:SS YYYY [GMT]". Maybe due to the OpenSSL library in use. I've forked the repo so I can modifyto support this use case.

Software version used:

nginx version: openresty/1.19.3.1
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)
built with OpenSSL 1.1.1f 31 Mar 2020

lua-resty-auto-ssl
0.13.1-1 (installed) - /usr/local/openresty/luajit//lib/luarocks/rocks

lua-resty-http
0.15-0 (installed) - /usr/local/openresty/luajit//lib/luarocks/rocks

Has anyone come across this?

On another note; related to building and running tests on the forked repo. I receive intermittent failed assertions of the same test case "./spec/expiry_spec.lua @ 101: expiry removes cert if expiration has expired and renewal fails". Not finding the expected string of "Ignoring because renew was forced!". Only 1 out of 5 times the test seems to pass seems to work. Anyway I will have a closer look at that as well. I am a little new to this project so any guidance would be appreciated! I will report my findings 👍

[luuk-ou]

I finally had some time to look at this. And upon closer examination I noticed the error is during the deploy-cert stage of requesting a new cert. As it turns out the custom hook script used by hydrated contained some older code that was still using the 'date' function.

As per #195 I manually extracted the date from the cert to see what EXPIRY date would be set by the script. The command: $(date --date="$(openssl x509 -enddate -noout -in "$CERTFILE"|cut -d= -f 2)" +%s) returned a date in epoch format, not the expected format of MMM DD HH:MM:SS YYYY [GMT].

So in my hook script I replaced:
if ! EXPIRY=$(date --date="$(openssl x509 -enddate -noout -in "$CERTFILE"|cut -d= -f 2)" +%s); then
with
if ! EXPIRY=$(openssl x509 -enddate -noout -in "$CERTFILE"); then

and all is dandy :) Sometime it helps to look at things with a fresh pair of eyes :)