Heute, am Pfingstmontag, wollte ich ein paar Stunden Arbeit nachholen, die ich am Freitag nicht mehr geschafft habe. Was man halt so macht, an einem wunderbar sonnigen Feiertag.

Da sich Feiertage anbieten, um kritische Software-Updates durchzuführen, denn sonst arbeitet ja keiner, loggte ich mich erstmal auf dem entsprechenden Server ein und updatete unsere GitLab-Installation. Im Normalfall läuft das immer völlig problemlos durch und erfordert kein manuelles Eingreifen.

Während das Update noch läuft, wechsel ich zu Tower und versuche mal den aktuellsten Stand eines Branches zu ziehen und bekomme direkt einen Fehler. Toll.

SSL certificate problem: certificate has expired

Nagut, denke ich mir, hab ich es also geschafft. Schön am Feiertag das GitLab kaputt gemacht, wenn ich eigentlich nur mal eben zwei Stündchen hochproduktiv meine offenen Tickets vom Freitag abarbeiten will!

Also los ans Debugging. Das SSL-Zertifikat läuft noch bis 2021, das kann es also nicht sein. GitLab läuft auch hinter einem nginx-Proxy, der das SSL übernimmt, in der VM kommt eigentlich alles per HTTP an. Kann also eigentlich auch gar nicht daran liegen. Extremes googeln liefert mir leider keine Ergebnisse, ich gehe also grob die Changes in GitLab 13 durch. Der Standard-Webserver wurde von unicorn zu puma gewechselt, aha! Also mal umgestellt, kein Erfolg.

Zusätzlich verwirrte mich, dass die Seite im Browser perfekt funktioniert, curl aber zum Beispiel auch wegen dem Zertifikat meckert.

Ich arbeite mich weiter in die Architektur ein. gitlab-workhorse ist für die Git-Kommunikation verantwortlich! Ich durchsuche die Logs und finde nichts.

Weiterhin bin ich der Meinung, dass das Update verantwortlich ist, auch wenn mir das sehr spanisch vorkommt. Wie soll GitLab, hinter dem Proxy, das Zertifikat verändern können, das ist zu dem Zeitpunkt der Verbindung doch noch gar nicht am Zug.

Leider liefert curl auch mit sehr vielen -vvvvv keine bessere Fehlermeldung. Ich installiere aus Spaß mal Wireshark, um zu schauen, welches Zertifikat da jetzt über die Leitung geht. Zum Glück weiß ich sogar noch, wie man es bedient! Leider hilft es auch nicht. Das Zertifikat ist das normale, haltbar bis 2021.

Immerhin hake ich erstmal GitLab als verantwortliches System ab, da es ja gar nicht sein kann und Google noch weiter, ohne „GitLab“ in den Keywords, und siehe da: ein helfender Stack Overflow-Post!

Turns out, wenn man eine Zertifikat-Chain mit mehreren Intermediates hat, dann müssten alle noch gültig ein. Leuchtet natürlich ein, aber warum sagt einem das die Fehlermeldung nicht? Schade!

Ein paar SSL-Incantations später weiß ich auch woran es liegt, zusätzlich finde ich diese hilfreiche Webseite, die checkt, ob man was in der Chain hat, was gammelt.

Jedenfalls: am 30. Mai, also am Samstag, ist ein Sectigo Root-Zertifikat expired, was bei uns in der Kette war. Moderne Browser kümmert das nicht weiter, aber Tools wie curl und git sind da leider sehr penibel und failen mit einer nicht sehr hilfreichen Fehlermeldung.

Also, Chain geupdated, neu gestartet, alles geht wieder. Puh. Anderthalb Stunden rum, nichts geschafft, aber immerhin was gelernt!

Dieser Post erläutert die Geschichte etwas professioneller als ich das je könnte.

---

Im Nachhinein Ärger ich mich, das ich soviel Zeit damit verschwendet habe, den Fehler bei GitLab zu suchen, aber nachher ist man ja immer schlauer. Mir war zwar die ganze Zeit klar, dass das gar nicht sein kann, aber ich hatte ja gerade das Update gemacht! Und wäre nicht das erste Mal gewesen, dass etwas gar nicht sein kann und trotzdem ist.

Insgesamt frage ich mich allerdings auch, warum Namecheap, die uns das Zertifikat verkauften, da keine E-Mail schrieb, denn die Expiration wat ja schon länger bekannt. Des Weiteren habe ich auch bei Hacker News dazu nix gelesen in den letzten Wochen. Kurios.