9137c07c95
Auf utm-2 war das Zertifikat der Management-UI seit dem 28.08. abgelaufen (entdeckt am 11.09.) und haette sich aus eigener Kraft nie wieder erneuert. Zwei Ursachen trafen zusammen: 1) Das FQDN eines per Join dazugekommenen Nodes landet in KEINER tls_certs-Zeile — es wird beim Setup einmalig ausgestellt und danach von niemandem mehr angefasst. certrenewer arbeitet nur die Tabelle ab und sieht es deshalb nie. (utm-1 steht dort drin, weil sein FQDN beim Erst-Setup regulaer als Domain angelegt wurde — deshalb fiel es dort nicht auf.) 2) Der Scheduler blockt auf einem Nicht-VIP-Master jede ACME-Erneuerung (v1.3.20). Fuer geteilte Domains ist das richtig: die zeigen per DNS auf die VIP, nur der Master kann die Challenge bestehen. Fuer das eigene Management-FQDN stimmt es nicht — utm-2.netcell-it.de zeigt auf 89.163.205.8, die eigene IP des Nodes, und Port 80 antwortet dort. Neu: runManagementCertRenew laeuft auf JEDEM Node unabhaengig von der VIP, aber ausschliesslich fuer das eigene FQDN aus setup.json. Prueft die Restlaufzeit der Datei unter /etc/edgeguard/tls und erneuert ab 30 Tagen Rest (gleicher Schwellwert wie bei den Domain-Certs). Bewusst NICHT ueber tls_certs: das ist eine replizierte Shared-Table, und cluster-reconcile-replication TRUNCATEt solche Tabellen beim Refresh — eine lokal auf dem Subscriber eingefuegte Zeile waere beim naechsten Paket-Upgrade wieder weg. Das Management-Zertifikat ist node-lokale Infrastruktur und wird wie die cluster-tls-Certs als reine Datei behandelt. Existiert dagegen bereits eine tls_certs-Zeile fuer das eigene FQDN (Fall utm-1), bleibt alles beim Alten und certrenewer behaelt die Zustaendigkeit — sonst haetten zwei Mechanismen dieselbe Datei. Tests decken die Schwellwert-Entscheidung ab, inklusive des utm-2-Falls (bereits abgelaufen) und kaputter PEM-Dateien. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3.6 KiB
3.6 KiB