private key is leaked in error logs

[luto]

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.

[GUI]

Sorry for the delay in response, but thanks for reporting this. This would definitely be good to cleanup. I'll take a look to see if we can eliminate this from the logging.

It may just be as simple as eliminating the set -x from our hook script, but I haven't verified that yet, and I'd still like to ensure we get some useful debug output if things fail.

[GUI]

This should actually no longer be an issue in v0.10.5+ due to this pull request which changed how we sent the certificates via curl: #53 After that change, it had the side effect of changing the debug output so that it would only contain the path to the files, rather than the file content. So in these newer versions, the debug output would look more like:

2017/06/18 23:35:56 [error] 1756#0: *15 [lua] lets_encrypt.lua:70: issue_cert(): auto-ssl: dehydrated manual hook.sh failed: env HOOK_SECRET=zz HOOK_SERVER_PORT=8999 /test/run/build/luajit/bin/resty-auto-ssl/letsencrypt_hooks deploy_cert 7214ed43.ngrok.io /tmp/resty-auto-ssl-test/letsencrypt/certs/7214ed43.ngrok.io/privkey.pem /tmp/resty-auto-ssl-test/letsencrypt/certs/7214ed43.ngrok.io/cert.pem /tmp/resty-auto-ssl-test/letsencrypt/certs/7214ed43.ngrok.io/fullchain.pem /tmp/resty-auto-ssl-test/letsencrypt/certs/7214ed43.ngrok.io/chain.pem 1497828956 status: 256 out: nil err: + HANDLER=deploy_cert
+ shift
+ deploy_cert 7214ed43.ngrok.io /tmp/resty-auto-ssl-test/letsencrypt/certs/7214ed43.ngrok.io/privkey.pem /tmp/resty-auto-ssl-test/letsencrypt/certs/7214ed43.ngrok.io/cert.pem /tmp/resty-auto-ssl-test/letsencrypt/certs/7214ed43.ngrok.io/fullchain.pem /tmp/resty-auto-ssl-test/letsencrypt/certs/7214ed43.ngrok.io/chain.pem 1497828956
+ local DOMAIN=7214ed43.ngrok.io KEYFILE=/tmp/resty-auto-ssl-test/letsencrypt/certs/7214ed43.ngrok.io/privkey.pem CERTFILE=/tmp/resty-auto-ssl-test/letsencrypt/certs/7214ed43.ngrok.io/cert.pem FULLCHAINFILE=/tmp/resty-auto-ssl-test/letsencrypt/certs/7214ed43.ngrok.io/fullchain.pem CHAINFILE=/tmp/resty-auto-ssl-test/letsencrypt/certs/7214ed43.ngrok.io/chain.pem TIMESTAMP=1497828956
+ curl --silent --show-error --fail -XPOST --header 'X-Hook-Secret: zz' --data-urlencode domain=7214ed43.ngrok.io --data-urlencode privkey@/tmp/resty-auto-ssl-test/letsencrypt/certs/7214ed43.ngrok.io/privkey.pem --data-urlencode cert@/tmp/resty-auto-ssl-test/letsencrypt/certs/7214ed43.ngrok.io/cert.pem --data-urlencode fullchain@/tmp/resty-auto-ssl-test/letsencrypt/certs/7214ed43.ngrok.io/fullchain.pem http://127.0.0.1:8999/deploy-cert

Still, though, that output caused by set -x is probably overly chatty, so I've updated things to remove this debug output: d59e14b It will be part of the v0.11.0 release.

In terms of previous exposure in log files, this certainly isn't ideal, although the only thing I'll note is that hopefully the situation where this got logged should be pretty rare (it would require the certificate to not be in storage, and then the manual call to the hook shell script would need to fail).

Thanks for reporting this!

[luto]

Thanks :)