Lets Encrypt SSL-Zertifikate des Administrators werden ungültig angezeigt

    Hallo,


    das Problem sind manche Zertifikate, die von LiveConfig angelegt werden.


    Mal in den Ordner "/etc/ssl/certs" wechseln und dort "ls -la | grep 'ca.crt' | grep '\->'" ausführen. Es sollten dann Verlinkungen sichtbar werden, die man löschen muss. Danach funktioniert das mit Let's Encrypt Zertifikaten wieder.


    Problem ist die Updateroutine von ca-certificates. Hier werden Hashwerte erstellt und zu den Zertifitkaten verlinkt. Wenn dabei ein Zwischenzertifikat von LE enthalten ist, dann wird die Validierung mit diesem vorgenommen und nicht gegen ca-certificates.crt. So weit für mich ersichtlich, handelt es sich dabei um ältere Dateien, da die Zeitstempel teilweise aus 2020 sind. Aber genaue Ursache suche ich noch selbst.

    Zitat von Marco


    Mal in den Ordner "/etc/ssl/certs" wechseln und dort "ls -la | grep 'ca.crt' | grep '\->'" ausführen. Es sollten dann Verlinkungen sichtbar werden, die man löschen muss. Danach funktioniert das mit Let's Encrypt Zertifikaten wieder.


    Stimmt! Ich habe mir die Deltas zwischen den Servern angeschaut und alle problematischen Server hatten als xxxxxx.0 folgendes Zertifikat enthalten:


    Let's Encypt X3

    Code
    -----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTE2MDMxNzE2NDA0NloXDTIxMDMxNzE2NDA0Nlow
....


    Sobald diese Verlinkung gelöscht wird, nutz zumindest CURL wieder die korrekte Kette.
    Ich vermute das ist ein "Feature", dass hier nicht die komplette Kette abgearbeitet, sondern nur der erste Pfad und dann mit einem Fehler abgebrochen wird.


    OpenSSL streikt aber weiterhin noch.

    Nach Abgleich auf mehreren Systemen (die meisten aktueller Stand) konnten zwei Ursachen für das Problem festgestellt werden. Vielleicht kann KK auch etwas dazu sagen.


    1. ehemalige Zertifikate von mittlerweile gelöschten Kunden


    Hier wurden Zertifikate über LE beantragt, die zum damaligen Zeitpunkt auch gültig waren. Als Aussteller dieser Zertifikate ist noch X3 eingetragen, was zur damaligen Zeit auch gültig war. Das zugehörige Zwischenzertifikat ist aber nun abgelaufen und nicht mehr gültig. Beim Löschen der Kunden wurden die zugehörigen Zertifikate aber nicht gelöscht und blieben als "Karteileiche" unter "/etc/ssl/certs" liegen.



    2. aktive Kunden


    2.1. aktiver Kunde, aber Vertrag aktuell gesperrt


    Hier gilt das vorher geschriebene. Kunde hatte ein gültiges Zertifikat, welches X3 als Aussteller hat. Das zugehörige Zwischenzertifikat ist aber mittlerweile abgelaufen und wird in der Übersicht bei LiveConfig unter Details als abgelaufen ausgewiesen. Da durch die Sperre keine Verlängerung stattfindet, bleiben diese alten Zertifikate im System hängen.


    2.2 aktiver Kunde mit älteren Verträgen


    Hier wurden die Zertifikate zu einem Zeitpunkt beantragt, als das alte Zwischenzertifikat noch gültig und der neue Aussteller noch nicht aktiv war. Nach und nach wurden solche Zertifikate aktualisiert und das neue gültige Zwischenzertifikat abgelegt. Das alte Zwischenzertifikat verbleibt aber im System gespeichert.




    Ursache allen Übels ist (unter Debian) die Funktion von "update-ca-certificates". Diese wird bei einer Aktualisierung des Paketes "ca-certificates" ausgeführt und erstellt unter "/etc/ssl/certs" Verlinkungen zu Zertifikaten her. Die Verlinkung trägt dabei den Namen HASHWERT.0, wobei bei Zwischenzertifikaten das .0 als .1, .2 usw. fortgeführt wird, wenn ein Zwischenzertifikat aktualisiert wird (Beispielsweise von Aussteller X3 auf R3).


    Bei neueren Zertifikaten ist dies alles kein Problem, da "update-ca-certificates" diese ignoriert, da mehrere Blöcke bzw. auch DH-Parameter in den Zertifikatsdateien vorhanden sind. In den alten Zertifikaten ist jedoch nur ein Block enthalten, daher werden diese Dateien gehasht. Zusätzliches Problem ist die Fortführung der Zertifikatskette. Dies sorgt auch dafür, dass alte abgelaufene Zwischenzertifikate im System verankert bleiben.


    Wenn nun eine Funktion ein LE Zertifikat einer Gegenstelle verifizieren möchte, dann wird (unter Debian) in dem Ordner "/etc/ssl/certs" nach einem passenden Zwischenzertifikat gesucht. Existieren nun solche "Karteileichen" auf dem System, dann wird die Verifizierung gegen das abgelaufene Zertifikat vorgenommen und ein gültiges Zwischenzertifikat oder die Datei "ca-certificates.crt" wird ignoriert. Mit den bekannten Folgen, dass der Verbindungsaufbau dann abgelehnt wird.



    Mögliche Problemlösungen, ohne Wertung der Sinnhaftigkeit


    1. Skripte anpassen und die Verifizierung abstellen. Damit hebelt man die Sicherheit aus, die man eigentlich damit erreichen möchte. Und je nach Anzahl der betroffenen Seiten ein mühseliges Unterfangen.


    2. Anpassung der php.ini. Unter LiveConfig den Schlüssel "openssl.cafile" ergänzen, dort den Wert "/etc/ssl/certs/ca-certificates.crt" eintragen und dann die Anpassung für die Verträge übernehmen lassen. Der Wert überschreibt damit die Systemeinstellung und zumindest PHP Skripte funktionieren wieder. Hilft aber nicht bei anderen Skriptarten. Hinweis: Evtl. auch bei der systemeigenen PHP Version anpassen, damit dies auch auf der Shell oder als Cronjob funktioniert.


    3. Im Ordner "/etc/ssl/certs" nach diesen alten Verlinkungen suchen und diese dann entfernen. Löst das Problem zumindest bis zur nächsten Aktualisierung von "ca-certificates". Dauerhaft ist nur ein Aufräumen dieser "Karteileichen" und die Löschung der alten Zertifikate/Zwischenzertifikate, damit diese nicht neuverlinkt werden können. Ist jedoch auch mühselig, da man den Dateien selbst nicht ansieht, ob diese aktiv verwendet werden oder sinnlos rumliegen. Aber zumindest kann man den Inhalt mit "openssl x509 -noout -text -in ZERTIFIKAT.crt" überprüfen.



    Für bessere oder einfachere Vorschläge bin ich offen.

    TCRserver


    Auf den System hier habe ich keine Problem mit openssl. Nach Löschung der Verlinkungen konnte dies wieder problemlos verwendet werden.


    Welche Begründung weist openssl bei einem Fehlschlag aus? Sollte bei "Verify return code" am Ende der Ausgabe oder bei "verify error" am Anfang stehen.

    Zitat von TCRserver


    Sobald diese Verlinkung gelöscht wird, nutz zumindest CURL wieder die korrekte Kette.


    Hat bei mir auf Curl leider gar keine Auswirkungen. (Auf LC Debian Servern)



    Zitat von Marco
    Code
    sed -i 's/mozilla\/DST_Root_CA_X3.crt/!mozilla\/DST_Root_CA_X3.crt/g' /etc/ca-certificates.conf
update-ca-certificates


    Das wird zwar überall empfohlen, hilft aber leider nicht. Also nur auskommentieren oder generelles löschen ändert nichts bei mir. (Auf LC Servern).





    Auf Servern ohne LC ist das auskommentieren ausreichend. bzw einfach dpkg-reconfigure ca-certificates nutzen.

    Kurzer Zwischenstand:


    das Problem scheint zu sein, dass OpenSSL 1.1 das abgelaufene DST X3 im eigenen Trust-Store (anders als von Let's Encrypt erwartet) eben nicht ignoriert. LiveConfig kann/darf das aber auch nicht einfach aus den Chain-Files löschen, weil es wiederum mit ausgeliefert werden muss damit ältere Clients die Verbindung hinbekommen.


    Anders formuliert: das DST X3 muss zwar ausgeliefert werden, darf aber lokal auf dem Server nicht mehr als "vertrauenswürdig" aufgeführt werden. Blöderweise scheint das Script "c_rehash" (was von update-ca-certificates verwendet wird) sich da recht ungünstig zu verhalten, so dass sogar trotz Blacklisting in /etc/ca-certificates.conf dieses Zertifikat immer noch aktiv in der CA-Liste landet.


    Wir sind einer Lösung auf der Spur, melden uns in Kürze nochmal.

    Ich denke wir haben das Problem lokalisiert.


    Durch den Aufruf von "update-ca-certificates" wird das Tool "c_rehash" ausgeführt, welches wiederum alle Zertifikate in /etc/ssl/certs/ ausliest und einen Hashwert berechnet. Dort speichert LiveConfig ja auch die Zertifikatsketten der eigenen Zertifikate.


    c_rehash stößt somit unter anderem auf das Zwischenzertifikat "R3" (US/O=Let's Encrypt/CN=R3, Hash=8d33f237) und legt dafür einen entsprechenden Symlink an (/etc/ssl/certs/8d33f237.0).


    Wenn nun ein OpenSSL-Client eine Verbindung irgendwohin aufbaut, erhält er vom Server dessen SSL-Zertifikat sowie eine Liste der Zwischenzertifikate, mit denen der Client einen Validierungspfad erzeugen kann. Aktuell sieht diese Liste bei Let's Encrypt so aus:


    #0: Subject: /CN=(Domainname)
    #0: Issuer:/C=US/O=Let's Encrypt/CN=R3


    #1: Subject: /C=US/O=Let's Encrypt/CN=R3
    #1: Issuer: /C=US/O=Internet Security Research Group/CN=ISRG Root X1


    #2: Subject: /C=US/O=Internet Security Research Group/CN=ISRG Root X1
    #2: Issuer: /O=Digital Signature Trust Co./CN=DST Root CA X3


    #0 ist das eigentliche Client-Zertifikat, #1 das Zwischenzertifikat (R3), und #2 eben der Sonderfall für alte Clients, welche das Let's-Encrypt-CA-Zertifikat noch nicht kennen (also alte Android-Endgeräte etc.).
    Das Problem liegt nun irgendwo im Verhalten von OpenSSL bei der Prüfung des Zwischenzertifikates (#1). Wenn hierfür nämlich der Hashwert-Symlink /etc/ssl/certs/8d33f237.0 existiert, dann hüpft es direkt weiter zur Prüfung von #2 - sucht also nach einem gültigen Zertifikat vom Aussteller "DST Root CA X3". Gibt's ja aber nicht, weil abgelaufen.
    Existiert der Hash-Symlink (8d33f237.0) nun aber nicht, dann sucht OpenSSL erst im eigenen CA-Truststore ob es einen Aussteller namens "ISRG Root X1" findet. Den gibt's, also ist alles prima.


    Auf den ersten Blick würde ich sagen, dass es sich hier um einen Bug in OpenSSL handelt. Möglicherweise ist dieses Verhalten aber auch bewusst und irgendwo in den Untiefen dokumentiert. Es dürfte bislang schlicht keine Rolle gespielt haben, weil wohl noch nie im vergleichbaren Umfang "abgelaufene" Chain-Zertifikate (hier: #2) in großem Stil ausgeliefert wurden, um Legacy-Clients noch eine Weile zu unterstützen.


    Workaround: die Datei /etc/ssl/certs/8d33f237.0 löschen. Das hält auch eine Weile an, die Hash-Files werden i.d.R. erst beim Update von CA-Zertifikaten aktualisiert:

    Code
    rm /etc/ssl/certs/8d33f237.0


    Wir bereiten nun ein Update vor, welches u.a. folgende Änderungen vornimmt:

    1. die Datei /etc/ssl/certs/8d33f237.0 wird gelöscht
    2. die Chain-Zertifikate werden künftig nicht mehr in /etc/ssl/certs/[...]-ca.crt gespeichert, sondern in /etc/ssl/certs/[...].chain (also nicht mehr mit der Dateiendung ".crt", damit c_rehash diese künftig nicht mehr berücksichtigt.


    Ich melde mich noch mal sobald das Update bereitsteht und wir das Verhalten so bestätigen konnten.

    Wäre es nicht ratsam, die von LC verwalteten Zertifikate unter z.B. /etc/liveconfig/certs abzulegen? Dann bleibt der /etc/ssl Ordner sauber und es kann nichts versehentlich gehasht werden.


    Betrifft aber nicht nur das genannte 8d33f237.0, sondern viele weitere Dateien.
    Aktuelles System bei mir:


    lrwxrwxrwx 1 root root 20 Sep 24 2018 364f1228.0 -> 78db1beb7a05e7ca.crt
    lrwxrwxrwx 1 root root 20 Sep 24 2018 4dad6171.0 -> 78db1beb7a05e7ca.crt
    lrwxrwxrwx 1 root root 23 Sep 24 2018 4a0a35c0.0 -> 1056ded49ebf7fb0-ca.crt
    lrwxrwxrwx 1 root root 23 Sep 24 2018 4f06f81d.0 -> 1056ded49ebf7fb0-ca.crt
    lrwxrwxrwx 1 root root 20 Sep 24 2018 6547a221.0 -> fbfa1a8a4bd536ca.crt
    lrwxrwxrwx 1 root root 20 Sep 24 2018 d426f497.0 -> fbfa1a8a4bd536ca.crt
    lrwxrwxrwx 1 root root 20 Sep 24 2018 7ab1dbe1.0 -> ea542ef395cb04ca.crt
    lrwxrwxrwx 1 root root 20 Sep 24 2018 b617eeea.0 -> ea542ef395cb04ca.crt



    Zusätzlich kann auch 8d33f237.0 und 8d33f237.1 usw. vorliegen.

    Kann ich bestätigen - hier war nur " 8d33f237.1 " vorhanden, nach dem löschen hat es tatsächlich wieder geklappt


    Auf einem zweiten Liveconfig-Server (beides gleicher Versionsstand, von Liveconfig wie auch Debian) gab es allerdings überhaupt keine Probleme :confused:

    Zitat von mhagge

    Auf einem zweiten Liveconfig-Server (beides gleicher Versionsstand, von Liveconfig wie auch Debian) gab es allerdings überhaupt keine Probleme :confused:


    Das haben wir inzwischen auch herausgefunden: das Problem taucht nur unter Debian/Ubuntu auf, wenn nachträglich CA-Zertifikate hinzugefügt oder gelöscht wurden (insbes. via /usr/local/share/ca-certificates/, oder Änderungen in /etc/ca-certificates.conf). Der Befehl "c_rehash" wird nur dann ausgeführt, wenn mindestens ein Zertifikat hinzugefügt oder gelöscht wurde.

    Vielen Dank für die ausführliche Erklärung und Analyse!


    Jetzt stellt sich nur noch die Frage wie man mit dem "alten" Zertifikat in der /etc/ca-certificates.conf korrekt umgeht.
    Ich für meinen Teil würde es wieder aktivieren um evtl. Querwirkungen zu vermeiden.

    In /etc/ca-certificates.conf braucht man eigentlich gar nicht eingreifen. Das "DST Root X3" darf da (nach aktuellem Kenntnisstand) ruhig drin stehen bleiben, da es "ganz normal" abgelaufen ist.
    [UPDATE]Wichtig ist lediglich, dass der Server möglichst aktuell ist (also alle normalen Updates eingespielt sind)[/UPDATE]


    Für den Zusammenhang: wenn das abgelaufene DST Root X3 drin bleibt und man aber die Datei /etc/ssl/certs/8d33f237.0 nicht gelöscht hat, dann erhält man bei ausgehenden OpenSSL-Verbindungen die Fehlermeldung "Certificate expired". Wenn man das DST Root X3 wiederum aus der ca-certificates.conf entfernt (bzw. darin deaktiviert) hat, bekommt man die Fehlermeldung "unable to get issuer certificate". Beide Fehlermeldungen zeigen aber, dass OpenSSL da (warum auch immer) den falschen Validierungspfad wählt.

    Einer von 2 Servern mit der neuen Version meldet:


    Code
    Okt 04 23:13:13 s7 apachectl[1062]: AH00526: Syntax error on line 97 of /etc/apache2/sites-enabled/000-default.conf:
Okt 04 23:13:13 s7 apachectl[1062]: SSLCertificateChainFile: file '/etc/ssl/chains/httpd-default-ca.crt' does not exist or is empty

    Ähm... also bei dem betroffenen Server liegen jetzt unter /etc/apache2/sites-enabled/ keine Verlinkungen mehr sondern die originalen .conf Dateien. Und diese werden bei einer Änderung im LC auch nicht überschrieben sondern nur die im Verzeichnis /etc/apache2/sites-available.


    Das sieht irgendwie nicht so ganz gewollt aus.

    (gelöscht)


    Wer Probleme mit wget oder curl unter Debian 9 hat, muss lediglich das System aktualisieren (GnuTLS in älteren Versionen hat Probleme mit dem abgelaufenen DST Root X3, auf aktuellen Debian9-Installationen passt aber alles).

    Aktuell scheinen wir auf einem System auch vom Let's Encrypt Zertifikatsketten Problem betroffen, auf welchem leider noch Ubuntu 16.04 läuft.


    Die Lösungen im Forum und Ihrem Blogpost haben leider keinen Erfolg gebracht.


    Mir ist aber aufgefallen das sehr viele Zertifikate noch eine alte kette mit verweisen auf die alte RootCA enthalten. (welche ja auch in der /etc/ssl/certs/8d33f237.* das Problem zu sein scheint)


    Gibt es eine Möglichkeit alle LE Zertifikate Zwangs zu erneuern, damit diese keine Verweise mehr auf die abgelaufene Kette enthalten?

    Alle von Let's Encrypt ausgestellten Zertifikate enthalten seit vielen Monaten bereits die "neue" Kette an Zwischenzertifikaten (also "R3" und "ISRG Root X1"). Eine Neuausstellung würde daran nichts ändern.


    Details werden gerade per Ticket geklärt.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden