api-ssl auf mt-az lieferte nur das Blattzertifikat aus. Gegen die famfi-Root-CA
allein scheiterte die Pruefung deshalb mit "unable to get local issuer
certificate" - jeder strenge TLS-Client braucht die Zwischen-CA separat
zugesteckt. Der CrowdSec-Bouncer funktionierte nur, weil er mit
famfi-ca-bundle.pem (Root + Intermediate) konfiguriert ist.
Ursache war nicht das Skript, sondern der Zertifikatsspeicher des Routers: die
Zwischen-CA lag dort gar nicht. RouterOS verknuepft Blatt und CA beim IMPORT des
Blattes (Feld ca=), und ohne die CA im Speicher entsteht diese Verknuepfung nicht.
Nachtraeglich laesst sie sich auch nicht setzen - "bad parameter ca".
Behoben in zwei Schritten: die Zwischen-CA als famfi-int-ca-20261022.crt_0
importiert, danach ein --force-Renew, damit RouterOS das neue Blatt mit ihr
verknuepft. api-ssl liefert jetzt Blatt + Zwischen-CA, und die Pruefung gegen die
Root allein gibt "Verify return code: 0 (ok)".
Das Skript selbst brauchte dafuer keine Aenderung - es schreibt weiterhin nur
d["certificate"]. Es funktioniert aber nur, SOLANGE die Zwischen-CA im Speicher
liegt. Darum hier ergaenzt:
- Hinweis im Kopf auf diese Abhaengigkeit.
- Kettenpruefung am Ende: nach dem Austausch wird gegen $ROOT_CA verifiziert.
Bewusst nur eine Warnung, kein die() - das Zertifikat waere ja in Ordnung, die
fehlende Kette ist ein Mangel, kein Ausfall. Ein Abbruch wuerde einen
erfolgreichen Austausch als Fehlschlag melden.
Die Pruefung laeuft nur bei einer tatsaechlichen Erneuerung, nicht beim taeglichen
Leerlauf - also genau dann, wenn die Verknuepfung verloren gehen koennte. Die Zeit
dazwischen deckt die Blackbox-Probe ab: deren Modul tcp_tls_famfi zeigt seit heute
auf die Root-CA allein, scheitert also, wenn die Kette je wieder wegfaellt.
Nachgewiesen: Bouncer nach dem Zertifikatswechsel neu gestartet, frischer
TLS-Handshake ohne x509-Fehler, arbeitet Entscheidungen ab; 16145 Eintraege in der
Router-Sperrliste, 82591 verworfene Pakete.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Das API-SSL-Zertifikat von mt-az.famfi.home (CN=mt-az.famfi.home, ausgestellt
von famfi.home Intermediate CA, 90 Tage) lief am 2026-09-26 ab. Folge: der
Container crowdsec-mikrotik-bouncer starb im Minutentakt mit
"x509: certificate has expired" - 967 Neustarts, letzter erfolgreicher
API-Pull 2026-09-27 02:29. Zehn Tage lang wurden CrowdSec-Sperren also nur
noch von Traefik durchgesetzt und nicht mehr in die Router-Firewall
geschoben.
Die eigentliche Ursache war nicht das Zertifikat, sondern dass niemand
hinsah: fuer openbao und gitea gibt es Erneuerungsskripte samt Timer (daher
sind die mit 58 bzw. 73 Tagen in Ordnung), fuer den Router gab es keins. Und
die Regeln TLSCertificateExpiringSoon/-Critical haengen am blackbox_exporter,
der nur openbao.famfi.home und www_mahle_com prueft - mt-az:8729 steht in
keiner Probe.
renew-mikrotik-cert.sh ist die Kopie von renew-gitea-cert.sh mit dem
Router-spezifischen Installationsschritt: Zertifikat und Schluessel per scp
hochladen, zweimal /certificate import mit leerem passphrase (RouterOS
protokolliert Kommandos mit, deshalb darf dort nichts Geheimes stehen),
api-ssl umschalten, hochgeladene Dateien entfernen und das alte Objekt erst
danach loeschen. Der Name traegt einen Datumsstempel, weil RouterOS den
Zertifikatsnamen vom Dateinamen ableitet und es sonst Kollisionen gibt.
Das Router-Passwort holt das Skript zur Laufzeit aus OpenBAO, damit es
nirgends auf Platte und in keiner Kommandozeile liegt. Die Policy cert-renew
bekommt dafuer read auf genau secret/data/mikrotik/MT-AZ/apics, nicht auf
secret/mikrotik/*.
Zwei Fehler des ersten Laufs sind behoben: die Namensauslese benutzte einen
gierigen Regex ".*name=", der in der terse-Ausgabe das spaetere
subject-alt-name= traf und "DNS:mt-az.famfi.home" zurueckgab; jetzt wird
feldweise zerlegt. Und /ip service set spricht den Dienst direkt beim Namen
an statt ueber [find ...], das auch den dynamischen Verbindungseintrag
erfasste und eine irritierende Meldung ueber telnet quittierte. Am Ende
prueft das Skript, dass api-ssl wirklich ein gueltiges Zertifikat ausliefert.
Ergebnis: neues Zertifikat gueltig bis 2027-01-04, der Bouncer laeuft und
arbeitet den Rueckstand ab ("Address ... blocked in mikrotik"). Die
IP-Dienste des Routers sind unveraendert, telnet/ftp/www-ssl bleiben
deaktiviert. Timer taeglich mit 21-Tage-Fenster, wie bei den anderen beiden.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
