Seite 3 von 6 ErsteErste 12345 ... LetzteLetzte
Ergebnis 21 bis 30 von 51
  1. #21
    Neuer Benutzer
    Registriert seit
    05.04.2016
    Beiträge
    23
    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.
    Geändert von Marco (02.10.2021 um 10:14 Uhr)

  2. #22
    Erfahrener Benutzer
    Registriert seit
    18.12.2012
    Beiträge
    133
    Zitat Zitat von Marco Beitrag anzeigen
    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.

  3. #23
    Neuer Benutzer
    Registriert seit
    05.04.2016
    Beiträge
    23
    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.

  4. #24
    Neuer Benutzer
    Registriert seit
    05.04.2016
    Beiträge
    23
    @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.

  5. #25
    Neuer Benutzer
    Registriert seit
    05.04.2016
    Beiträge
    23
    @TCRserver

    Das alte Zertifikat hast du auf deinen Systemen auch deaktiviert? Oder ist das noch in der Kette eingebunden?

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

  6. #26
    Erfahrener Benutzer
    Registriert seit
    21.02.2011
    Beiträge
    329
    Zitat Zitat von TCRserver Beitrag anzeigen
    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 Zitat von Marco Beitrag anzeigen
    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.
    Geändert von Mogwais (03.10.2021 um 00:30 Uhr)

  7. #27
    LiveConfig-Team Avatar von kk
    Registriert seit
    10.12.2010
    Beiträge
    3.587
    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.

  8. #28
    LiveConfig-Team Avatar von kk
    Registriert seit
    10.12.2010
    Beiträge
    3.587
    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.

  9. #29
    Neuer Benutzer
    Registriert seit
    05.04.2016
    Beiträge
    23
    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.

  10. #30
    Benutzer
    Registriert seit
    11.11.2015
    Beiträge
    41
    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

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •