5 ms·

Unfortunately CloudFlare doesn’t provide limited-scope API keys so every server requesting certs needs your global API key which is the keys-to-the-kingdom...so

• josteink 8y ago
  I actually have the reverse model: requesting certs is done by its own isolated and dedicated container and scp’d to the server which needs it. Compromising a web-server will thus not compromise my DNS.
  • xref 8y ago
    I like the sound of this idea, happen to have a Dockerfile/scripts for it on GitHub?
    • josteink 8y ago
      Nope. I’m using LXC and have set things up manually. It’s just a basic setup with dehydrated[1], some bash scripts for deployment and cron though. [1] https://github.com/lukas2511/dehydrated https://github.com/lukas2511/dehydrated
• regecks 8y ago
  You can also CNAME your _acme-challenge record to another zone and perform the updates on the target zone, avoiding overprivileging your webserver. https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns is a server implementation of that, and a number of popular clients support it. Or if you don't want to run acme-dns, some ACME clients support an "alias" mode that essentially does the same thing using generic DNS CNAMEing. Annoyed that Route53 IAM still doesn't let you limit the record label ...
• dspillett 8y ago
  No need for individual servers, let alone public ones, to have your DNS API key. Have a separate machine that isn't publicly addressable generate the keys and request the certificates, and then push them out to where they need to be. You don't even need to give that box privileged access to the places the certificates need to be, if you arrange things right. Only one box then needs your API key.
  • tialaramex 8y ago
    That separate machine doesn't need the private keys. Depending on your scenario it may well make more sense for the DNS privileged machine not to know the keys, and be given Certificate Signing Requests (CSRs) for the certificates it's to go get from Let's Encrypt. Most good ACME clients will accept a CSR you provide as an alternative to making their own keys or using a private key you generated. A CSR is a signed document like a certificate, but instead of being signed by a CA (Let's Encrypt) to certify something, they're signed by "you" (ie using your private key) to prove you know the key and you want a certificate with these names on it. Under the hood the ACME protocol always uses CSRs, but since tools to make them are often clumsy and nasty clients tend to follow Certbot (the reference client) in defaulting to making their own CSR without you needing to know about it, a client can do this because it knows your private keys. By providing your own CSRs you don't need the box speaking ACME to know your private keys. Let's Encrypt doesn't care if you provide the same CSR repeatedly for renewals, unless your private key is known to them because somebody leaked it, in which case subsequent requests for a certificate will fail, which is what you want since that key is now compromised and you need to replace it. You should rotate keys anyway, but can do so at a pace which is appropriate to your risk factors e.g. once a year is fine for most people, and not dictated by the rate at which Let's Encrypt renewals happen.
    • dspillett 8y ago
      Aye, though I didn't want to complicate the "everything needs my API key" correction with discussion of providing CSRs separately. That and I've not played with doing that myself yet, so while I know it is possible I can't talk about it authoritatively.