Never heard that one before.
How often is the acme-dns server in use?
If "too often", then you might consider keeping it on behind a good IPS and/or behind a dedicated DNS proxy/relay.
When the attack vector(s) are known, I simply deploy the most feasible known defense from each.
2 Likes
acme-dns can be left on if wanted.
The common usage pattern, however, is to only enable acme-dns during certificate procurement.
This can be done by using Certbot's pre/post hooks to 1) enable/disable the acme-dns service, 2) change ip firewall rules, or 3) both. If multiple servers are using a single acme-dns service, it's easiest to have a cronjob enable/disable acme-dns/firewall at a set time for renewals.
4 Likes
Interesting idea with cronjob for service. Enabling it every 2,5 months.
The pattern is usually to enable/disable daily. For example:
- acme-dns server on 4:30am, off 5:00am daily
- machines running certbot set to renew at 4:35am daily
Certbot starts at least 5 minutes later to account for clock-drift and incorrect times.
If your organization is too paranoid to implement one of the common usage patterns, IMHO your best option is to not use automatic renewals and have a person manually handle renewals + acme-dns/firewall + certificate deployment every 2 months. That workflow is less effort and less prone to timing issues than trying to properly automate the necessary coordination of services in an overly and needlessly secured system.
2 Likes
I made acme-dns server exactly for automatic renewals. We have more than dozen of certificates and renewing it manually (DNS challenge) is a giant pain.
If you are trying over-secure your system by using cron-jobs to only allow renewals every 2.5 months, you will either have to invest an incredibly large amount of resources to avoid timing problems and ensure fallback opportunities - or you will have to live with those problems. The people who believe they can implement a poorly designed system always regret their decisions later, and complain here when things fail and they realize they created an emergency situation. Certbot and similar systems are designed to run daily after 60 days as a fallback system to ensure renewals of 90 day certificates.
The status-quo method of handling renewals from multiple servers against a single locked-down acme-dns instance is what I mentioned above - the acme-dns server is available every day for a certain window, and the various acme clients are set to attempt renewals at that time. That is a low-effort pattern that works for many users. If there is only one server involved, acme-dns and firewall rules can be easily controlled by Certbot's pre/post hooks.
If your organization does not want to use that pattern, the work-effort involved in automating the coordination of multiple servers is rather large. Unless you have the resources to invest in creating, testing, and maintaining that effort ā which few organizations are willing to do ā I believe the best option is to assign a human to manually renew the certificates on a set schedule. That does not mean the person cannot use acme-dns to automate that portion ā they should ! ā it means that a person will be tasked a set schedule to enable/disable acme-dns/firewalls themselves, and invoke Certbot or whatever client(s) are used.
For example, while my organization uses automated certificate renewals for our public facing infrastructure, we also use a manual system for our internal testing and development infrastructure. On the first Tuesday of every month, someone runs a script that:
- ssh's into firewall and enables a firewall rule + acme-dns service
- invokes certbot
- ssh's into firewall and disables a firewall rule + acme-dns service
- deploys the certificates onto local machines (ssh, etc), enrolls them in version control for developer access.
While that process is entirely automated, the coordination of all the required services and servers has too much potential for error, and we often encounter errors. The work effort to fully automate our solution with proper error handling and notifications was estimated at 80-120 hours. In contrast, having someone manually initiate and monitor this process is only 15 minutes once a month.
5 Likes
Please do yourself a favor and use a DNS Provider from this list:
(or find one that should be on the list but isn't)
1 Like
Unfortunately, we can't change our DNS provider for few reasons. I wanted Cloudflare but no.
I would then suggest putting in a Service Request with the present DNS Provider to implement and make available an ACME DNS-01 API for applications to use their DNS Server easily for ACME clients.
1 Like
What is the acme-dns being used for [and how]?
2 Likes
Have you considered pointing CNAMEs to a dedicated challenge domain at a compatible provider?
I'm not finding my preferred articles quickly enough, but this one appears to do a good job of explaining the concept.
4 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.