[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`.
Try entering a long wifi-password via the 1-line lcd and 2 buttons on the printer, what a nightmare. (No way to configure via usb). Oh well, I still have a couple of days before I need to print a bunch of documents, so there goes the weekend ;)
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?
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>"
}
}
}
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...
I've never heard of that CNAME approach for changing the validation domain. That looks like a viable solution since it requires a one-time setup on the main domain and ongoing access to the second (validation) domain.
At my last job we deployed a special sub-domain for that purpose (dnsauth.example.com) and manually created CNAMEs on our main (sub-)domains to point to it.
We then deployed a single (no-HA) externally exposed BIND server with a bunch of scripts that folks could connect to (we had deploy hooks scripts for users/developrs). Nowadays there even purpose-build DNS servers for this purpose:
My solution was to give up on CertBot and use dehydrated instead. This did require me to come up with a script to make the necessary API call to the DNS hosting, which dehydrated will then run as necessary.
A CertBot ticket on the subject opened January 2026:
The article says it is for those who
> prefer to keep DNS updates and sensitive credentials out of their issuance path.
I see that AWS permissions can be set to limit the risk of compromised credentials. That's a good idea. I see that the lego project has an example of this in their documentation: https://go-acme.github.io/lego/dns/route53/index.html#least-...
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.
> Get certificates for remote servers - The tokens used to provide validation of domain ownership, and the certificates themselves can be automatically copied to remote servers (via ssh, sftp or ftp for tokens). The script doesn't need to run on the server itself. This can be useful if you don't have access to run such scripts on the server itself, e.g. if it's a shared server.
* https://github.com/srvrco/getssl
It's written in Bash, so dependencies aren't too heavy.
If something gets the credentials for desec.io, they can only use them to do stuff with the single txt record.
No need to give broader access
Given the immense popularity of Cloudflare DNS + API + ACME DNS-01 challenge, why are not other DNS providers stepping into this foray?
You can use a boatload of providers for automated DNS-01.
I've built some custom AspNetCore middleware that completely owns the entire thing. I tried win-acme and other clients but they aren't in the same room of convenience. All I need to provide is the desired hostname to the middleware and ensure traffic destined for that FQDN winds up at the server. HTTP-01 is used to verify, so I don't have to screw with anything other than an A record. If the hostname is null, it issues an IP address certificate instead using Amazon's public IP lookup service to derive the appropriate SAN. Certs are automatically refreshed when they are within 48 hours of expiration, and the actual swap is a X509Certificate2 reference being updated. It's about as trivial as it gets.
None of the libraries/CLI tools I attempted support anything like this experience. This is what originally put me off to the ecosystem and the idea of short lived certificates. The automation can't just be "sufficient". It needs to be "fucking incredible". $12.95/yr is not that expensive to me if the alternative is getting sucked into hours and hours of someone else's idea of a good time.
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.
Sticking it on a VLAN only controls access, not data secrecy.
also 9/10 printing protocols are insecure anyway
scans - sure, mailserver needs to be allowed
vendor support - same mailserver
vm - at least a reason to kill it
also why would i ever allow auto updates, it's better not to without understanding what garbage manufacturer released this time