Das stimmt wohl. Aber wie hast du das realisiert?
Zentrale VM am Homeserver, auf der getssl läuft und die DNS-Challenge verwendet wird. Die Zertifikate werden danach über SSH vollautomatisch auf die Zielsysteme kopiert und benötigte Dienste werden gleich reloaded oder restartet. Bei proprietären Mist gibt es statt SSH meistens kleinere Shell/PHP/Python Scripts, die das neue Zertifikat über HTTP (oder was es halt sonst gibt) am Zielsystem importieren. Natürlich hat diese VM dann theoretisch Vollzugriff auf alle konfigurierten Systeme. Wobei man das mit einem eigenen SSH-User, weiteren Scripts und sudo entschärfen könnte. Habe ich bei mir aber nicht gemacht. Wenn mir jemand diese VM knackt, habe ich sowieso ganz andere Probleme.
Als Anregung noch ein Beispiel, was man mit GetSSL konfigurationsmäßig alles anstellen kann: https://forum.netcup.de/sonstiges/sons…ent/#post167808
Was ich mir in Deinem Fall aber auch vorstellen könnte: Zentraler Webserver mit z.B. PHP hinter HTTP-Auth, der Challenge-Tokens (GET/POST) entgegen nimmt und sie an die jeweilige DNS-API weiterleitet. Oder alternativ auch einfach ein SSH-User mit Keyfile, der nur ein bestimmtes Wrapper-Script ausführen darf. Der ACME-Client wird dann auf allen Systemen so umkonfiguriert, dass er statt direkt mit der DNS-API zu sprechen, einen wget/curl/ssh Request an Deinen zentralen Host abfeuert. Somit muss das System mit dem ACME-Client keine Details und Zugangsdaten der DNS-API kennen. Und der zentrale Host hat wiederum keinen Zugriff auf Deine Systeme. Durchaus eine Win-Win-Situation, auch wenn die Ersteinrichtung aufwändig ist.
In Verbindung mit meiner miserablen Dokumentation hat das den Nachteil, dass ich gar nicht so genau weiß welche Hosts alle so Zertifikate abrufen. Aber das könnte ich ja bei Letsencrypt nachschauen, was so an subdomains gelistet ist .. 
crt.sh, wenn es keine Wildcard-Zertifikate sind. 
