auto-ssl / lua-resty-auto-ssl Goto Github PK

2017/05/06 12:14:37 [error] 9610#9610: *68 [lua] lets_encrypt.lua:62: issue_cert(): auto-ssl: dehydrated manual hook.sh failed: env HOOK_SECRET=32cffc43cb.... HOOK_SERVER_PORT=8999 /usr/local/openresty/luajit/share/lua/5.1/resty/auto-ssl/shell/letsencrypt_hooks deploy_cert xxx /etc/resty-auto-ssl/letsencrypt/certs/xxx/privkey.pem /etc/resty-auto-ssl/letsencrypt/certs/xxx/cert.pem /etc/resty-auto-ssl/letsencrypt/certs/xxx/fullchain.pem /etc/resty-auto-ssl/letsencrypt/certs/xxx/chain.pem 1494072877 status: 256 out: hook request failed
(...)
++ cat /etc/resty-auto-ssl/letsencrypt/certs/xxx/privkey.pem
+ local 'PRIVKEY=-----BEGIN RSA PRIVATE KEY-----
(...)

When the hook fails, the private key is written to the log verbatim. While logs are usually only readable by root, this can still be a problem in systems which stream logs via syslog-ng. There are also many setups using the ELK stack to collect logs centrally.

are any multi-subdomain servers actually using this in production? seems unlikely

The following is showing up in the error logs:

sh: 1: /usr/share/nginx/luajit/share/lua/5.1/resty/auto-ssl/shell/start_sockproc: Permission denied
2017/02/15 09:58:53 [error] 2013#2013: *1 [lua] start_sockproc.lua:10: auto-ssl: failed to start sockproc, context: init_worker_by_lua*

root owns that file, should it be owned by www-data in order to start?

The original project was renamed due to trademark violations, from "letsencrypt.sh" to "dehydrated".
You probably want to rename things in your project, too.

First request that require server to issue a certificate is stuck on "Establishing secure connection".
After some time this shows in logs:

2016/07/23 15:26:24 [error] 9#9: lua tcp socket read timed out, context: ssl_certificate_by_lua*, client: 10.0.0.1, server: 0.0.0.0:443
2016/07/23 15:26:24 [error] 9#9: [lua] lets_encrypt.lua:20: issue_cert(): auto-ssl: letsencrypt.sh failed: env HOOK_SECRET=*** /usr/local/openresty/luajit/share/lua/5.1/resty/auto-ssl/vendor/letsencrypt.sh --cron --domain *** --challenge http-01 --config /etc/resty-auto-ssl/letsencrypt/config.sh --hook /usr/local/openresty/luajit/share/lua/5.1/resty/auto-ssl/shell/letsencrypt_hooks status: -1 out: nil err: timeout, context: ssl_certificate_by_lua*, client: 10.0.0.1, server: 0.0.0.0:443
2016/07/23 15:26:24 [error] 9#9: [lua] ssl_certificate.lua:70: issue_cert(): auto-ssl: issuing new certificate failed: letsencrypt.sh failure, context: ssl_certificate_by_lua*, client: 10.0.0.1, server: 0.0.0.0:443
2016/07/23 15:26:24 [error] 9#9: [lua] ssl_certificate.lua:238: ssl_certificate(): auto-ssl: could not get certificate for *** - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: 10.0.0.1, server: 0.0.0.0:443

The page shows bad certificate, but after reloading valid certificate is used.

I can't think of the secure way of avoiding exposing bad certificate, but would be nice if errors could be omitted.

==> /etc/openresty/nginx/logs/error.log <==
2016/08/07 02:31:26 [error] 194#0: [lua] start_sockproc.lua:9: auto-ssl: failed to start sockproc, context: init_worker_by_lua*

I get the aforementioned error after my Nginx instance starts.. Don't know what could be causing it..

It appears I may be missing a dependency is that CORRECT.

Here is the Docker image repo, with more information on how I have set things up.

Also, I noticed that sockproc is actually running.. See the images below.

cc/
@GUI
@agentzh

Hi,

certbot offers a functionality with which you can create a single certificate for multiple subdomains using a command like this:-

certbot-auto -d one.example.com -d two.example.com -d three.example.com -d example.org

Can we do the same with lua-resty-auto-ssl? Or does it create a different certificate for each of the sub-domains?

PS: It seems that dehydrated also offers a -d flag:-

--domain (-d) domain.tld Use specified domain name(s) instead of domains.txt entry (one certificate!)

Thanks,
Akshat

I've been working on a feature for our hosting setup that generates Let's Encrypt certificates using lua-resty-auto-ssl to force the renewal of a certificate (this would be useful in case of a security issue with Let's Encrypt, for example having to do with OpenSSL and forcing to renew all certs).

Here's what I have done so far:

• Deleted all Redis keys for the domain (domain..":latest")
• Deleted the "domain:fullchain_der:"..domain "domain:privkey_der:"..domain from the nginx cache
• Deleted cert.csr, cert.pem, chain.pem, fullchain.pem and privkey.pem from /etc/resty-auto-ssl/letsencrypt/certs/$domain

On the next request to the domain I do get new symlinks in /etc/resty-auto-ssl/letsencrypt/certs/$domain and the private keys changes, but the cert remains the same. It looks like Let's Encrypt is returning the same cert somehow, or did I miss something?

Is there a feature in lua-resty-auto-ssl that's calling dehydrated to force renewal that I missed, or is this something that would need to be implemented?

Thanks!

This looks similar to #4 but for the other directory created inside of /etc/resty-auto-ssl: .acme-challenges/, conf.d/ and config.sh are created by root

It would be nice if the modules did some checking at runtime.I just put together a docker image today with no experience with any of the components and so much time was lost round tripping to track down all the things that need to be right. People putting together an alpine distribution will generally not add openssl / curl / bash.

It would be beneficial to have docker files for a few variants available in the repo even if they aren't published publicly. I'm attaching some of the relevant bits below.

FROM openresty/openresty:1.9.15.1-alpine

RUN \
    apk add --no-cache --update --repository  http://dl-3.alpinelinux.org/alpine/edge/testing/ --virtual .build-deps \
        luarocks5.2 \
        make \
        gcc \
        libc-dev \
    && apk add openssl curl bash \
    && luarocks-5.2 install lua-resty-auto-ssl \
    && rm -rf ~/.cache \
    && apk del .build-deps \
    && mkdir /etc/resty-auto-ssl

ADD ./docker-entrypoint.sh ./docker-entrypoint.sh

ENTRYPOINT ./docker-entrypoint.sh

#!/bin/sh

cat << EOF > /sbin/start_nginx
  #!/bin/sh
  mkdir -p /var/log/nginx
  ln -sf /dev/stdout /var/log/nginx/access.log
  ln -sf /dev/stderr /var/log/nginx/error.log
  /usr/local/openresty/nginx/sbin/nginx -g "daemon off;" -c /etc/nginx/nginx.conf
EOF

chmod +x /sbin/start_nginx

start_nginx

Hello,

I managed to make auto run ssl with simple html, does anyone know how I can make it work with php and fpm?

Let's Encrypt imposes (quite reasonable) rate limits on the issuance of new certificates. Currently we request one certificate for each domain. This means that images.autossl.org and secure.autossl.org both get their own certificate. The number of certificates which can be issued like this is 25 per week - effectively limiting us to 25 subdomains.

The official way of dealing with this is combining the subdomains (up to 100) into one certificate. Dehydrated has support for this via a domains.txt-file. To implement this here, I'd suggest grouping domains by their main domain name (according to the public suffix list. Each group would get one domains.txt and config-file (with DOMAINS_TXT set). Dehydrated is then called with --config instead of --domain.

Combing the certificates gives us 100 subdomains instead of 25. If that is still too low, we could repeat this process for 25 subdomain-groups, giving us 2500 subdomains for each domain.

Would it be possible to use this solution with a single nginx hosting several domains that each require an SSL cert from Let's Encrypt?

Thanks! And the project looks awesome!

Everything seems to work correctly with certs, but in logs I get:

2016/07/24 09:43:00 [error] 10#10: connect() to [*]:80 failed (101: Network is unreachable), context: ssl_certificate_by_lua*, client: 10.0.0.1, server: 0.0.0.0:443
2016/07/24 09:43:00 [error] 10#10: [lua] ssl_certificate.lua:203: set_cert(): auto-ssl: failed to set ocsp stapling for * - continuing anyway - failed to get ocsp response: OCSP responder query failed: network is unreachable, context: ssl_certificate_by_lua*, client: 10.0.0.1, server: 0.0.0.0:443

We have an openresty 1.11.2.2 on Ubuntu 12.04 LTS and/or Ubuntu 14.04, and we're having issues with the service start/stop commands since we started using lua-resty-auto-ssl.

I have been able to narrow it down to a single line in the configuration file.
Once the line auto_ssl:init() in nginx.conf is commented out of nginx.conf, everything works. (i.e. all normal nginx/openresty functionality)

Once the line auto_ssl:init() is active, nginx can be started once using service nginx start or start nginx, but when a stop is attempted (service nginx stop or stop nginx)
nginx does stop, but the stop command never returns, and from that moment on, the start and stop commands do not work any more, until a reboot. No nginx processes are left running.

nginx can still be started by issuing the nginx command, and stopped using nginx -s stop...

openresty is self-compiled, lua-resty-auto-ssl 0.10.5 is installed using luarocks.

Do you have some pointers on this?

Hi,

I tried to use your solution on Ubuntu 12.04 but I had a problem with OpenSSL as 1.0.2e is not available in that distro release and building from source got me into more trouble. But if https://ma.ttias.be/day-google-chrome-disables-http2-nearly-everyone-may-31st-2016/ is still valid, then actually lua-resty-auto-ssl is useful only on Ubuntu 16.04, among the most popular "pro" distros. Is that right? Anyway: can you please lower the requirements for OpenSSL to, let's say, 1.0.1?

According to this code, I was expecting to see here the privkey-latest.pem and cert-latest.pemcert file, but they are not there.

I need to get the private key/cert to be also used in another service for token encryption.

Also why are there new private keys created for the same domain?

/ # ls -la /tmp/letsencrypt/certs/app.domain.com/
total 40
drwx------    2 nobody   nobody        4096 Jan  5 23:34 .
drwx------    3 nobody   nobody        4096 Jan  5 23:31 ..
-rw-------    1 nobody   nobody        1695 Jan  5 23:32 cert-1483659118.csr
-rw-------    1 nobody   nobody           0 Jan  5 23:32 cert-1483659118.pem
-rw-------    1 nobody   nobody        1695 Jan  5 23:32 cert-1483659135.csr
-rw-------    1 nobody   nobody           0 Jan  5 23:32 cert-1483659135.pem
-rw-------    1 nobody   nobody        1695 Jan  5 23:34 cert-1483659255.csr
-rw-------    1 nobody   nobody           0 Jan  5 23:34 cert-1483659255.pem
-rw-------    1 nobody   nobody        1695 Jan  5 23:34 cert-1483659261.csr
-rw-------    1 nobody   nobody           0 Jan  5 23:34 cert-1483659261.pem
-rw-------    1 nobody   nobody        3243 Jan  5 23:32 privkey-1483659118.pem
-rw-------    1 nobody   nobody        3247 Jan  5 23:32 privkey-1483659135.pem
-rw-------    1 nobody   nobody        3243 Jan  5 23:34 privkey-1483659255.pem
-rw-------    1 nobody   nobody        3243 Jan  5 23:34 privkey-1483659261.pem

Hi, if the config directory is on an NFS shared volume, can one still use files for storing config and certificates or will that not work?
Thanks!

We encountered a problem when issuing a new certificate failed, but the certificate was installed anyway.
Second issue is: why was it requesting a new certificate? The previous one was only 18 hours old.

2017/04/04 00:01:48 [error] 2398#0: *1352113 [lua] ssl_certificate.lua:88: issue_cert(): auto-ssl: issuing new certificate failed: dehydrated succeeded, but no certs present, context: ssl_certificate_by
_lua*, client: 67.205.xx.xxx, server: 0.0.0.0:443
2017/04/04 00:01:48 [error] 2398#0: *1352113 [lua] ssl_certificate.lua:247: auto-ssl: could not get certificate for www.mydomain.com  - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: 67.205.xx.xxx, server: 0.0.0.0:443

root@prof394:/etc/resty-auto-ssl/storage/file# ls -l
total 20
-rw-rw-rw- 1 www-data www-data 9571 Apr  3 05:56 www.mydomain.com%3A1491199011707
-rw-rw-rw- 1 www-data www-data   51 Apr  4 00:01 www.mydomain.com%3A1491264107999
-rw-rw-rw- 1 www-data www-data   51 Apr  4 00:01 www.mydomain.com%3Alatest
root@prof394:/etc/resty-auto-ssl/storage/file# more www.mydomain.com%3Alatest 
{"cert_pem":"","privkey_pem":"","fullchain_pem":""}

and (almost an hour after that) after that moment, thousands of
2017/04/04 00:57:12 [error] 2398#0: *1448383 [lua] ssl_certificate.lua:247: auto-ssl: could not get certificate for www.mydomain.com - using fallback - failed to convert certificate chain from PEM to DER: PEM_read_bio_X509_AUX() failed, context: ssl_certificate_by_lua*, client: 75.142.xx.xxx, server: 0.0.0.0:443

Hello,

I see this error now.

The certificate was obtained correctly a few minutes ago but the OCSP stapling isn't working.

2017/05/15 13:43:06 [error] 27#27: *12 [lua] ssl_certificate.lua:212: set_cert(): auto-ssl: failed to set ocsp stapling for pascal.domain.com - continuing anyway - failed to get ocsp response: failed to validate OCSP response (http://ocsp.int-x3.letsencrypt.org/): OCSP response not successful (6: unauthorized), context: ssl_certificate_by_lua*, client: 84.84.104.165, server: 0.0.0.0:443

I have some other sites running that are setup automatically all in the same way all working fine. This is actually the first time I encounter this type of error.

Hi,

I'm using auto-ssl for a while now, but I'm facing some issues regularly.

Once in a while this error comes up. Which results in a handshake error. Restarting the nginx-instances solved the problem. I'm using Redis as storage.

2017/02/23 07:45:01 [error] 25#0: *3177 lua entry thread aborted: runtime error: /usr/local/openresty/lualib/ngx/ocsp.lua:54: attempt to get length of local 'certs' (a nil value) stack traceback: coroutine 0: /usr/local/openresty/lualib/ngx/ocsp.lua: in function 'get_ocsp_responder_from_der_chain' .../luajit/share/lua/5.1/resty/auto-ssl/ssl_certificate.lua:123: in function 'get_ocsp_response' .../luajit/share/lua/5.1/resty/auto-ssl/ssl_certificate.lua:180: in function 'set_ocsp_stapling' .../luajit/share/lua/5.1/resty/auto-ssl/ssl_certificate.lua:210: in function 'set_cert' .../luajit/share/lua/5.1/resty/auto-ssl/ssl_certificate.lua:252: in function 'ssl_certificate' .../local/openresty/luajit/share/lua/5.1/resty/auto-ssl.lua:70: in function 'ssl_certificate' ssl_certificate_by_lua:2: in function <ssl_certificate_by_lua:1>, context: ssl_certificate_by_lua*, client: 10.42.205.225, server: 0.0.0.0:443 2017/02/23 07:45:01 [crit] 25#0: *3176 SSL_do_handshake() failed (SSL: error:1408A179:SSL routines:ssl3_get_client_hello:cert cb error) while SSL handshaking, client: 10.42.205.225, server: 0.0.0.0:443

What could be going wrong here?

Gino

In production, my Rails app has many many subdomains that each need their own TLS cert. This causes lua-resty-auto-ssl to be constantly rate-limited by Let's Encrypt. That's not a problem except that eventually (after several hours), lua-resty-auto-ssl causes nginx to stop routing requests to Passenger.

I've uploaded the OpenResty debug and access logs to https://kurttomlinson.com/files/nginx_logs_2017-4-49.zip. Ignore any certificate errors you get when you try to download it. I've turned TLS off for the time being.

When I open top after nginx has stopped routing requests to Passenger, I see a lot of processes like these:

# about ten of these:
curl --silent --show-errors --fail -XPOST --header X-Hook-Secret: ... --data-urlencode domain=...
# about eleven of these:
bash /opt/openresty/luajit/bin/resty-auto-ssl/dehydrated --cron --no-lock --domain ...
# and about four of these:
openssl genrsa -out /etc/resty-auto-ssl/letsencrypt/certs/.../privkey-....pem4096

It seems that these processes are getting started by lua-resty-auto-ssl, failing, and never getting killed.

Passenger version 5.1.2.
OpenResty version 1.11.2.2.
lua-resty-auto-ssl version 0.10.6-1.
lua-rest-http version 0.10-0.

As more and more Mail Clients also Support SNI when talking to the MailServer
i thought it would be nice to got the same for the Mail Part of Nginx/Reverse Proxy.

I got a test setup, and the https part works perfectly.

Simply doing this part in the Mail Section of the Config:

ssl_certificate_by_lua_block {
auto_ssl:ssl_certificate()
}

gives a
nginx: [emerg] "ssl_certificate_by_lua_block" directive is not allowed here in /usr/local/openresty/nginx/conf/nginx.conf:92
back.

is it in anyway possible to use the same mechanics to be able to present the mail client the right certificate?

Please update the documentation to mention that vanilla nginx will require patch and this lua package will not work without it.

https://raw.githubusercontent.com/openresty/openresty/dbccee1418ddb24a2adabd80b0737595b7fd577e/patches/nginx-1.11.2-ssl_cert_cb_yield.patch

We have this running behind a load balancer with 2 servers: A and B. If an unknown domain makes a request to server A and it's valid, our server makes a new cert request to lets encrypt.

The next step is for lets encrypt to make a request back to us to confirm we are who we say we are. If the load balancer chooses to send that request to server B, then the confirmation will fail as it doesnt know about the pending domains.

Has anyone tackled this problem before? Are the pending domains stored in memory? Would it be possible to store this state in redis so that both servers could know about pending domains?

2017/04/19 15:26:40 [error] 5547#0: *1155021 [lua] lets_encrypt.lua:32: issue_cert(): auto-ssl: dehydrated failed: env HOOK_SECRET=c2d5f64508a4c2edee0c4faf1c19f3f81908264232eb56b23d9602cd4bfaef36 HOOK_SERVER_PORT=8999 /usr/local/share/lua/5.1/resty/auto-ssl/vendor/dehydrated --cron --no-lock --domain www.imagecon.com --challenge http-01 --config /etc/resty-auto-ssl/letsencrypt/config --hook /usr/local/share/lua/5.1/resty/auto-ssl/shell/letsencrypt_hooks status: 256 out: # INFO: Using main config file /etc/resty-auto-ssl/letsencrypt/config
Processing www.imagecon.com

• Checking domain name(s) of existing cert... err: # !! WARNING !! Extra configuration directory /etc/resty-auto-ssl/letsencrypt/conf.d exists, but no configuration found in it.
  unable to load certificate
  140039407040152:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:701:Expecting: TRUSTED CERTIFICATE
  , context: ssl_certificate_by_lua*, client: 10.169.165.199, server: 0.0.0.0:443
  2017/04/19 15:26:40 [error] 5547#0: 1155021 [lua] ssl_certificate.lua:88: issue_cert(): auto-ssl: issuing new certificate failed: dehydrated failure, context: ssl_certificate_by_lua, client: 10.169.165.199, server: 0.0.0.0:443
  2017/04/19 15:26:40 [error] 5547#0: 1155021 [lua] ssl_certificate.lua:247: auto-ssl: could not get certificate for www.imagecon.com - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua, client: 10.169.165.199, server: 0.0.0.0:443

Hi,

I'm experimenting with auto-ssl, but found a few problems.
7/19/2016 10:07:00 AM2016/07/19 08:07:00 [notice] 11#0: [lua] ssl_certificate.lua:67: issue_cert(): auto-ssl: issuing new certificate for domain.com, context: ssl_certificate_by_lua*, client: 10.42.225.194, server: 0.0.0.0:443 7/19/2016 10:07:01 AM2016/07/19 08:07:01 [warn] 11#0: [lua] lets_encrypt.lua:37: issue_cert(): auto-ssl: letsencrypt.sh succeeded, but certs still missing from storage - trying to manually copy - domain: domain.com, context: ssl_certificate_by_lua*, client: 10.42.225.194, server: 0.0.0.0:443 7/19/2016 10:07:01 AM2016/07/19 08:07:01 [error] 11#0: [lua] lets_encrypt.lua:48: issue_cert(): auto-ssl: letsencrypt.sh manual hook.sh failed: env HOOK_SECRET=069a6df73827f25a7a090eda215c370fd926e2c3f2998a31a268247286167443 /usr/local/openresty/luajit/share/lua/5.1/resty/auto-ssl/shell/letsencrypt_hooks deploy_cert domain.com /etc/resty-auto-ssl/letsencrypt/certs/domain.com/privkey.pem /etc/resty-auto-ssl/letsencrypt/certs/domain.com/cert.pem /etc/resty-auto-ssl/letsencrypt/certs/domain.com/fullchain.pem status: 256 out: nil err: + HANDLER=deploy_cert 7/19/2016 10:07:01 AM+ shift 7/19/2016 10:07:01 AM+ deploy_cert domain.com /etc/resty-auto-ssl/letsencrypt/certs/domain.com/privkey.pem /etc/resty-auto-ssl/letsencrypt/certs/domain.com/cert.pem /etc/resty-auto-ssl/letsencrypt/certs/domain.com/fullchain.pem 7/19/2016 10:07:01 AM/usr/local/openresty/luajit/share/lua/5.1/resty/auto-ssl/shell/letsencrypt_hooks: line 35: 5: unbound variable 7/19/2016 10:07:01 AM, context: ssl_certificate_by_lua*, client: 10.42.225.194, server: 0.0.0.0:443 7/19/2016 10:07:01 AM2016/07/19 08:07:01 [error] 11#0: [lua] ssl_certificate.lua:70: issue_cert(): auto-ssl: issuing new certificate failed: letsencrypt.sh failure, context: ssl_certificate_by_lua*, client: 10.42.225.194, server: 0.0.0.0:443 7/19/2016 10:07:01 AM2016/07/19 08:07:01 [error] 11#0: [lua] ssl_certificate.lua:238: ssl_certificate(): auto-ssl: could not get certificate for domain.com - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: 10.42.225.194, server: 0.0.0.0:443 7/19/2016 10:07:01 AM2016/07/19 08:07:01 [info] 11#0: *63 SSL_do_handshake() failed (SSL: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:SSL alert number 48) while SSL handshaking, client: 10.42.225.194, server: 0.0.0.0:443 7/19/2016 10:07:01 AM2016/07/19 08:07:01 [crit] 11#0: *63 SSL_shutdown() failed (SSL: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init) while SSL handshaking, client: 10.42.225.194, server: 0.0.0.0:443

Because it is using its fallback cert I get an Privacy Error.

Two things got my attention: the letsencrypt_hooks: line 35: 5: unbound variable and letsencrypt.sh succeeded, but certs still missing from storage.

I'm using a Redis-storageadapter between multiple servers.

What could I be doing wrong?

Considering LetsEncrypt doesn't issue certs on IPs, it would be great to detect and ignore IP addresses before sending a request to LetsEncrypt, rather than having to add that logic into the allow_domain configuration/function.

Sometimes I see errors in my logs with a failed domain signing request
"detail": "Error creating new authz :: Issuance for IP addresses not supported"

Could you make a check on the beginning of the sequence to check wether it's a domain or IP, and cancel the sequence when it is a IP-address? Just to beautify the logs.

Hi,
i am currently using lua-resty-auto-ssl, it´s working like a charm, thank you.
I just noticed, that it´s generating 4096bits keys and i would like it to be 2048 keys (in opnenssl.cnf i have 2048 as default). I´ve looked through config files, but I haven´t found where should i set this.
Can you help me ?
Thanks

To be clear, this is a question rather than an issue. I apologise in advance if this is the incorrect place to ask questions regarding this plugin.

I was reading over the rate limit documentation at Let's Encrypt and noticed this.

If you have a lot of subdomains, you may want to combine them into a single certificate, up to a limit of 100 Names per Certificate. Combined with the above limit, that means you can issue certificates containing up to 2,000 unique subdomains per week. A certificate with multiple names is often called a SAN certificate, or sometimes a UCC certificate.

Does this plug in support this?

My goal to achieve is to have lots of subdomains pointed at a single server running nginx and this plugin.

Thank you for your time.

Hi, those messages pops up in logs every few minutes. Do you have any idea why do_ssl gets interupted?

Visitors receive fallback certificate while the error occurs. (That is invalid.)

[lua] ssl_certificate.lua:265: ssl_certificate(): auto-ssl: failed to run do_ssl: init_by_lua:10: Interrupted system call, context: ssl_certificate_by_lua*, client: 10.135.30.111, server: 0.0.0.0:443

We run on Fedora 24 with Openresty installed from package. This issue occures on two of our servers for SSL termination.

We will appreciated any help. Thanks

Link to a test https://www.ssllabs.com/ssltest/

2016/11/27 08:50:53 [error] 11971#0: *11515 lua entry thread aborted: runtime error: /usr/share/lua/5.1/resty/auto-ssl.lua:69: loop or previous error loading module 'resty.auto-ssl.ssl_certificate'
stack traceback:
coroutine 0:
        [C]: in function 'require'
        /usr/share/lua/5.1/resty/auto-ssl.lua:69: in function 'ssl_certificate'
        ssl_certificate_by_lua:2: in function <ssl_certificate_by_lua:1>, context: ssl_certificate_by_lua*, client: ****, server: 0.0.0.0:443
2016/11/27 08:50:53 [crit] 11971#0: *11514 SSL_do_handshake() failed (SSL: error:1408A179:SSL routines:ssl3_get_client_hello:cert cb error) while SSL handshaking, client: ****, server: 0.0.0.0:443
2016/11/27 08:50:55 [error] 11973#0: *11523 lua entry thread aborted: runtime error: /usr/share/lua/5.1/resty/auto-ssl.lua:69: loop or previous error loading module 'resty.auto-ssl.ssl_certificate'
stack traceback:
coroutine 0:
        [C]: in function 'require'
        /usr/share/lua/5.1/resty/auto-ssl.lua:69: in function 'ssl_certificate'
        ssl_certificate_by_lua:2: in function <ssl_certificate_by_lua:1>, context: ssl_certificate_by_lua*, client: ****, server: 0.0.0.0:443
2016/11/27 08:50:55 [crit] 11973#0: *11522 SSL_do_handshake() failed (SSL: error:1408A179:SSL routines:ssl3_get_client_hello:cert cb error) while SSL handshaking, client: ****, server: 0.0.0.0:443

I also tried with testssl.sh but it produces different result every time.

I've just gotten this error on our production server:

2017/04/07 19:05:21 [error] 595#595: *227 [lua] ssl_certificate.lua:212: set_cert(): auto-ssl: failed to set ocsp stapling for xxxxx.com - continuing anyway - failed to get ocsp response: failed to validate OCSP response (http://ocsp.int-x3.letsencrypt.org/): OCSP response not successful (6: unauthorized), context: ssl_certificate_by_lua*, client: x.x.x.x, server: 0.0.0.0:443\n

Have you seen this before? I'm on version 0.10.3-1

Sorry for a potentially dumb question, I've got no experience with Lua.

But is it possible to reuse the Redis connection within the allow_domain method for looking up permissable domains from a set stored there?

We've played with a couple of different options, but would really like to keep a whitelist of domains in a DB somewhere it refers to and since there's already Redis support baked in, we may as well use it.

Currently the hook-port is hard coded to be 8999. Lua-resty-auto-ssl should implement changing this port to another value (e.g. to a lower port only root can bind to), while defaulting to 8999 so we don't break existing installations.

TODO:

• add a new parameter named hook_server_port
  • check that the new parameter contains a number below 65536
  • make it default to 8999
• respect value in letsencrypt_hooks#L20
• respect value in letsencrypt_hooks#L31
• write tests
  • change the port, plus invalid values
  • default to 8999
• document new parameter in README

What do you think about this?

Hi,

I think this might be due to letsencrypt.sh limitations and/or Let's Encrypt themselves, but: If I open example.com in one tab, and open www.example.com in another tab while it's creating the certificate/key pair for example.com, www.example.com simply returns the fallback cert. Refreshing after example.com's creation is done, makes it create and return the cert for www.example.com just fine.

Daniël

I'm running this from a docker centos 7 image. It somehow stucks on lets_encrypt.lua

status, out, err = shell_execute(command)

env HOOK_SECRET=2f9506c7a8adca5e3ec26ee5088124e297868bf2e5811b1a6fce97df216a4e91 HOOK_SERVER_PORT=8999 /usr/local/openresty/luajit/share/lua/5.1/resty/auto-ssl/shell/letsencrypt_hooks deploy_cert test55.XXX.com /tmp/letsencrypt/certs/test55.XXX.com/privkey.pem /tmp/letsencrypt/certs/test55.XXX.com/cert.pem /tmp/letsencrypt/certs/test55.XXX.com/fullchain.pem /tmp/letsencrypt/certs/test55.XXX.com/chain.pem 1489127206

I have tried to execute the command variable manually on bash. It runs all okey.

I also have tried to execute status, out, err = shell_execute('ls -lah') to see if things are working correctly. It does execute from lua no problem.

Error log
2017/03/10 06:54:46 [warn] 78012#78012: 371 [lua] lets_encrypt.lua:52: issue_cert(): auto-ssl: dehydrated succeeded, but certs still missing from storage - trying to manually copy - domain: test66.xxx.com, context: ssl_certificate_by_lua, client: , server: 0.0.0.0:443

2017/03/10 06:54:40 [error] 78012#78012: 363 [lua] ssl_certificate.lua:247: auto-ssl: could not get certificate for - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua, client: , server: 0.0.0.0:443

Any ideas guys? I'm running everything as the latest.

How do I specify multiple cluster nodes to connect to for the Redis config?

The instructions on the readme say create /etc/resty-auto-ssl/ and chown it to the nginx user, but the files that auto_ssl:init() creates are owned by root, not the user directive in the config file -- this means I get this error:

2016/04/03 18:43:00 [error] 16#16: [lua] ssl_certificate.lua:55: issue_cert(): auto-ssl: failed to obtain lock: /etc/resty-auto-ssl/storage/file/test.ignoreme.com%3Aissue_cert_lock:
 Permission denied, context: ssl_certificate_by_lua*, client: 127.0.0.1, server: 0.0.0.0:443```

The License Agreement changed on August 1st.
The version of the script installed with the module through Luarocks is outdated now and blocks registration.

When the domain is badly configured and run into 'Invalid' response from LE, I get this error:

resty/auto-ssl/shell/letsencrypt_hooks: line 54: invalid_challenge: command not found

+ Responding to challenge for machelp.pro...
err: # !! WARNING !! Extra configuration directory /etc/resty-auto-ssl/letsencrypt/conf.d exists, but no configuration found in it.`
+ HANDLER=deploy_challenge
+ shift
+ deploy_challenge machelp.pro xxxxxxx
+ local DOMAIN=machelp.pro TOKEN_FILENAME=x TOKEN_VALUE=x
+ curl --silent --show-error --fail -XPOST --header 'X-Hook-Secret: xx' --data-urlencode domain=machelp.pro --data-urlencode token_filename=xx --data-urlencode token_value=xx
xx-xx http://127.0.0.1:8999/deploy-challenge
+ HANDLER=clean_challenge
+ shift
+ clean_challenge machelp.pro xxx xxx
+ local DOMAIN=machelp.pro TOKEN_FILENAME=xxx TOKEN_VALUE=xxx
+ curl --silent --show-error --fail -XPOST --header 'X-Hook-Secret: xxxx' --data-urlencode domain=machelp.pro --data-urlencode token_filename=xxx --data-urlencode token_value=xxx
xxx http://127.0.0.1:8999/clean-challenge
+ HANDLER=invalid_challenge
+ shift
+ invalid_challenge machelp.pro '{' '"type":' '"http-01",' '"status":' '"invalid",' '"error":' '{' '"type":' '"urn:acme:error:unauthorized",' '"detail":' '"Invalid' response from http://machelp.pro/.well-known/acme-challenge/eZd6Mj9eOgblkYE6XTwyBWYxNwnXHlhFz71b4SdLyRM: '\"\u003chtml\u003e\r\n\u003chead\u003e\u003ctitle\u003e404' Not 'Found\u003c/title\u003e\u003c/head\u003e\r\n\u003cbody' 'bgcolor=\"white\"\u003e\r\n\u003ccenter\u003e\u003ch1\u003e404' Not 'Found\u003c/h1\u003e\u003c/center\u003e\r\n\u003chr\u003e\u003ccenter\u003e\"",' '"status":' 403 '},' '"uri":' '"https://acme-v01.api.letsencrypt.org/acme/challenge/xxx/738875868",' '"token":' '"xxx",' '"keyAuthorization":' '"xxx",' '"validationRecord":' '[' '{' '"url":' '"http://machelp.pro/.well-known/acme-challenge/eZd6Mj9eOgblkYE6XTwyBWYxNwnXHlhFz71b4SdLyRM",' '"hostname":' '"machelp.pro",' '"port":' '"80",' '"addressesResolved":' '[' '"87.236.19.141"' '],' '"addressUsed":' '"87.236.19.141"' '}' ']' '}'
/usr/local/openresty/lualib/resty/auto-ssl/shell/letsencrypt_hooks: line 54: invalid_challenge: command not found
, context: ngx.timer
2017/03/04 05:24:24 [error] 2683#2683: *21617367 [lua] renewal.lua:112: renew_check_cert(): auto-ssl: issuing renewal certificate failed: nil, context: ngx.timer

Hi,

In the list of requirements, the "curl" commandline-tool is missing.
When you try to do the "luarocks install lua-resty-auto-ssl" on a minimalistic container, it fails on that not being available.

Daniël

I've been encountering a problem with our (reverse proxy) nginx servers that they have been crashing. They stop responding to requests completely, and don't seem to come out of this state by themselves. These servers deal with a highish volume of requests (>5million a day).

For the past few days I've been at a bit of a loss, and restarting the Docker instance manually whenever I was alerted to this by monitoring, but I decided to put a helper cron script in place that would check if nginx was still responding and restart it via supervisord if there was an issue.

Due to the fact initially I was restarting the Docker container, I wasn't really getting any form of debugging information -- the logging would just stop. However after changing this to instead restart nginx inside the container I have the following in the logs:

2017/02/01 01:14:16 [alert] 489#0: worker process 501 exited on signal 9
2017/02/01 01:14:16 [alert] 489#0: shared memory zone "auto_ssl" was locked by 501
2017/02/01 01:14:16 [alert] 489#0: worker process 502 exited on signal 9

I had around on Google and the only reference I can find is 18F/api.data.gov#325 -- however it looks like expirations were put into place, this doesn't seem to be working on our setup, as we (due to bad monitoring) ended up with about a 7 hour downtime recently.

I should mention I cannot recreate this bug at all locally, even using the same Docker container.

I'm at a bit of a loss, our automatic restart script has sorted out the issues for now but it would be nice to see if anyone has ideas. I'd be happy to turn on extra logging and attempting the debug log (I've been a bit scared to turn it on in our production servers).

According to the LuaRocks page, its use is now discouraged:

http://openresty.org/en/using-luarocks.html

Would you be interested in releasing an OPM package also? :)

In environments with very frequent config changes (like mine! 😁), nginx can sometimes be reloaded while resty-auto-ssl is requesting a certificate. This causes errors and ultimately fails the certificate request.

1. request a new certificate
2. spawns dehydrated with AUTO_SSL_HOOK_SECRET
3. nginx is reloaded (which means the secret changes!)
4. dehydrated gets around to curling our API, supplying the secret provided earlier.
5. the curl fails with status 403 Forbidden and dehydrated gives up.

This is particularly bad, because we never output any status, as to why the request was denied.

Now, how do we solve this?
Currently the secret is generated every reload or restart, even if one is already present. I suggest that we first check if a secret is present. If there is one, just leave it. If there is none, generate one.

Is there any reason we currently regenerate the secret every reload?

I'm wondering if there's a way to provide the email address that Let's Encrypt requires for registering domains?

First thanks for the great work in building this 👍

It would be great if auto-ssl would check that the DNS would resolve to a certain set of IPs before issuing a request to LetsEncrypt.

For example a new auto_ssl:set function could return that list of IPs, and if DNS resolves to any of those the certificate request goes ahead.

In some cases the request size of hook POST requests can exceed the default client_body_buffer_size (16k). This causes nginx to buffer the request in a file, instead of in memory. Since lua-nginx does not support temp files (yet?) the hooks fail.

A quick fix is increasing the client_body_buffer_size as well as client_max_body_size.

Following install process get this error on start:

init_by_lua error: /usr/local/share/lua/5.1/resty/auto-ssl/init.lua:1: module 'resty.random' not found:
        no field package.preload['resty.random']
        no file './resty/random.lua'
        no file '/usr/share/luajit-2.0.4/resty/random.lua'
        no file '/usr/local/share/lua/5.1/resty/random.lua'
        no file '/usr/local/share/lua/5.1/resty/random/init.lua'
        no file '/usr/share/lua/5.1/resty/random.lua'
        no file '/usr/share/lua/5.1/resty/random/init.lua'
        no file './resty/random.so'
        no file '/usr/local/lib/lua/5.1/resty/random.so'
        no file '/usr/lib/arm-linux-gnueabihf/lua/5.1/resty/random.so'
        no file '/usr/local/lib/lua/5.1/loadall.so'
        no file './resty.so'
        no file '/usr/local/lib/lua/5.1/resty.so'
        no file '/usr/lib/arm-linux-gnueabihf/lua/5.1/resty.so'
        no file '/usr/local/lib/lua/5.1/loadall.so'
stack traceback:
        [C]: in function 'require'
        /usr/local/share/lua/5.1/resty/auto-ssl/init.lua:1: in main chunk
        [C]: in function 'require'
        /usr/local/share/lua/5.1/resty/auto-ssl.lua:59: in function 'init'
        init_by_lua:11: in main chunk