Uhrzeit-Desynchronisation und Proxy-Ausfälle: TLS-, Token- und Signatur-Diagnose
Inhalt des Artikels
- Grundlagen: warum die zeit teil des protokolls ist und nicht nur eine zahl auf dem bildschirm
- Tiefe einblicke: wo genau die zeit kritisch ist
- Wie der fehler in verschiedenen clients aussieht
- Warum uhren abdriften: anatomie der drift
- Diagnose in einer minute: schnell zur diagnose
- Synchronisation einrichten: damit sie wirklich funktioniert
- Container und uhren: was wird geerbt und was nicht
- Typische fehler: was man nicht tun sollte
- Werkzeuge und ressourcen
- Fälle und ergebnisse
- Faq: tiefe antworten auf häufige fragen
Stellen Sie sich vor: Gestern lief Ihr Parser über den Proxy einwandfrei, die Logs waren sauber, die Metriken grün. Heute Morgen öffnen Sie das Dashboard und sehen eine Wand voller Fehler: certificate is not yet valid, token expired, signature does not match. Der erste Gedanke eines Ingenieurs ist vorhersehbar: Der Proxy ist kaputt, der Anbieter hat etwas verändert, wir müssen den Pool wechseln. Sie verbringen Stunden mit Netzwerkdiagnose, tauschen Endpunkte aus, schreiben dem Support. Und die Ursache saß die ganze Zeit direkt vor Ihrer Nase und tickte falsch. Es ist die Systemuhr.
Zeitdesynchronisation ist eine der am meisten unterschätzten Ausfallquellen in Infrastrukturen, die über Proxys laufen. Sie ist heimtückisch, weil sie sich als Netzwerk- und Zertifikatsproblem tarnt. Sie sehen das Wort certificate in der Fehlermeldung und gehen reflexartig los, um TLS zu untersuchen, obwohl das Zertifikat völlig lebendig und gültig ist. Ihre Maschine denkt nur, es sei ein anderer Tag.
In diesem Ratgeber behandeln wir das Thema von A bis Z. Sie erfahren, wo genau die Zeit in die Kryptografie und die Protokolle eingebaut ist, wie konkrete Fehler in curl, Python und Node aussehen, warum Uhren in VMs und Containern abweichen, wie Sie in einer Minute eine Diagnose stellen und wie Sie die Synchronisation so einrichten, dass sie wirklich funktioniert und nicht nur installiert ist. Das Material wurde von Proxeon-Ingenieuren auf Basis der Analyse realer Vorfälle verfasst. Wir betonen ausdrücklich: Es geht nicht um die Ausstellung von Zertifikaten und nicht um deren Aufbau – nur um die Zeit als Ausfallursache.
Grundlagen: Warum die Zeit Teil des Protokolls ist und nicht nur eine Zahl auf dem Bildschirm
Beginnen wir mit dem Fundament. Viele betrachten die Systemzeit als rein menschliche Konvention: Es ist praktisch zu wissen, dass es gerade 14:30 Uhr ist. Doch in der Welt der Netzwerkprotokolle ist die Zeit ein aktiver Teilnehmer an Sicherheitsprüfungen. Sie ist auf mehreren Ebenen gleichzeitig in die Validierungslogik eingebaut.
Wenn zwei Knoten eine gesicherte Verbindung aufbauen oder signierte Nachrichten austauschen, brauchen sie eine Möglichkeit, frische Daten von veralteten zu unterscheiden. Ohne ein Zeitverständnis lassen sich einfache Fragen nicht beantworten: Ist dieses Zertifikat abgelaufen? Ist dieser Token veraltet? Wiederholt ein Angreifer eine alte abgefangene Anfrage? Genau deshalb sind Zeitstempel und Gültigkeitsfenster in die Protokolle eingebaut.
Was die Systemzeit ist und woher sie kommt
In jedem Betriebssystem gibt es zwei zusammenhängende Konzepte. Erstens die Hardware-Uhr (RTC, real-time clock), ein Chip mit eigener Batterieversorgung, der auch bei ausgeschaltetem Computer weiterläuft. Zweitens die Systemuhr, die der OS-Kernel im Arbeitsspeicher führt, ausgehend vom RTC-Wert beim Start und im Betrieb nachjustierend.
Das Problem: Der Quarzoszillator in jeglicher Hardware ist nicht ideal. Er geht pro Tag um Bruchteile einer Sekunde vor oder nach. Das nennt man Uhrendrift. In einer Woche ohne Korrektur sammeln sich merkliche Sekunden an, in manchen virtuellen Umgebungen ganze Minuten. Um die Drift zu bekämpfen, wurde ein Netzwerkzeitprotokoll erfunden. Der Synchronisationsdaemon fragt regelmäßig bei Referenzservern die genaue Zeit ab und führt die lokale Uhr sanft nach.
UTC, Zeitzonen und warum das für Proxys wichtig ist
Eine wichtige Erkenntnis für Einsteiger: Die gesamte ernsthafte Netzwerkkryptografie arbeitet in UTC – der koordinierten Weltzeit, ohne Bindung an Zeitzonen. Zertifikate, JWT, Request-Signaturen – alles operiert mit Zeitpunkten in UTC. Die Zeitzone ist nur Kosmetik für die Anzeige gegenüber dem Menschen.
Das bedeutet: Wenn Sie die Zeitzone falsch eingestellt haben, die absolute Zeit (in UTC) aber korrekt ist, leidet die Kryptografie nicht. Wenn jedoch die absolute Zeit falsch ist, gerät alles durcheinander. Häufige Verwechslung: Der Ingenieur sieht im Log eine seltsame lokale Zeit, geht die Zeitzone reparieren, aber die eigentliche Ursache liegt woanders. Merken Sie sich die Trennung: Die Zeitzone beeinflusst die Anzeige, die absolute Zeit in UTC beeinflusst die Prüfungen.
Wie der Proxy ins Bild passt
Wenn Sie über einen Proxy arbeiten, entsteht ein zusätzlicher Knoten auf dem Weg der Anfrage. Aber wichtig zu verstehen: Der Proxy verändert oder ersetzt in den meisten Szenarien die Zeit in Ihren kryptografischen Prüfungen nicht. Der TLS-Handshake mit dem Zielserver, die Prüfung des Zertifikatsablaufs, die Token-Validierung – all das geschieht auf Ihrer Seite oder auf der Seite des Zielservers. Der Proxy überträgt nur Bytes.
Daher das Paradox: Die Arbeit über einen Proxy erzeugt kein Zeitproblem, macht aber seine Symptome verworrener. Der Ingenieur sieht die Kette Client – Proxy – Server und verdächtigt natürlich das Zwischenglied. Schuld ist aber die lokale Maschine, deren Uhr falsch läuft. Wir nennen das den Effekt des verschobenen Verdachts: Je länger die Kette, desto eher beschuldigen wir ihre Mitte statt ihre Enden.
Tiefe Einblicke: Wo genau die Zeit kritisch ist
Jetzt tauchen wir tiefer ein und betrachten konkrete Punkte, an denen falsche Zeit zum Ausfall wird. Es gibt vier, und jeder verdient besondere Aufmerksamkeit.
Prüfung der Zertifikatsgültigkeit in TLS
Jedes TLS-Zertifikat enthält zwei Felder: notBefore (nicht gültig vor) und notAfter (nicht gültig nach). Das sind die Grenzen des Gültigkeitsfensters. Wenn Ihr Client eine gesicherte Verbindung aufbaut, erhält er das Serverzertifikat und prüft: Fällt die aktuelle Zeit in dieses Fenster?
Und hier der entscheidende Punkt: Unter aktueller Zeit versteht man die Zeit auf Ihrer Maschine. Wenn Ihre Uhr nachgeht und ein Datum vor notBefore anzeigt, entscheidet der Client, dass das Zertifikat noch nicht in Kraft getreten ist. Fehler wie certificate is not yet valid. Wenn die Uhr über notAfter hinausgelaufen ist – ist das Zertifikat für Sie bereits abgelaufen, obwohl es für den Rest der Welt frisch ist. Fehler certificate has expired.
Besonders heimtückisch sind kurzlebige Zertifikate. Die moderne Praxis bewegt sich zu Zertifikaten mit 90 Tagen Laufzeit und weniger, und bis 2026 diskutiert die Branche eine Verkürzung auf 45 Tage und darunter. Je kürzer das Gültigkeitsfenster, desto weniger Sicherheitsmarge gegen falsch gestellte Uhren. Früher war eine Stunde Desynchronisation bei einem Jahreszertifikat fast unbemerkt. Jetzt bedeutet ein enges Fenster, dass selbst eine Verschiebung um einige Stunden an der Erneuerungsgrenze eine Verbindung zum Absturz bringen kann.
JWT: Felder exp, nbf und iat
JSON Web Token ist ein beliebtes Format für Autorisierungstoken. Darin leben Zeitfelder, die bei jeder Verwendung des Tokens geprüft werden:
- exp (expiration time) – der Zeitpunkt, nach dem der Token als abgelaufen gilt.
- nbf (not before) – der Zeitpunkt, vor dem der Token noch nicht gültig ist.
- iat (issued at) – wann der Token ausgestellt wurde.
Alle drei sind Unix-Timestamps in Sekunden seit der Epoche, also absolute Zeit in UTC. Wenn der Server einen Token erhält, vergleicht er diese Felder mit seiner Uhr. Wenn Ihr Client entscheidet, ob der Token erneuert werden muss, schaut er auf exp relativ zu seiner Uhr.
Das Ausfallszenario ist elegant in seiner Bösartigkeit. Angenommen, die Uhr Ihres Clients läuft zehn Minuten vor. Der Server hat einen Token mit fünf Minuten Lebensdauer ausgestellt. Ihr Client betrachtet mit seiner vorgehenden Uhr den frischen Token sofort als abgelaufen und sendet ihn entweder nicht oder startet eine Endlosschleife der Erneuerung. Umgekehrte Situation: Wenn nbf relativ zu Ihrer Uhr falsch ist, erhalten Sie token used before issued oder token not yet valid.
Request-Signaturen mit Zeitstempel
Viele APIs verlangen, dass jede Anfrage signiert ist, und in die Signatur wird ein Zeitstempel einbezogen. Klassisches Beispiel sind HMAC-Signaturschemata, bei denen der Client eine Zeichenkette aus Methode, Pfad, Body und aktuellem Timestamp bildet und diese mit einem geheimen Schlüssel signiert. Der Server wiederholt die Berechnung und vergleicht die Signaturen.
Hier spielt die Zeit eine Doppelrolle. Erstens geht der Timestamp in die signierte Zeichenkette ein, also muss der Server genau denselben Timestamp verwenden, den der Client gesendet hat – er nimmt ihn aus dem Header. Zweitens prüft der Server, dass dieser Timestamp nicht zu weit von seiner eigenen Zeit entfernt ist. Üblicherweise wird ein Fenster von einigen Minuten erlaubt – Schutz gegen Replay alter Anfragen.
Wenn die Uhr des Clients außerhalb dieses Fensters liegt, lehnt der Server die Anfrage als zu alt oder aus der Zukunft kommend ab. Fehler wie request timestamp too skewed, signature expired oder das allgemeine signature does not match. Und genau wegen der Zeit sehen Sie oft einen Signaturfehler statt eines Zeitfehlers – der Server sagt nicht immer ehrlich, dass es an der Uhr liegt.
Einmalcodes und temporäre Passwörter
Eine separate Kategorie sind zeitbasierte Einmalcodes (TOTP), die bei der Zwei-Faktor-Authentifizierung für den Zugang zu Verwaltungspanels und API-Konsolen verwendet werden. Ein solcher Code wird aus einem gemeinsamen Geheimnis und der aktuellen Zeit berechnet, die in Intervalle von üblicherweise 30 Sekunden unterteilt wird. Beide Seiten berechnen den Code unabhängig und vergleichen.
Wenn die Uhr des Clients um mehr als ein bis zwei Intervalle falsch ist, stimmen die Codes nicht mehr überein. Sie geben einen frisch generierten Code ein, und das System sagt, er sei falsch. Menschen beschuldigen in dieser Situation die Generator-App oder geraten wegen eines Hacks in Panik, obwohl ein Blick auf die Uhr gereicht hätte. Die Toleranz ist hier sehr eng – Dutzende Sekunden –, weshalb TOTP hervorragend als Indikator für Desynchronisation funktioniert.
Wie der Fehler in verschiedenen Clients aussieht
Theorie ist Theorie, aber der Ingenieur lebt im Terminal und liest Fehlermeldungen. Betrachten wir, wie sich Desynchronisation in populären Tools manifestiert. Das hilft Ihnen, das Symptom sofort zu erkennen.
curl
Bei der Arbeit mit TLS über curl ergeben falsch gestellte Uhren charakteristische Meldungen. Wenn die Zeit nachgeht und das Zertifikat nach Ihrer Uhr noch nicht in Kraft getreten ist:
curl: (60) SSL certificate problem: certificate is not yet validWenn die Zeit vorausgelaufen ist und das Zertifikat nach Ihren Maßstäben bereits abgelaufen ist:
curl: (60) SSL certificate problem: certificate has expiredEin nützliches Detail: Der Fehlercode 60 betrifft Zertifikatsprüfungsprobleme. Ein unerfahrener Ingenieur sieht das Wort certificate und geht los, das Zertifikat selbst mit einem Anzeigebefehl zu prüfen, stellt fest, dass die Gültigkeitsdaten in Ordnung sind, und gerät ins Stocken. Die Auflösung liegt darin, dass die Zertifikatsdaten mit Ihrer lokalen Zeit verglichen werden. Prüfen Sie ein Beispiel über den Proxy:
curl -x http://user:pass@gateway.proxeon.net:8080 -v https://api.example.com/statusWenn Sie in der -v-Ausgabe Zeilen zur Prüfung der Zertifikatsdaten und gleich danach einen Gültigkeitsfehler sehen – vergleichen Sie zuerst date -u mit der Referenz und verdächtigen Sie nicht das Gateway.
Python (requests und httpx)
In Python auf Basis des Standard-TLS-Stacks lösen falsch gestellte Uhren eine Ausnahme beim Handshake aus:
requests.exceptions.SSLError: HTTPSConnectionPool(host='api.example.com', port=443): Max retries exceeded (Caused by SSLError(SSLCertVerificationError("certificate verify failed: certificate is not yet valid")))Achten Sie auf das Ende der Meldung: certificate is not yet valid. Es ist dasselbe Zeitsymptom. Bei der Arbeit mit JWT ist das Bild anders – keine TLS-Fehler, aber die Token-Validierungsbibliothek wirft eine spezifische Ausnahme:
jwt.exceptions.ImmatureSignatureError: The token is not yet valid (nbf)oder
jwt.exceptions.ExpiredSignatureError: Signature has expiredHier ist das Wort signature verwirrend – es scheint, als läge das Problem in der kryptografischen Signatur. Tatsächlich weist expired genau auf das Feld exp und Ihre Uhr hin. Schnelle Zeitprüfung direkt aus dem Code:
import time, datetime; print(datetime.datetime.utcnow(), int(time.time()))Vergleichen Sie den erhaltenen Unix-Timestamp mit der Referenz – eine Abweichung von mehr als ein paar Sekunden ist bereits verdächtig.
Node.js
In Node kommen TLS-Fehler mit Codes. Charakteristisch für Desynchronisation sind:
Error: certificate is not yet valid\ncode: 'CERT_NOT_YET_VALID'und
Error: certificate has expired\ncode: 'CERT_HAS_EXPIRED'Die Codes CERT_NOT_YET_VALID und CERT_HAS_EXPIRED sind direkte Hinweise. Wenn Sie den ersten bei einem lebendigen Zertifikat sehen, geht Ihre Uhr nach. Wenn Sie den zweiten bei einem offensichtlich frischen Zertifikat sehen, läuft die Uhr vor. Bei der Arbeit mit JWT-Bibliotheken in Node erhalten Sie Fehler mit Namen wie TokenExpiredError und NotBeforeError. Schnelle Prüfung:
node -e "console.log(new Date().toISOString(), Math.floor(Date.now()/1000))"Übersichtstabelle der Symptome
Fassen wir die Muster in einer mentalen Landkarte zusammen:
- certificate is not yet valid / CERT_NOT_YET_VALID – die Uhr geht nach.
- certificate has expired / CERT_HAS_EXPIRED bei frischem Zertifikat – die Uhr läuft vor.
- token not yet valid / nbf / ImmatureSignature – die Uhr geht relativ zum ausstellenden Server nach.
- token expired / ExpiredSignature direkt nach Erhalt des Tokens – die Uhr läuft vor.
- signature does not match / timestamp too skewed – die Uhr ist aus dem Toleranzfenster des Servers gelaufen.
- Ständig falscher TOTP-Code – die Uhr ist um Dutzende Sekunden und mehr falsch.
Warum Uhren abdriften: Anatomie der Drift
Die Ursache zu verstehen ist die halbe Lösung. Betrachten wir, warum in moderner Infrastruktur Uhren häufiger falsch gestellt werden, als es scheint. Besonders betrifft das Server und Arbeitsknoten, durch die Sie Proxy-Traffic leiten.
Virtuelle Maschinen und Einfrieren
Eine virtuelle Maschine hat keinen direkten Zugriff auf den physischen Quarz. Ihre Vorstellung von der Zeit ist eine Abstraktion, die der Hypervisor pflegt. Normalerweise ist alles gut, solange die VM kontinuierlich arbeitet. Aber sobald der Hypervisor die Maschine anhält, beginnen die Wunder.
Das klassische Szenario ist Einfrieren und Snapshots. Der Hypervisor pausiert die VM, etwa für Migration oder Backup. Im Gast steht die Zeit quasi still. Wenn die Maschine aufgetaut wird, geht ihre Systemuhr genau um die Dauer der Pause nach. War es eine Minute – haben Sie eine Minutenverschiebung sofort, auf einmal. Für kurzlebige Token und enge Signaturfenster ist das fatal.
Noch schlimmer ist die Wiederherstellung aus einem alten Snapshot. Die Maschine erwacht mit der Zeit zum Zeitpunkt der Snapshot-Erstellung – das können Stunden oder Tage in der Vergangenheit sein. TLS beginnt sofort, Zertifikate als noch nicht gültig abzulehnen. Viele Cloud-Plattformen bieten Gast-Agenten, die die Zeit nach dem Auftauen nachführen, aber sie sind nicht immer vorhanden oder funktionieren nicht immer.
Container
Bei Containern ist die Geschichte subtiler. Ein Container hat keine eigene Systemuhr – er nutzt den Kernel des Hosts und damit die Host-Zeit. Das ist die gute Nachricht: Wenn der Host synchronisiert ist, sieht der Container automatisch die richtige Zeit.
Die schlechte Nachricht liegt in den Nuancen. Erstens kann man im Container normalerweise die Systemzeit nicht ändern – er hat keine entsprechenden Rechte, und das ist richtig. Zweitens, und das ist wichtig, fehlt im Container oft der Synchronisationsdaemon, und das ist normal – synchronisieren soll der Host. Das Problem entsteht, wenn der Host selbst nicht synchronisiert ist und Sie das nicht bemerken, weil Sie gewohnt sind, dass auf dem Entwickler-Notebook alles out of the box synchron ist.
Fehlender Synchronisationsdaemon
Die banalste und häufigste Ursache. Auf minimalen Server-Images kann der Zeitsynchronisationsdaemon nicht installiert oder nicht gestartet sein. Die Maschine startet, nimmt die Zeit aus der RTC und lebt dann mit einem driftenden Quarz ohne Korrektur. Tag für Tag summiert sich die Verschiebung.
Besonders gefährlich sind manuell gebaute oder geklonte Images. Der Ingenieur hat alles auf einer Referenzmaschine eingerichtet, ein Image erstellt, auf hundert Knoten ausgerollt – aber der Synchronisationsdaemon ist dort nicht aktiviert. Hundert Knoten beginnen, still jeder in seine eigene Richtung zu driften. Solange die Verschiebung klein ist, funktioniert alles. Nach einer Woche klettern die schnellsten Quarze aus dem Toleranzfenster, und Sie erhalten flackernde, nicht reproduzierbare Ausfälle auf einem Teil des Parks.
Manuelle Korrektur und hängengebliebene RTC
Manchmal zerbricht ein Mensch die Zeit. Jemand hat das Datum manuell für einen Test eingestellt und vergessen zurückzusetzen. Jemand hat die Synchronisation deaktiviert, weil sie ein konkretes Experiment störte. Ein separates Übel ist eine leere RTC-Batterie auf einem physischen Server: Nach dem Neustart fällt die Uhr in eine ferne Vergangenheit zurück, und bis zur ersten Synchronisation funktioniert TLS überhaupt nicht.
Doppelte Zeitverwaltung
Ein subtiler Fall, der oft vergessen wird. Manchmal kämpfen zwei Mechanismen gleichzeitig um die Zeit: der Gast-Agent des Hypervisors und der Synchronisationsdaemon im OS. Sie ziehen die Uhr in verschiedene Richtungen, und Sie erhalten Zeitschwankungen hin und her. Das manifestiert sich als intermittierende Ausfälle, die unmöglich zu fangen sind. Die Regel ist einfach: Für die Zeit soll genau ein Mechanismus verantwortlich sein.
Diagnose in einer Minute: Schnell zur Diagnose
Kommen wir zur Praxis. Ihr Ziel ist es, in sechzig Sekunden zu verstehen, ob die Zeit schuld ist. Hier ist ein schrittweises Framework, das wir bei Proxeon bei der Analyse von Vorfällen verwenden.
Schritt eins: Schauen Sie auf Ihre Zeit in UTC
Finden Sie zuerst heraus, was Ihre Uhr denkt, und zwar in UTC, um Verwirrung mit der Zeitzone auszuschließen:
date -uNotieren Sie den Wert. Vergleichen Sie nun mit der Referenz.
Schritt zwei: Mit externer Quelle vergleichen
Die zuverlässigste Methode ist, die Zeit bei einem Netzwerkzeitserver abzufragen und die Abweichung zu sehen. Wenn chrony installiert ist:
chronyc trackingSuchen Sie in der Ausgabe die Zeile System time – sie zeigt die Abweichung der Systemuhr relativ zur Referenz. Ein Wert wie 0.000030 seconds ist ideal. Bei systemd-timesyncd:
timedatectl show-timesync --all | grep -i offsetEin weiterer schneller Trick ist eine einmalige Abfrage beim Zeitserver ohne Änderung der Uhr:
chronyd -Q 'server pool.ntp.org iburst'Er druckt die vermutete Korrektur aus. Ist ihr Betrag groß – da haben Sie Ihre Antwort.
Schritt drei: Über den HTTP-Header Date prüfen
Eine Erkenntnis, die viel Zeit spart. Fast jeder Webserver gibt in der Antwort den Header Date mit der aktuellen Zeit in UTC zurück. Vergleichen Sie ihn direkt über Ihren Proxy mit Ihrer Uhr:
curl -sI -x http://user:pass@gateway.proxeon.net:8080 https://example.com | grep -i ^dateVergleichen Sie mit date -u. Wenn die Abweichung Sekunden beträgt – alles in Ordnung. Wenn Minuten – da ist Ihre Ursache. Der Charme der Methode: Sie erfordert keine installierten Daemons und funktioniert sogar in einem nackten Container, in dem nichts außer curl vorhanden ist.
Welche Streuung ist normal
Praktische Richtwerte aus Erfahrung:
- Bis 1 Sekunde – ausgezeichnet, nichts zu tun. Ein gesundes synchronisiertes System hält Bruchteile einer Sekunde.
- 1-5 Sekunden – akzeptabel für TLS und die meisten JWT, aber schon im Aufmerksamkeitsbereich. Request-Signaturen und TOTP halten noch, aber die Reserve schmilzt.
- 5-30 Sekunden – Alarm. TOTP beginnt zu scheitern, enge Signaturfenster sind gefährdet. Die Synchronisation funktioniert offensichtlich nicht richtig.
- Mehr als 30 Sekunden – kritisch. Signaturen, kurzlebige Token und bei großen Verschiebungen auch TLS fallen aus. Sofort beheben.
- Minuten und Stunden – Katastrophe, meist Folge von Einfrieren, Snapshot oder toter RTC-Batterie.
Goldene Regel: Wenn die Abweichung größer als fünf Sekunden ist, muss die Zeit als erster Verdächtiger bei allen TLS-, Token- und Signaturausfällen betrachtet werden.
Synchronisation einrichten: Damit sie wirklich funktioniert
Diagnostizieren reicht nicht – man muss heilen und Wiederholung verhindern. Betrachten wir zwei Hauptwerkzeuge in Linux und vor allem, wie man sicherstellt, dass die Synchronisation tatsächlich aktiv ist und nicht nur installiert. Das ist der entscheidende Unterschied, der übersehen wird.
systemd-timesyncd: die einfache Variante
Für die meisten Client-Maschinen und leichten Knoten reicht der in systemd integrierte Client. Er macht eine einfache Synchronisation über das Zeitprotokoll. Aktivierung:
timedatectl set-ntp truePrüfung, dass die Synchronisation wirklich läuft:
timedatectl statusSuchen Sie zwei Zeilen. System clock synchronized: yes bedeutet, dass das System sich als synchronisiert betrachtet. NTP service: active bedeutet, dass der Daemon läuft. Beide sollten positiv sein. Wenn synchronized: no bei active – der Daemon läuft, konnte sich aber noch nicht mit dem Server verbinden oder dieser ist nicht erreichbar.
Details zum konkreten Server:
timedatectl show-timesync --allHier sieht man, mit welchem Server verbunden wurde und welche Abweichung erhalten wurde. Genau dieser Befehl trennt wirklich funktionierende Synchronisation von dekorativer.
chrony: die ernsthafte Variante
Für Server, bei denen Robustheit wichtig ist, besonders für VMs mit Einfrierrisiko, ist chrony vorzuziehen. Er übersteht Zeitsprünge intelligenter und konvergiert schneller nach einem Leerlauf. Installation über den Paketmanager, dann Dienststart. Arbeitsprüfung – der Hauptbefehl:
chronyc trackingAnalyse der wichtigsten Ausgabezeilen:
- Reference ID – an welche Quelle gebunden. Steht dort 00000000 oder eine Zeile, dass keine Quelle ausgewählt ist, gibt es keine Synchronisation.
- Stratum – Ebene der Entfernung von den Referenzuhren. Normalerweise sieht man eine kleine Zahl.
- System time – aktuelle Abweichung der Systemuhr. Ihr Hauptindikator.
- Last offset und RMS offset – jüngste und gemittelte Korrekturen, zeigen die Stabilität.
Liste der Quellen und ihr Zustand:
chronyc sources -vEin Sternsymbol links vom Server bedeutet, dass genau er als aktive Quelle ausgewählt ist. Wenn keine Quelle ein Auswahlzeichen hat, ist der Daemon installiert, synchronisiert aber nicht – eine typische Falle.
Wie man installierte von funktionierender Synchronisation unterscheidet
Das ist die Erkenntnis, für die es sich lohnt, den Abschnitt zu lesen. Die Tatsache der Paketinstallation und selbst die Tatsache eines laufenden Dienstes garantieren keine Synchronisation. Der Dienst kann laufen und keinen Zugang zu Zeitservern haben – zum Beispiel schneidet eine Firewall ausgehende Pakete auf den nötigen Port ab, oder in einem geschlossenen Umfeld gibt es keinen internen Zeitserver.
Die echte Prüfung besteht aus drei Fragen. Erstens: Ist eine aktive Quelle ausgewählt? Schauen Sie auf die Markierung in sources oder die Reference ID in tracking. Zweitens: Wie groß ist die aktuelle Abweichung? System time sollte in Bruchteilen einer Sekunde liegen. Drittens: Aktualisiert sie sich? Führen Sie die Prüfung zweimal mit Abstand aus und stellen Sie sicher, dass die Zahlen lebendig sind und nicht erstarrt. Sind alle drei Antworten positiv – funktioniert die Synchronisation tatsächlich.
Überwachung der Abweichung als Metrik
Der professionelle Ansatz ist, nicht auf den Vorfall zu warten, sondern die Abweichung ständig zu überwachen. Geben Sie den Wert System time als gewöhnliche Metrik in Ihr Monitoring-System aus. Richten Sie eine Warnung bei Überschreitung von beispielsweise zwei Sekunden und einen Alarm bei fünf ein. Dann erfahren Sie von dem Problem, bevor Signaturen und Token zusammenbrechen. Die Kosten solcher Überwachung sind nahe null, und der Nutzen ist enorm: Ein verhinderter nächtlicher Vorfall rechtfertigt alles.
Container und Uhren: Was wird geerbt und was nicht
Containerisierung verdient eine separate tiefe Betrachtung, weil hier die Ingenieure die meisten Missverständnisse haben. Sortieren wir genau, was der Container vom Host erhält und was nicht.
Was geerbt wird: die Zeit selbst
Eine Schlüsseltatsache: Der Container teilt den Kernel des Hosts und damit die Systemuhr. Im Container zeigt date -u genau dieselbe absolute Zeit wie auf dem Host. Einen separaten Zeitzähler hat der Container nicht. Das ist fundamental. Daraus folgt die Hauptschlussfolgerung: Damit der Container die richtige Zeit sieht, muss der Host synchronisiert werden, nicht der Versuch, die Synchronisation im Container einzurichten.
Was nicht geerbt wird: die Zeitzone
Die Anzeige der Zeit ist eine andere Sache. Die Zeitzone wird durch Einstellungen im Container bestimmt, üblicherweise durch eine Zonendatei und eine Umgebungsvariable. Das Basis-Image kommt oft mit UTC, und das ist übrigens eine gute Praxis für Server. Wenn die lokale Zeit im Container anders aussieht als auf dem Host – ist das fast immer ein Zeitzonenunterschied, nicht der echten Zeit. Prüfen Sie den Absolutwert über UTC, bevor Sie in Panik geraten.
Warum man keinen Zeitdaemon im Container starten sollte
Ein verbreiteter Anfängerfehler ist, einen Synchronisationsdaemon in den Container zu stecken. Das ist aus zwei Gründen falsch. Erstens ist die Änderung der Systemzeit eine privilegierte Operation, die den gesamten Kernel und damit alle Container auf dem Host und den Host selbst betrifft. Standardmäßig ist das dem Container verboten, und das ist gut. Dieses Privileg für die Synchronisation zu geben bedeutet, eine Lücke zu öffnen und einen Konflikt zu schaffen.
Zweitens ist es einfach unnötig: Die Zeit kommt bereits vom Host. Die richtige Architektur ist ein synchronisierter Host, viele Container, die automatisch die richtige Zeit sehen. Wenn Sie einen Orchestrator mit vielen Knoten haben, muss die Synchronisation auf jedem Knoten-Host gewährleistet werden, nicht in jedem Pod.
Die Falle des Entwickler-Notebooks
Separat warnen wir vor einer heimtückischen Situation. Auf dem Entwickler-Notebook funktioniert alles: Container sehen die richtige Zeit, weil das Betriebssystem der Workstation out of the box synchronisiert ist. Der Ingenieur baut ein Image, alles grün. Das Image geht auf einen Server, wo der Host nicht synchronisiert ist – und dort beginnen die Ausfälle. Lektion: Testen Sie das Verhalten bei falsch gestellter Zeit, nicht nur bei idealer. Verschieben Sie bewusst die Zeit in der Testumgebung und schauen Sie, wie die Anwendung reagiert.
Zeitprüfung im laufenden Container
Ein schneller Befehl, um in einen laufenden Container zu schauen und seine absolute Zeit zu prüfen:
docker exec -it my_container date -uWenn sie mit date -u auf dem Host übereinstimmt – alles in Ordnung, suchen Sie das Problem woanders. Wenn der Container auf irgendeine Weise eine andere absolute Zeit zeigt, ist das ein Signal für eine ungewöhnliche, potenziell gefährliche Konfiguration, die sofort überprüft werden sollte.
Typische Fehler: Was man nicht tun sollte
Die Erfahrung aus der Vorfallanalyse verdichtet sich zu einer Liste von Harken, in die man immer wieder tritt. Gehen wir sie durch, damit Sie sie umgehen.
Fehler eins: Den Proxy aus Reflex beschuldigen
Wir haben damit begonnen und wiederholen es. Das Wort certificate oder signature in der Fehlermeldung bei Arbeit über einen Proxy weckt automatisch Verdacht gegen Netzwerk und Gateway. Lassen Sie sich nicht verleiten. Die erste Aktion bei diesen Fehlern ist, die Zeit zu prüfen, nicht den Endpunkt zu wechseln. Das kostet zehn Sekunden und schneidet die häufigste verborgene Ursache ab.
Fehler zwei: Die Zeitzone statt der Zeit reparieren
Der Ingenieur sieht eine seltsame lokale Zeit im Log und stellt die Zeitzone um. Das Symptom im Log ändert sich, aber die Kryptografie fällt weiterhin aus, weil die reale absolute Zeit in UTC falsch geblieben ist. Diagnostizieren Sie immer über date -u und den Vergleich mit der Referenz, nicht über die lokale Anzeige.
Fehler drei: Die Installation der Synchronisation als Lösung betrachten
Paket installiert, gesehen, dass der Dienst läuft, Aufgabe geschlossen. Eine Woche später wieder Ausfälle, weil der Dienst keinen Zugang zu Zeitservern hatte. Installation ist nicht gleich Synchronisation. Prüfen Sie immer die tatsächliche Abweichung und die Existenz einer ausgewählten Quelle.
Fehler vier: Uhren im laufenden Betrieb hart korrigieren
Ein plötzlicher Sprung der Systemzeit durch einen direkten Setzbefehl kann laufende Prozesse brechen, die auf die Monotonie der Zeit vertrauen: Timeouts laufen ab, Sitzungen reißen, falsche Scheduler-Auslösungen treten auf. Richtig ist, den Synchronisationsdaemon die Uhr sanft nachführen zu lassen. Eine harte Korrektur ist nur bei einer enormen einmaligen Verschiebung akzeptabel, und dann bewusst.
Fehler fünf: Das Einfrieren von VMs ignorieren
Das Team berücksichtigt nicht, dass Migrationen, Snapshots und Pausen einmalige Verschiebungen erzeugen. Für solche Umgebungen braucht man einen Daemon, der gegen Sprünge robust ist, und eine Überwachung der Abweichung nach Wartungsarbeiten. Wenn Ihre Ausfälle zeitlich mit Backups oder Migrationen korrelieren – da haben Sie Ihre Auflösung.
Fehler sechs: Doppelte Zeitverwaltung
Gleichzeitig arbeiten der Gast-Agent des Hypervisors und ein interner Daemon. Die Uhr zuckt, Ausfälle sind intermittierend und nicht reproduzierbar. Wählen Sie einen Mechanismus und deaktivieren Sie den zweiten. Das heilt die zermürbendsten flackernden Bugs.
Fehler sieben: Zu enge Fenster ohne Reserve
Wenn Sie eine API mit Request-Signatur entwickeln, machen Sie das Toleranzfenster nicht dreißig Sekunden ohne triftigen Grund. Eine vernünftige Reserve von einigen Minuten senkt die Empfindlichkeit gegenüber kleiner Desynchronisation der Clients drastisch, ohne den Replay-Schutz zu opfern. Die Balance zwischen Strenge und Robustheit ist eine Ingenieursentscheidung, kein Dogma.
Werkzeuge und Ressourcen
Stellen wir das Arsenal zusammen, das man zur Hand haben sollte. Alle Werkzeuge sind Standard und legal, für den normalen Ingenieurbetrieb.
Kommandozeile
- date -u – der sofortige Blick auf die absolute Zeit. Der erste Befehl bei jedem Verdacht.
- timedatectl – Synchronisations- und Zeitzonenstatus in systemd-Systemen.
- chronyc tracking und chronyc sources – tiefe chrony-Diagnose: Abweichung, Quellen, Stabilität.
- curl -sI ... | grep -i date – Zeitabgleich über den HTTP-Antwortheader, funktioniert sogar dort, wo es keine Daemons gibt. Ideal für nackte Container und Prüfung über das Gateway.
Sprachspezifische Prüfungen
- In Python: eine Zeile mit utcnow-Ausgabe und Timestamp zum Abgleich direkt aus der Laufzeitumgebung der Anwendung.
- In Node: eine Zeile mit toISOString und Date.now, um die Zeit mit den Augen Ihrer Runtime zu sehen.
- JWT ohne Signaturprüfung dekodieren, um mit eigenen Augen die Felder exp, nbf, iat zu sehen und sie mit der aktuellen Zeit zu vergleichen. Das beseitigt Vermutungen: Sie sehen buchstäblich, ob der Token nach Ihrer Uhr abgelaufen ist oder nicht.
Was man ständig überwachen sollte
- Abweichung der Systemuhr als numerische Metrik mit Warn- und Alarmschwellen.
- Status der Existenz einer ausgewählten Zeitquelle – ein boolescher Gesundheitsindikator der Synchronisation.
- Häufigkeit von TLS- und Token-Fehlern aufgeschlüsselt nach Knoten – ein Anstieg auf einem bestimmten Knoten deutet oft genau auf dessen falsch gestellte Uhr hin.
Proxeon-Infrastruktur
Bei der Arbeit über Proxeon-Gateways empfehlen wir, eine Zeitprüfung in das Startskript Ihrer Arbeitsknoten einzubauen. Eine Zeile Abgleich des Date-Headers über das Gateway beim Start – und Sie fangen die Desynchronisation vor der ersten Arbeitsanfrage ab. Das ist günstig und senkt den Anteil falscher Support-Anfragen drastisch, bei denen die Ursache in der Uhr der Client-Seite liegt und nicht im Proxy.
Fälle und Ergebnisse
Theorie erwacht in echten Geschichten. Führen wir verallgemeinerte Fälle aus der Praxis an – Zahlen gerundet, Details anonymisiert, aber die Muster absolut real.
Fall eins: Nächtlicher Parser-Kollaps nach dem Backup
Das Team sammelte rund um die Uhr Daten über einen Proxy. Jede Nacht gegen drei Uhr begann eine Wand von Fehlern certificate is not yet valid, bis zum Morgen heilte alles von selbst. Die Ingenieure beschuldigten zwei Wochen lang den Proxy-Pool, tauschten Endpunkte aus, schrieben Beschwerden. Die Auflösung kam, als jemand die Korrelation bemerkte: Die Ausfälle begannen genau während der nächtlichen Backup-Erstellung der VMs.
Der Hypervisor fror die VM für anderthalb bis zwei Minuten ein, um einen konsistenten Snapshot zu erstellen. Nach dem Auftauen ging die Uhr um diese Minuten nach, und der Gast-Agent führte sie nicht sofort nach. Im Fenster zwischen Auftauen und Korrektur lehnte TLS frische Zertifikate als noch nicht gültig ab – weil sie nach der zurückgefallenen Uhr in der Zukunft zu gelten begannen. Die Lösung war der Wechsel zu chrony mit schneller Konvergenz nach dem Sprung und die Überwachung der Abweichung direkt nach Backup-Operationen. Die nächtlichen Ausfälle verschwanden vollständig, die Diagnosezeit zukünftiger ähnlicher Probleme sank von Tagen auf Minuten.
Fall zwei: Hundert Knoten, die auseinanderdriften
Eine Organisation rollte einen Park von hundert Arbeitsknoten aus einem Image aus. Die erste Woche funktionierte alles. Dann begannen flackernde Signaturausfälle bei Anfragen auf zufälligen Knoten – request timestamp too skewed. Nicht reproduzierbar: Startet man die Aufgabe neu, kann sie auf einem anderen Knoten durchlaufen.
Die Ursache – im Image war die Zeitsynchronisation nicht aktiviert. Hundert Knoten drifteten jeder nach seinem eigenen Quarz. Die schnellsten waren nach einer Woche aus dem Signatur-Toleranzfenster gelaufen. Eine Massenprüfung von chronyc tracking über den gesamten Park zeigte Abweichungen von Bruchteilen einer Sekunde bis zu fünfzehn Sekunden. Nach Aktivierung und Prüfung der tatsächlichen Synchronisation auf allen Knoten plus Hinzufügen der Abweichungsmetrik zum Monitoring hörten die Ausfälle auf. Fazit des Teams: Beim Massen-Rollout nicht die Tatsache der Installation prüfen, sondern die Tatsache der Synchronisation.
Fall drei: Der Entwickler, den niemand verstand
Ein Ingenieur beklagte, dass bei ihm lokal die TOTP-Autorisierung im Verwaltungspanel nicht durchläuft, obwohl sie bei allen funktioniert. Er gibt den richtigen Code ein, das System lehnt ab. Man vermutete Probleme mit seinem Konto.
Es stellte sich heraus, dass er vor einer Woche die Systemzeit auf seiner Workstation für einen Test einer anderen Anwendung manuell verschoben und vergessen hatte zurückzusetzen, und dabei die Synchronisation deaktiviert hatte. Die Uhr war fast eine Minute verschoben. TOTP mit einem Fenster von dreißig Sekunden stimmte nicht mehr überein. Das Aktivieren der automatischen Synchronisation reparierte sofort alles. Moral: Die enge TOTP-Toleranz ist ein eingebauter Detektor für Desynchronisation. Wenn Codes nicht übereinstimmen, schauen Sie zuerst auf die Uhr.
Fall vier: Container mit fremder Zeitzone
In den Logs der Anwendung im Container lief die Zeit mit einer Dreistundenverschiebung relativ zum Host. Die Ingenieure dachten, die Uhr des Containers sei falsch, und verbrachten einen Tag mit Versuchen, die Synchronisation darin einzurichten, wobei sie dem Container fast überflüssige Privilegien gewährt hätten.
Die Prüfung von date -u innerhalb und außerhalb zeigte dieselbe absolute Zeit. Die Verschiebung war rein in der Anzeige: Das Basis-Image hatte eine Zeitzone, der Host eine andere. Die Kryptografie funktionierte dabei einwandfrei, weil in UTC alles übereinstimmte. Es gab überhaupt kein echtes Problem – nur kosmetische Verwirrung in den Logs. Die Lektion kostete einen Arbeitstag: Unterscheiden Sie immer absolute Zeit und ihre Anzeige.
FAQ: Tiefe Antworten auf häufige Fragen
Kann der Proxy selbst meine Zeit verstellen oder sie in TLS ersetzen?
In Standardszenarien der Arbeit über ein Gateway – nein. Der Proxy überträgt Bytes zwischen Ihnen und dem Zielserver. Die Prüfung des Zertifikatsablaufs, der Felder exp und nbf, des Signaturfensters geschieht auf Ihrer Seite oder auf der Seite des Zielservers, gestützt auf deren eigene Uhren. Daher muss man bei zeitlich anmutenden Fehlern zuerst die lokale Uhr des Arbeitsknotens verdächtigen, nicht das Gateway. Der Proxy verlängert nur die Kette und verschiebt psychologisch den Verdacht zur Mitte.
Wie genau muss die Zeit laufen, damit alles funktioniert?
Für TLS ist die Reserve meist groß – dort werden die Gültigkeitsfenster von Zertifikaten in Tagen gemessen, und selbst eine Minutenverschiebung passiert meist unbemerkt, außer an der Erneuerungsgrenze. Für JWT hängt alles von der Lebensdauer des Tokens ab: Bei kurzen Token spielen schon Sekunden eine Rolle. Für Request-Signaturen ist das typische Fenster Minuten, aber besser hält man die Abweichung innerhalb einer Sekunde. TOTP ist am anspruchsvollsten – Dutzende Sekunden. Universelle Empfehlung: Halten Sie die Abweichung innerhalb einer Sekunde, dann sind Sie gegen alle genannten Mechanismen gleichzeitig abgesichert.
Warum zeigt das Zertifikat gültige Daten, aber der Client sagt, es sei noch nicht gültig?
Weil der Client die Zertifikatsdaten nicht mit absoluter Wahrheit vergleicht, sondern mit Ihrer lokalen Uhr. Wenn Ihre Uhr nachgeht und einen Moment vor dem Feld notBefore anzeigt, ist das Zertifikat für den Client noch nicht eingetreten. Die Daten im Zertifikat selbst sind dabei ideal. Die Auflösung liegt immer im Abgleich Ihres date -u mit der Referenz. Das ist die häufigste Quelle des Stockens bei Ingenieuren.
Muss man einen Synchronisationsdaemon im Container installieren?
Nein. Der Container nutzt die Uhr des Host-Kernels, daher muss der Host synchronisiert werden. Die Installation eines Daemons im Container ist nutzlos und erfordert gefährliche Privilegien zur Änderung der Systemzeit, die den gesamten Host betreffen. Das richtige Modell ist ein synchronisierter Host und viele Container, die automatisch die richtige Zeit sehen. Im Orchestrator gewährleistet man die Synchronisation auf jedem Knoten-Host.
Wie unterscheidet man ein Zeitproblem von einem echten Proxy- oder Netzwerkproblem?
Beginnen Sie mit der Zeitprüfung – das sind zehn Sekunden. Vergleichen Sie date -u mit der Referenz und mit dem HTTP-Header Date über Ihr Gateway. Wenn die Abweichung klein ist und TLS- und Token-Fehler bleiben – gehen Sie zur Netzwerkdiagnose über. Wenn die Abweichung groß ist – haben Sie die Ursache gefunden. Das Schlüsselmerkmal zeitlicher Probleme: Die Fehler enthalten die Wörter not yet valid, expired, skewed, signature bei offensichtlich lebendigen Zertifikaten und frischen Token.
Was tun unmittelbar nach dem Auftauen oder der Migration einer VM?
Stellen Sie sicher, dass der Synchronisationsdaemon die Uhr schnell nachgeführt hat. Für Umgebungen mit Einfrieren ist chrony vorzuziehen, der Sprünge gut übersteht. Prüfen Sie chronyc tracking und stellen Sie sicher, dass System time in Bruchteile einer Sekunde zurückgekehrt ist. Gute Praxis ist, nach Wartungsarbeiten die Abweichungsprüfung erzwungen auszulösen und keine kritischen signierten Anfragen zu starten, bis die Uhr konvergiert ist.
Beeinflusst eine falsche Zeitzone die Arbeit von TLS und Token?
Nein, vorausgesetzt, die absolute Zeit in UTC ist korrekt. Die gesamte Kryptografie operiert in UTC, und die Zeitzone ist nur die Anzeige für den Menschen. Eine falsche Zeitzone verwirrt Sie in den Logs, bringt aber TLS, JWT oder Signatur nicht zum Absturz. Genau deshalb muss man über UTC diagnostizieren, nicht über die lokale Zeit. Die Verwechslung von Zeitzone und absoluter Zeit ist eine klassische Falle.
Wie baut man die Zeitprüfung in den Arbeitsablauf über den Proxy ein?
Fügen Sie in das Startskript des Knotens eine Abgleichszeile ein: Fragen Sie den Date-Header über Ihr Proxeon-Gateway ab und vergleichen Sie ihn mit dem lokalen date -u. Bei einer Abweichung über dem Schwellenwert stoppen Sie den Start und lösen einen Alarm aus. Plus: Geben Sie die Systemuhrabweichung als ständige Metrik mit Schwellen in das Monitoring aus. Diese zwei Maßnahmen fangen die überwiegende Mehrheit zeitlicher Vorfälle ab, bevor sie zu TLS- und Token-Ausfällen werden.
Warum erhalte ich
