Drei Tage vor Ablauf
Eine ganz normale Anfrage: Was kostet der Tausch des Wildcard-Zertifikats auf unserer Horizon-Umgebung? Mehrere Verbindungsserver, ein Unified Access Gateway davor. Unsere Schätzung: ein paar Stunden, mit Prüfung und Funktionstest.
Freigegeben wurde das mit einer guten Auflage: Dokumentation und Wissenstransfer gleich einplanen, damit der nächste Tausch ohne uns geht.
Als das Zertifikat bei uns lag, kam die Frage nach dem Ablaufdatum. Antwort: in drei Tagen.
So etwas sehen wir öfter, als man denkt. Ein Zertifikat läuft ein oder zwei Jahre, und in der Zeit vergisst jeder, wann. Bis jemand nachsieht.
Die Verbindungsserver
Der Teil war Routine. Auf jedem Verbindungsserver kommt das neue Zertifikat mit privatem Schlüssel in den Zertifikatsspeicher des Computers. Der private Schlüssel muss exportierbar sein. Horizon erkennt sein Zertifikat am Anzeigenamen vdm: Das neue bekommt ihn, das alte verliert ihn, dann wird der Dienst neu gestartet. Eine gute Schritt-für-Schritt-Anleitung dafür steht bei The DXT
.
Am nächsten Morgen waren alle Verbindungsserver getauscht.
Das Gateway
Dann das Gateway. Das hinterlegte Kennwort stimmte nicht, und ein anderes kannte niemand. Ein Gateway, das man nicht mehr verwalten kann, ist zwei Tage vor Ablauf ein ernstes Problem.
Omnissa beschreibt für genau diesen Fall, wie man das Root- und das Admin-Kennwort über die Konsole der Appliance zurücksetzt. Das haben wir gemacht. Danach ließ sich das Gateway wieder verwalten.
Beim Blick in die Konfiguration fiel dann etwas auf, das mit dem Zertifikat nichts zu tun hatte. Das Gateway zeigte auf genau einen der Verbindungsserver. Und es gab nur dieses eine Gateway.
Mehrere Verbindungsserver sehen nach Redundanz aus. Für jeden, der von außen kommt, gab es aber genau einen Weg: ein Gateway, ein Server. Fällt einer der beiden aus, ist der externe Zugang weg, egal wie viele Verbindungsserver dahinter laufen.
Der Tausch
Am Abend, mit angekündigter kurzer Unterbrechung des externen Zugangs. Die Anwender mussten sich danach einmal neu anmelden, dann liefen die Verbindungen wieder.
Am nächsten Tag der Test beim Kunden: alles in Ordnung. Kurz danach lief das alte Zertifikat ab. Viel Puffer war das nicht.
Die Frage, die der Kunde gestellt hat
Im Ticket stand eine kluge Frage: Wie soll das künftig gehen, wenn Zertifikate immer kürzer gelten? Die Laufzeit öffentlicher TLS-Zertifikate sinkt nach den Beschlüssen des CA/Browser Forums schrittweise: höchstens 200 Tage seit März 2026, 100 Tage ab März 2027, 47 Tage ab März 2029 .
Bei 47 Tagen ist ein Tausch, der Handarbeit und ein Kennwort braucht, das niemand mehr kennt, keine Option mehr.
Was wir daraus mitnehmen
- Ablaufdaten kennen, bevor jemand fragt. Drei Tage Vorlauf sind zu wenig, wenn unterwegs etwas klemmt.
- Zugänge prüfen, bevor man sie braucht. Ein Kennwort, das nicht stimmt, fällt sonst genau dann auf, wenn die Zeit knapp ist.
- Redundanz von außen nach innen ansehen. Wie viele Server dahinter stehen, ist egal, wenn der Weg dorthin nur einer ist.
- Den Tausch aufschreiben und automatisieren. Die Auflage des Kunden war richtig. Bei kürzeren Laufzeiten wird aus der Dokumentation bald ein Skript werden müssen.
Was beim Tausch an Horizon sonst noch übersehen wird, steht in Ein Arbeitstag und ein Feld . Und was bei Zertifikaten im vCenter schiefgehen kann, in Alle Zertifikate erneuert. Bis auf eins.