Seite 4 von 6 ErsteErste ... 23456 LetzteLetzte
Ergebnis 31 bis 40 von 51
  1. #31
    LiveConfig-Team Avatar von kk
    Registriert seit
    10.12.2010
    Beiträge
    3.587
    Zitat Zitat von mhagge Beitrag anzeigen
    Auf einem zweiten Liveconfig-Server (beides gleicher Versionsstand, von Liveconfig wie auch Debian) gab es allerdings überhaupt keine Probleme
    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.

  2. #32
    LiveConfig-Team Avatar von kk
    Registriert seit
    10.12.2010
    Beiträge
    3.587
    Aktueller Kenntnisstand und ausführliche Erklärung:

    https://www.liveconfig.com/de/blog/2...-lets-encrypt/

  3. #33
    Erfahrener Benutzer
    Registriert seit
    18.12.2012
    Beiträge
    133
    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.

  4. #34
    LiveConfig-Team Avatar von kk
    Registriert seit
    10.12.2010
    Beiträge
    3.587
    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.
    Geändert von kk (05.10.2021 um 09:53 Uhr)

  5. #35
    LiveConfig-Team Avatar von kk
    Registriert seit
    10.12.2010
    Beiträge
    3.587
    PS: die v2.13.0 steht nun als Preview bereit, alle Tests hier verliefen soweit reibungsfrei.

  6. #36
    Erfahrener Benutzer
    Registriert seit
    18.12.2012
    Beiträge
    133
    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

  7. #37
    Erfahrener Benutzer
    Registriert seit
    18.12.2012
    Beiträge
    133
    Ä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.

  8. #38
    LiveConfig-Team Avatar von kk
    Registriert seit
    10.12.2010
    Beiträge
    3.587
    (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).
    Geändert von kk (05.10.2021 um 09:52 Uhr)

  9. #39
    Benutzer
    Registriert seit
    03.12.2014
    Beiträge
    63
    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?

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

Lesezeichen

Berechtigungen

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