1

I'm hoping to use Let's Encrypt for several domains and subdomains and my company. In lieu of buying a long lasting wild card cert that is installed on every machine, the goal is to use short lived and specific certs. This is to prevent our exposure if one machine gets compromised.

Unfortunately, some servers can't have any service interruption (aka. no ability of HTTP acme challenge). So the final option is DNS challenge. This requires an API token for our DNS provider, in this case, Cloudflare.

However, if I put the Global API Token on the machine and it gets compromised, this gives the attacker full access to our DNS for that whole domain. This is exactly what I want to mitigate by not using a wildcard cert.

Cloudflare let's you create less privileged tokens however they don't get more granular than per root level domain. Again, essentially same access/concern as wildcard cert.

Has anyone come up with a solution to this issue?

d1str0
  • 111
  • 5
  • If you are already using Cloudflare for DNS, is there any reason it can’t also be used for SSL? You can get a Cloudflare issued “internal” SSL certificate for your own servers, to ensure encryption across all connections. – David Jan 22 '20 at 22:44
  • You have to enable CF proxy which disrupts lots of stuff. We don't want to use the proxy for all of our services. – d1str0 Jan 23 '20 at 23:08

3 Answers3

2

The approach that I have taken in the past for this requirement, and which I believe is blessed by Let's Encrypt's documentation, is to CNAME the _acme-challenge subdomain for the name(s) you wish to validate to names in one or more other zones, which have different access control configurations.

As an example, if you wished to allow some service to generate certificates only for bobservice.example.com, you could create a separate zone for some other domain, say bobservice.example, and then CNAME _acme-challenge.bobservice.com to _acme-challenge.bobservice.example. The challenge token then gets placed in a TXT record on _acme-challenge.bobservice.example, LE follows the CNAME, and the name is validated.

Of course, the other option is to switch away from using Cloudflare entirely, because their service lacks useful features like limited scope credentials, and also the teeny tiny issue that they provide services to the scum of the Internet.

womble
  • 96,255
  • 29
  • 175
  • 230
1

Unfortunately, some servers can't have any service interruption (aka. no ability of HTTP acme challenge). So the final option is DNS challenge.

There's another option for your sort of scenario, the webroot plugin. This allows you to tell the Let's Encrypt client the path to your server's web root, and it'll put the HTTP challenge files there. This approach doesn't mess with your webserver at all, and incurs no downtime.

ceejayoz
  • 32,910
  • 7
  • 82
  • 106
  • This is a great option, however the specific service I'm thinking of might be proprietary or otherwise uneditable. So this might not work either. – d1str0 Jan 21 '20 at 22:00
0

My solution is to build a service that lives on the internal network, is quite locked down, and holds the Global API key. This service will use this key to create/renew certificates for various subdomains. Servers that rely on the subdomain certs will have a per-domain token they can issue against this internal service to retrieve a new or renewed certificate.

d1str0
  • 111
  • 5