I am using lua-resty-auto-ssl package with openresty to dynamically generate certificates for my clients (tenants). I got reports that generation of new certificates stopped working, and I was checking the logs and I found this.
2022/12/26 13:08:48 [error] 3722673#0: 97 [lua] ssl_certificate.lua:97: issue_cert(): auto-ssl: issuing new certificate failed: dehydrated failure, context: ssl_certificate_by_lua, client: 220.127.116.11, server: 0.0.0.0:443
2022/12/26 13:08:48 [error] 3722673#0: 97 [lua] ssl_certificate.lua:291: auto-ssl: could not get certificate for codedesign.network - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua, client: 18.104.22.168, server: 0.0.0.0:443
2022/12/26 13:08:52 [error] 3722673#0: 100 [lua] lets_encrypt.lua:40: issue_cert(): auto-ssl: dehydrated failed: env HOOK_SECRET=**
HOOK_SERVER_PORT=8999 /usr/local/bin/resty-auto-ssl/dehydrated --cron --accept-terms --no-lock --domain codedesign.network --challenge http-01 --config /etc/resty-auto-ssl/letsencrypt/config --hook /usr/local/bin/resty-auto-ssl/letsencrypt_hooks status: 256 out: # INFO: Using main config file /etc/resty-auto-ssl/letsencrypt/config
err: ERROR: Problem connecting to server (get for https://acme-v02.api.letsencrypt.org/directory; curl returned with 35)
Is this an issue with our end or has LetsEncrypt blocked our Ip address? The ip address in question is 22.214.171.124.
A curl(35) is not the typical response when your IP is blocked. This is more likely on your end.
Testing connections to
codedesign.network results in a couple problems. One is that connections from various locations often take 30 seconds or more. I think it likely you also have issues on outbound connections.
More importantly, the cert returned is wrong. The cert being used names
The only certs in the history for
codedesign.network are wildcards (link here). Yet, the dehydrated request uses the http challenge. An http challenge does not support a wildcard cert. You must use DNS challenge instead for that.
As for the curl, do these succeed and how long do they take?
curl -i https://cloudflare.com
curl -i https://google.com
Thank you for the reply. The wildcard certs are configured to *.codedesign.app as a fallback so that the nginx doesn't complain when starting up. Our configuration is similar to that of GitHub - auto-ssl/lua-resty-auto-ssl: On the fly (and free) SSL registration and renewal inside OpenResty/nginx with Let's Encrypt.. This used to work for the last 5 months.
The certs are generated on the fly and codedesign.network doesn't have any prior certificates.
Both the commands return data. However, I found a suggestion to run
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to acme-v02.api.letsencrypt.org:443
and as you can see, that's what I get. On my local machine, it doesn't throw the error.
What about this?
echo | openssl s_client -connect acme-v02.api.letsencrypt.org:443 | head
And, an aside,
It absolutely does as shown by the link I provided (here)
It automatically appears to have resolved on its own. The curl call and the certificate generation are now working as expected.
Not sure what went wrong, but thank you for the help Mike.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.