auto-ssl / lua-resty-auto-ssl

On the fly (and free) SSL registration and renewal inside OpenResty/nginx with Let's Encrypt.
MIT License
1.93k stars 182 forks source link

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

Closed luuk-ou closed 3 years ago

luuk-ou commented 3 years ago

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 :+1:

luuk-ou commented 3 years ago

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 :)