This post explains why UI Drafter issues its TLS certificates from an orchestration server, as opposed to from each server. Also, the chosen frequency, diversity, and key strengths.
are preferred because they require fewer privileges than HTTP ones.
For instance, they only need to create TXT records that start
_acme-challenge subdomain. For example:
_acme-challenge.example.com. 120 IN TXT "rAnd0mK" _acme-challenge.foo.example.com. 120 IN TXT "43aZ09i"
On the other hand, HTTP challenges need:
- a program on a live server,
- write permissions on a servable directory, and
'pass out' firewall exceptions without IP scope.
We don’t publish a list of IP addresses we use to validate… Let's Encrypt
UI Drafter renews certificates at least once a month per server.
Let's Encrypt certificates last for 90 days, and can be renewed up to 5 times a week. Josh Aas, from the Internet Security Research Group (ISRG), recommends renewing them every 60 days in his 2015 post:
We recommend that subscribers renew every sixty days. Once automated renewal tools are widely deployed and working well, we may consider even shorter lifetimes.
Each server has a different certificate. As UI Drafter doesn't need stateful load balancing, this way mitigates the decryption of all the traffic of a particular user on a given period. In other words, an adversary hoarding encrypted traffic has to break more certificates.
Although this guide uses Cloudflare®, that list shows how to adapt other providers. If your provider is not on that list, or if its API isn't compatible with your security polices, you could use a different domain than the one the certificate is going to be issued for. For that, see challenging with an alias.
Create a custom API Token with these permissions:
Zone | Zone | Read Zone | DNS | Edit
Cloudflare doesn't let you limit the privileges to "Only edit TXT records", neither allow-listing subdomains. But other providers might, as suggested by Joona Hoikkala in his article.
Issuing a certificate
export CF_Token=TheToken export CF_Account_ID=TheAccountId ./acme.sh --issue --dns dns_cf -k ec-256 --force \ -d example.com \ -d foo.example.com
ec-256 is stronger than the default key
(RSA 2048 bits). Check out the compatibility
--force for being able to renew the certificate
before the next renewal time (60
days by default).
The previous command creates the certificate and key in a directory
next to where the
acme.sh script is.
DIR=~/.acme.sh/example.com_ecc rsync $DIR/fullchain.cer your_live_server: rsync $DIR/example.com.key your_live_server: