Curl returned with 35 error

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:, server:

2022/12/26 13:08:48 [error] 3722673#0: 97 [lua] ssl_certificate.lua:291: auto-ssl: could not get certificate for - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua, client:, server:

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 --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; curl returned with 35)

Is this an issue with our end or has LetsEncrypt blocked our Ip address? The ip address in question is

A curl(35) is not the typical response when your IP is blocked. This is more likely on your end.

Testing connections to 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 * (not

The only certs in the history for 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

curl -i

Hi Mike,

Thank you for the reply. The wildcard certs are configured to * 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 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 

and as you can see, that's what I get. On my local machine, it doesn't throw the error.

1 Like

What about this?

echo | openssl s_client -connect | 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. :slight_smile:


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.