rolisoft/letsencrypt-cloudflare-hook

Hook script for LetsEncrypt.sh to allow automatic manipulation of CloudFlare DNS records for the dns-01 verification.

letsencrypt-cloudflare-hook's Issues

Permissions

This is a great script. Much easier to understand that the python hook for Cloudflare and letsencrypt.sh. So thank you!

How do you run deploy.sh in such a manner that the certs for example.org can be placed in /etc/ssl/private/example.org/ with ownership being root:ssl-cert and the permissions for the example.org directory being 755 (world-readable/executable) and the permissions of file that privkey.pem links to being 640 and the permissions of the files that cert.pem, chain.pem, and fullchain.pem link to being 644. (All the symbolic links themselves should be 777.)

Would you do this by shifting $BASEDIR or by executing mv commands in deploy.sh? If the latter, how would you make it run with sudo privileges so as to move files to /etc/ssl/?

Here is a good link on permissions: certbot/certbot#1473 (comment)

hook.sh should check dig installed on host and fail gracefully

The deploy_challenge routine used dig to check for successful TXT record propagation. When I first bundled hook.sh into a Docker image for cron deployment, dig was not installed. I had to install the dnsutils package.

It might be better to have deploy_challenge check that dig exists and fail with an explicit message before invoking dig.

I don't remember how the script fails now without dig, but I don't remember it failing gracefully...

Hook Needed for Unchanged Cert

While this doesn't affect the functionality, for sake of completeness, it would be good to include code for the "unchanged_cert" response, since currently one gets:

/etc/letsencrypt.sh/hook.sh: line 192: unchanged_cert: command not found

Parameter mismatch in deploy.sh.example

deploy.sh.example checks for 4 parameters being passed to it. However, hook.sh, thanks to 11c5790 , now passes 5 parameters, not 4.

Also, in letsencrypt.sh, there's an additional parameter, TIMESTAMP, that may be passed, taking the total to 6.

Propagation check should ensure answer is for TXT record

My domain has a wildcard CNAME so when the hook script checks for propagation of the _acme-challenge TXT record, a CNAME answer is returned if the TXT record has not propagated yet.

Before propagation has occurred, the answer is the CNAME record:

dig txt +trace +noall +answer _acme-challenge.nl.walri.com
.           10480   IN  NS  a.root-servers.net.
.           10480   IN  NS  b.root-servers.net.
.           10480   IN  NS  c.root-servers.net.
.           10480   IN  NS  d.root-servers.net.
.           10480   IN  NS  e.root-servers.net.
.           10480   IN  NS  f.root-servers.net.
.           10480   IN  NS  g.root-servers.net.
.           10480   IN  NS  h.root-servers.net.
.           10480   IN  NS  i.root-servers.net.
.           10480   IN  NS  j.root-servers.net.
.           10480   IN  NS  k.root-servers.net.
.           10480   IN  NS  l.root-servers.net.
.           10480   IN  NS  m.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 30 ms

;; Received 506 bytes from 202.12.27.33#53(202.12.27.33) in 186 ms

;; Received 186 bytes from 192.33.14.30#53(192.33.14.30) in 384 ms

_acme-challenge.nl.walri.com. 300 IN    CNAME   walri.com.
;; Received 212 bytes from 173.245.58.113#53(173.245.58.113) in 16 ms

After propagation, the answer is the TXT record:

dig txt +trace +noall +answer _acme-challenge.nl.walri.com
.           10270   IN  NS  a.root-servers.net.
.           10270   IN  NS  b.root-servers.net.
.           10270   IN  NS  c.root-servers.net.
.           10270   IN  NS  d.root-servers.net.
.           10270   IN  NS  e.root-servers.net.
.           10270   IN  NS  f.root-servers.net.
.           10270   IN  NS  g.root-servers.net.
.           10270   IN  NS  h.root-servers.net.
.           10270   IN  NS  i.root-servers.net.
.           10270   IN  NS  j.root-servers.net.
.           10270   IN  NS  k.root-servers.net.
.           10270   IN  NS  l.root-servers.net.
.           10270   IN  NS  m.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 31 ms

;; Received 502 bytes from 2001:500:9f::42#53(2001:500:9f::42) in 16 ms

;; Received 186 bytes from 192.26.92.30#53(192.26.92.30) in 197 ms

_acme-challenge.nl.walri.com. 300 IN    TXT "ND5I8VmIN_UhAtqg9CP8d5Z05qjHn3M0gbTu6_GNKS8"
;; Received 102 bytes from 2400:cb00:2049:1::adf5:3b70#53(2400:cb00:2049:1::adf5:3b70) in 88 ms

LetsEncrypt-CloudFlare-Hook silently fails

Hey,

using the latest letsencrypt.sh (cloned on commit 6192b33), this hook silently fails after + Requesting challenge for example.com... The letsencrypt.sh just terminates and nothing happens. I have done chmod +x on the hook, have exported my credentials to letsencrypt.sh's config (unsetting them does make it complain about missing credentials) and set it to use dns-01.

Any idea?

DNS propagation for domain with 69 subdomains

I'm experiencing a problem generating the certs for a domain with 69 subdomains. The CloudFlare hook sets the TXT record for each name challenge and waits for the DNS to propagate from the point of view of my server. When the letsencrypt.sh script tries to check the challenge, it occasionally fails and the script errors out. I have been unable to get all the way through the challenges to generate the certs and I now have hit some sort of limit on the number of pending challenges that I may have (so I guess I will have to wait a week to see if those failed challenges are removed and I can try again).

Looking at the letsencrypt.sh script, there is an option to bundle all the challenges into one call to hook.sh using the HOOK_CHAIN variable.

I think hook.sh should support the HOOK_CHAIN="yes" option to make the CF TXT records all at once, wait for them to propagate (checking that all the TXT records have propagated after all TXT records have been deployed) and then support an option to wait a couple more minutes before returning to letsencrypt.sh (increasing the chance that the LE servers are seeing the TXT records from their resolver).

This would greatly decrease the time it currently takes to wait on 70 TXT records to propagate since now, the hook.sh applies the records one at a time and waits on each record to propagate before proceeding to the next one. And, maybe avoid the problem of intermittent failure.