TECHNIK · AI VM SETUP BLUEPRINT
Private Apps mit öffentlichen Zertifikaten: zwei Traefik-Controller, zwei Wege zu TLS
Ein vom Browser akzeptiertes Zertifikat setzt keine öffentlich erreichbare Anwendung voraus. Domainvalidierung und Anwendungszugriff dürfen unterschiedliche Wege nehmen. Der VM Blueprint nutzt das, um private Dienste per HTTPS bereitzustellen, ohne öffentliche Anfragen an deren Backends weiterzuleiten.
Internet → öffentlicher Traefik → öffentliche Apps Betreiber → VPN → privater Traefik → private Apps
Zertifizierungsstelle → öffentliche IP :80 → öffentlicher Traefik → ausschließlich temporärer ACME-Solver cert-manager → TLS-Secret → privater Ingress VPN-Client → privater Traefik → private App
Zertifikatsautomatisierung → DNS-API → öffentlicher TXT-Eintrag Zertifizierungsstelle → autoritatives DNS → Validierung Ausgestelltes Zertifikat → privater Traefik → private App
Zwei Controller, zwei explizite Klassen
Der öffentliche Traefik-Controller verarbeitet die aus dem Internet erreichbaren Routen. Ein zweiter Traefik-Controller bedient private Routen über das VPN. Jeder berücksichtigt seine eigene explizite Ingress-Klasse; keine ist als Standard gesetzt. Zusätzlich prüft die Bereitstellung die Provider-Filter, damit eine andere aktivierte Routen-API die Trennung nicht umgeht.
Für das private Backend gibt es keine Anwendungsroute auf dem öffentlichen Controller. NetworkPolicies und Prüfungen alternativer Zugangswege ergänzen diese Grenze. Ein im DNS versteckter Hostname allein schützt nichts: Ein externer Client kann den Namen direkt an eine öffentliche IP senden.
Option 1: HTTP-01 auf dem öffentlichen Controller
Für einen Namen wie crm.int.example.com zeigt das öffentliche DNS auf die öffentliche Adresse. Let’s Encrypt prüft HTTP-01 auf Port 80 unter /.well-known/acme-challenge/<token>. cert-manager legt dafür eine temporäre Solver-Route auf der öffentlichen Ingress-Klasse an. Diese liefert die Challenge-Antwort, nicht die private Anwendung.
Eine eigenständige Certificate-Ressource fordert das Zertifikat über einen Issuer an, dessen HTTP-01-Solver ausdrücklich die öffentliche Klasse auswählt. Der private Ingress verweist auf das erzeugte TLS-Secret in seinem eigenen Namespace. Der private Traefik-Controller verwendet das Zertifikat ohne eigenen ACME-Resolver.
Nach der Validierung wird die temporäre Challenge-Route entfernt. Öffentliche Anfragen für die private Anwendung finden weiterhin keine passende Anwendungsroute. In diesem Aufbau liefert öffentliches HTTP die allgemeine 404-Antwort; bei öffentlichem HTTPS kann bereits die Zertifikatsprüfung scheitern, weil der öffentliche Controller das Zertifikat des privaten Hosts nicht ausliefert. Private Anwendungsinhalte dürfen auf keinem der Wege erscheinen.
Derselbe Hostname, eine andere Adresse im VPN
VPN-Clients lösen crm.int.example.com über einen hosts-Eintrag oder eine auf int.example.com begrenzte Resolver-Regel zur Tunnel-Adresse auf. Im Browser bleibt der Hostname gleich. Das Zertifikat gilt deshalb auch dann, wenn die Verbindung eine andere Adresse erreicht.
Der öffentliche DNS-Eintrag muss für HTTP-01-Verlängerungen weiter auf den öffentlichen Challenge-Endpunkt zeigen. Wer ihn durch die VPN-Adresse ersetzt, kann ein heute funktionierendes Zertifikat behalten und trotzdem die nächste Verlängerung verhindern. Auch veröffentlichte IPv6-Einträge müssen auf einen erreichbaren Solver führen.
Eine eigene interne Subdomain begrenzt die Resolver-Regel auf private Namen, ohne sämtliche öffentlichen DNS-Abfragen umzuleiten. VPN-Verbindung, lokale Namensauflösung und Zertifikatsausstellung erfüllen unterschiedliche Aufgaben.
Option 2: DNS-01 über eine automatisierte DNS-API
Bei DNS-01 wird die Kontrolle über die Domain durch einen TXT-Eintrag unter _acme-challenge.crm.int.example.com belegt. Die Zertifizierungsstelle prüft das autoritative öffentliche DNS. Sie braucht weder eine eingehende Verbindung zur privaten App noch eine öffentliche HTTP-Challenge-Route. DNS-01 unterstützt außerdem Wildcard-Zertifikate.
Die automatische Verlängerung benötigt eine unterstützte DNS-API-Anbindung, direkt oder über eine delegierte Challenge-Zone. Zugangsdaten sollten eng begrenzt sein; DNS-Propagation und Credential-Rotation gehören in die Planung. Manuell gesetzte TXT-Einträge sind keine dauerhafte Lösung für unbeaufsichtigte Verlängerungen.
Das alternative Beispiel im Blueprint verwendet Traefiks eigenen ACME-Resolver für DNS-01. Auch cert-manager kann die Ausstellung übernehmen und ein TLS-Secret schreiben. Pro Hostname sollte genau eine Komponente zuständig sein. Traefik und cert-manager dürfen nicht unabhängig dasselbe Zertifikat verwalten. Wiederherstellungsrelevanter Zustand und Secret-Verweise der gewählten Lösung müssen gesichert werden.
Welche Variante passt?
HTTP-01 ist im Blueprint die einfachere Voreinstellung, wenn ein öffentlicher Challenge-Endpunkt verfügbar ist. Dafür braucht der Cluster keine DNS-Schreibberechtigung. Im Gegenzug müssen der öffentliche DNS-Eintrag und die Validierung über Port 80 erhalten bleiben, obwohl die Anwendung privat ist.
DNS-01 eignet sich, wenn öffentliche HTTP-Validierung nicht möglich oder nicht gewünscht ist oder Wildcards benötigt werden. An die Stelle der Netzwerkabhängigkeit treten DNS-API-Rechte und deren Automatisierung. Bei beiden Varianten gilt: Ein öffentlich vertrauenswürdiges Zertifikat hält den Hostnamen nicht geheim. Zertifikatsnamen können in öffentlichen Certificate-Transparency-Logs auftauchen.
Den Zugangsweg prüfen, den es nicht geben darf
Zuerst wird über das VPN die erwartete private Antwort samt gültigem Zertifikat geprüft. Danach folgt der Test von außerhalb des VPN: Der private Hostname wird mit passendem Host-Header und TLS-SNI gezielt an jede öffentliche Adresse geschickt. Die private Antwort darf nie erscheinen. Gefälschte Forwarding-Header, alternative Ports und Schnittstellen gehören ebenfalls zur Prüfung.
Eine 404 allein reicht nicht, wenn sie von der privaten Anwendung stammt. Deshalb werden Antwortidentität und Status verglichen und die Trennung der Controller-Klassen geprüft. Eine falsche Ingress-Klasse kann ein Backend veröffentlichen; die Trennung braucht daher Konfigurationsprüfungen und Zugriffsschutz auf Workload-Ebene.
Zum Schluss müssen Ausstellung und Verlängerung der Zertifikate überprüft werden. Dass eine App heute funktioniert, belegt noch nicht, dass DNS-Zugangsdaten, Challenge-Routing und Resolver-Regeln bei der nächsten Verlängerung oder nach einem Wiederaufbau funktionieren.