Sicheres internes TLS mit ACME-Proxys und DNS-Delegation

Self-hosted Umgebungen haben oft Schwierigkeiten, gültige TLS-Zertifikate für Dienste zu erhalten, die nicht direkt vom Internet aus erreichbar sind. Ein kürzlich veröffentlichter technischer Leitfaden von Sapiolab skizziert eine robuste Architektur unter Verwendung eines ACME-Proxys und eines dedizierten DNS-Servers, um diese Konnektivitätslücke zu schließen. Der Artikel wurde am 15. Oktober 2026 veröffentlicht und bietet Betreibern von Homelabs und kleinen IT-Teams eine schrittweise Methode zur sicheren Automatisierung der Zertifikatsausstellung.

Was passiert ist

Die zentrale Herausforderung, die adressiert wird, ist die Einschränkung der Standard-ACME-Validierungsmethoden für interne Server. HTTP-01-Challenges erfordern, dass der Server vom öffentlichen Internet aus erreichbar ist, was für private Infrastrukturen oft unmöglich oder unsicher ist. DNS-01-Challenges erfordern API-Zugriff auf den autoritativen DNS-Anbieter, was Sicherheitsrisiken birgt, wenn Zugangsdaten auf internen Maschinen exponiert werden. Die vorgeschlagene Lösung besteht darin, einen ACME-Proxy bereitzustellen, der als Vermittler zwischen internen Clients und öffentlichen Zertifizierungsstellen (Certificate Authorities) fungiert.

Dieser Proxy wandelt interne Validierungsanfragen in externe DNS-01-Aufträge um. Um die primären DNS-API-Schlüssel nicht preiszugeben, nutzt das Setup einen separaten ACME-DNS-Server. Dieser lokale Server verarbeitet Challenge-Records über einen CNAME-Delegations-Trick, sodass öffentliche CAs die Domain-Eigentümerschaft validieren können, ohne auf die Haupt-DNS-Zone zugreifen zu müssen. Der Leitfaden führt durch die Installation von MariaDB, NGINX, Step CA und Unbound, um eine vollständig automatisierte, sichere Zertifikats-Pipeline zu erstellen.

Wichtige Details

• Die Architektur verwendet Step CA oder Lab-CA für das interne Zertifikatsmanagement, wobei Step CA als leichter und einfacher zu installieren hervorgehoben wird.
• Ein ACME-Proxy übersetzt interne HTTP-01- oder DNS-01-Anfragen in externe DNS-01-Aufträge für öffentliche CAs wie Let’s Encrypt oder ZeroSSL.
• External Account Binding (EAB) kann mehrere interne Konten unter einem externen Konto zusammenfassen, wobei das Verhalten bei der Domain-Verifizierung je nach Anbieter variieren kann.
• ACME DNS dient als Brücke, indem _acme-challenge TXT-Records lokal gehostet werden, während die öffentliche CA einem CNAME-Record folgt, um sie zu finden.
• Das Setup erfordert eine Split-DNS-Konfiguration unter Verwendung von Unbound, um interne Abfragen korrekt aufzulösen, während Challenge-Subdomains delegiert werden.
• Private Zertifikate vermeiden Certificate Transparency Logs, erfordern aber die manuelle Installation des Trust Stores auf jedem Client-Gerät und Container-Image.

Hintergrund

ACME ist das Protokoll, das von den meisten modernen Zertifizierungsstellen zur Automatisierung der Ausstellung von TLS-Zertifikaten verwendet wird. Es basiert auf Challenges, um die Eigentümerschaft einer Domain nachzuweisen. HTTP-01 platziert eine Datei auf dem Webserver, während DNS-01 einen spezifischen Text-Record zur DNS-Zone der Domain hinzufügt. Für interne Server ist keine dieser Methoden unkompliziert, da der Server hinter Firewalls verborgen ist und die Gewährung von DNS-API-Zugriff auf jeden internen Dienst eine erhebliche Angriffsfläche schafft.

Certificate Transparency Logs sind öffentliche Register, die alle ausgestellten öffentlichen Zertifikate aufzeichnen. Während dies die allgemeine Internetsicherheit erhöht, ermöglicht es Angreifern auch, neue Subdomains und Dienste zu entdecken. Private Zertifizierungsstellen vermeiden diese Logs, führen aber zu operativem Mehraufwand, da jedes Gerät und jede Anwendung so konfiguriert werden muss, dass es dem privaten Root-Zertifikat vertraut. Dies ist besonders schwierig in heterogenen Umgebungen, die Docker-Container oder Sprachen wie Python verwenden, die ihre eigenen Zertifikatsspeicher pflegen.

Warum es wichtig ist

Für Teams, die Self-hosted Software betreiben, ist die Aufrechterhaltung gültiger TLS-Zertifikate entscheidend für Sicherheit und Compliance. Abgelaufene oder ungültige Zertifikate brechen Integrationen, verursachen Browser-Warnungen und untergraben das Vertrauen der Nutzer. Die Automatisierung dieses Prozesses reduziert den administrativen Aufwand für DevOps-Ingenieure, die sich sonst auf manuelle Erneuerungsskripte oder langlebige statische Zertifikate verlassen müssten. Das ACME-Proxy-Muster ermöglicht es Organisationen, vertrauenswürdige öffentliche Zertifikate für interne Dienste zu nutzen, ohne die Netzwerksicherheit durch das Öffnen eingehender Ports zu gefährden.

Darüber hinaus begrenzt die Trennung des DNS-Validierungsmechanismus vom primären DNS-Anbieter die Auswirkung eines potenziellen Lecks von Zugangsdaten. Wenn ein interner Dienst kompromittiert wird, erhält der Angreifer nur Zugriff auf den eingeschränkten ACME-DNS-Server, nicht aber die Möglichkeit, kritische DNS-Records wie MX- oder A-Records für die Hauptdomain zu ändern. Dieser Defense-in-Depth-Ansatz ist für kleine und mittelständische Unternehmen, die ihre eigene Infrastruktur verwalten, aber keine großen Sicherheitsteams haben, unerlässlich.

Was Sie tun können

• Bewerten Sie, ob Ihre internen Dienste den operativen Mehraufwand für die Verwaltung eines privaten CA-Trust-Stores über alle Clients hinweg tolerieren können.
• Stellen Sie einen ACME-Proxy bereit, wie im Beispiel mit Step CA beschrieben, um Zertifikatsanfragen aus internen Netzwerken zu bearbeiten.
• Richten Sie eine dedizierte ACME-DNS-Instanz ein, um Challenge-Records zu verarbeiten, und vermeiden Sie so die Preisgabe primärer DNS-API-Schlüssel.
• Konfigurieren Sie CNAME-Records in Ihrer öffentlichen DNS-Zone, um _acme-challenge-Subdomains an Ihren lokalen ACME-DNS-Server zu delegieren.
• Implementieren Sie Split-Horizon-DNS mit Tools wie Unbound, um sicherzustellen, dass interne Clients Dienste korrekt auflösen, während externe Validatoren die Challenge-Records erreichen können.
• Überwachen Sie Zertifikatsablaufdaten aktiv, da automatisierte Systeme weiterhin aufgrund von Netzwerkänderungen oder Konfigurationsdrifts versagen können.