This post explains why it is more secure to issue TLS certificates from an orchestration server, as opposed to from each server. We'll discuss the chosen challenge, frequency, diversity, and key strength.
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
Uxtely 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 Uxtely 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 lets you limit the token to a specific zone (domain name) and from certain IP address. On the other hand, it doesn't let you limit the privileges to "Only edit TXT records", but other providers might, as suggested by Joona Hoikkala in his article.
Restrict which Certificate Authority is Authorized to issue certificates by adding a DNS CAA record. For example:
CAA @ letsencrypt.org
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: sst -t your_live_server service nginx reload