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: 157.46.154.48, 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: 157.46.154.48, 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 20.219.20.151.

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 *.codedesign.app (not codedesign.network).

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
5 Likes

Hi Mike,

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 https://acme-v02.api.letsencrypt.org/directory
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.

1 Like

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)

6 Likes

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:

2 Likes

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