For internal-use certificates, you'll have to make use of a DNS challenge with Let's Encrypt. I've been hesitant to set that up because I'm concerned about the potential compromise of a token that has permissions to edit my DNS zone. I see that the author creates exactly that kind of token and has permanently accessible to his script. For a home lab where he's the only person accessing his hardware, that's less of a concern. But what about at a company where multiple people may have access to a system?
Am I being too paranoid here? Or is there a better way to allow DNS challenges without a token that allows too much power in editing a DNS zone?
The article says it is for those who
> prefer to keep DNS updates and sensitive credentials out of their issuance path.
I'd look for a custom DNS challenge provider plugin which delegates the task of creating DNS records to another machine which holds the actual token.
Depending on your DNS provider, it may be possible to narrow the permissions to allow only updates of a particular record. Route53 as an example:
{
"Effect": "Allow",
"Action": "route53:ChangeResourceRecordSets",
"Resource": "arn:aws:route53:::hostedzone/<ZONE-ID>",
"Condition": {
"ForAllValues:StringEquals": {
"route53:ChangeResourceRecordSetsNormalizedRecordNames": "_acme-challenge.<SUB>.<DOMAIN>.<TLD>"
}
}
}
* https://github.com/acmesh-official/acme.sh/wiki/How-to-use-A...BIND 9 example:
* https://dan.langille.org/2020/12/19/creating-a-very-specific...
You can also point the hostname that you wish to issues certs for to another (sub-)domain completely via a CNAME, and allow updates only for that other (sub-)domain:
* https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo...
* https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se...
[0]: https://github.com/gregtwallace/brother-cert/blob/main/pkg/p...
[1]: https://github.com/gregtwallace/brother-cert/blob/main/pkg/p...
BTW: The easiest way to run certbot in a container is to mount a renew script (some shell script as simple as `certbot renew`) to /etc/periodic/daily/renew, then change the container's entrypoint to `crond -d6 -f`.
lousken•51m ago
justin_oaks•40m ago
As for putting it on a separate VLAN and securing traffic with firewall rules, that may be as much or more trouble than setting up the automated certificate renewal. At least with the automated certificates there may not be any further maintenance required. With firewall rules, you'll need to open up the firewall each time you want a new device to access the printer.
dns_snek•39m ago
Sticking it on a VLAN only controls access, not data secrecy.