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

    Hallo,


    die SSL-Zertifikate die ich über den Admin angelegt habe werde plötzlich in LiveConfig alle als ungültig markiert, obwohl dies nicht der Fall ist (alle noch gültig).


    Das Problem besteht soweit ich es einschätzen kann seit dem letzten LiveConfig-Update auf Version 2.12.2


    Wenn ich die Zertifikate lösche und neu anlege werde Sie wieder als gültig angezeigt bzw. nicht mehr als ungültig markiert.


    Kann das jemand bestätigen bzw. hat das auch beobachtet?

    Ja, können wir bestätigen (betrifft die Übersicht der SSL-Zertifikate, da ist jeweils das Symbol "Zertifikat ist abgelaufen").


    Eventuell prüft LiveConfig intern die Zertifikatsgültigkeit noch über einen alten Validierungspfad. Wir kümmern uns darum, Update wird kurzfristig bereitgestellt.
    Die Zertifikate sind dennoch gültig, der Fehler betrifft nur die Anzeige innerhalb der Übersicht in LiveConfig.


    Viele Grüße


    -Klaus Keppler

    Moin, ich habe auch Probleme mit den Zertifikaten.
    Vor allem bei Postfix, da Empfänger den Empfang blockieren: "454 4.7.5 Certificate validation failure, Reason:CertificateExpired'"


    Das Problem ist das abgelaufene R3 Zertifikat. Moderne Browser überspringen das, ältere Clients aber nicht und es sollte auch nicht mehr Teil der Cert-Chain sein.


    Außerdem ist mein "Default SSL Certificate for SNI" abgelaufen. Wie kann ich das erneuern? Finde kein Update/Renew Button. :(

    Meine leise Hoffung ist auch, dass der ACME-Client aus LiveConfig es in Zukunft erlaubt die Preferred-Chain zu waehlen, so dass man LE-Zertfikate anfordern kann, welche "DST Root CA X3" nicht mehr enthalten. Vielleicht habe ich heute Nacht aber auch nur getraeumt, dass es diese Loesung gibt. ;)

    Zitat von pkambach

    ich habe hier zumindest auch Probleme bei mehreren Kunden - In der Zertifikatskette in Chrome z.B. steht das abgelaufene Root-Zertifikat drin (welche Version und OS es ist, weiß ich noch nicht).


    Soweit ich das sehe stimmt die Zertifikatskette. Ohne die Info welches OS das ist kann man leider nichts sagen.
    Falls es sich um ein Windows XP (vor SP3) oder gar etwas Älteres handelt, wird das nicht erkannt.
    https://letsencrypt.org/docs/certificate-compatibility/


    Workaround: das ISRG X1 Root manuell auf dem betroffenen Rechner installieren.
    Saubere Lösung: betroffenen Rechner grundsätzlich aktualisieren. ;)
    (wenn der tatsächlich sooo alt ist dass er die Zertifikatskette nicht akzeptiert, dann ist SSL das geringste Problem...)


    Viele Grüße


    -Klaus Keppler

    Bei uns ruckelt das Internet heute auch etwas (um heise.de mal zu zitieren)


    Die Probleme mit den Ablauf des LE Zertifikates scheinen doch größer zu sein als erwartet.
    Ein Muster in den betroffenen Geräten können wir nicht erkennen. Es sind aber in allen Fällen aktuelle Geräte mit aktueller Software!


    Eine Lösung die zumindest vereinzelt hilft, aber nicht praktikabel für große Massenupdates ist:

    Code
    # Debian/Ubuntu
# entfernt, weil Querwirkungen


    - Server neu starten (evtl. unnötig)
    - Zertifikat löschen und neu ausstellen


    Danach ist auch der Anzeige Fehler in LC behoben, bei dem jeweiligen Zertifikat.

    Zitat von TCRserver

    Es sind aber in allen Fällen aktuelle Geräte mit aktueller Software!


    Bei aktuellen Geräten mit aktueller Software gibt es (zumindest was LiveConfig betrifft) definitiv keine Probleme.
    Ansonsten bitte konkrete Beispiele nennen (Betriebssystem, Version, konkrete Domain - gerne an support@liveconfig.com).


    Alle bei uns heute aufgeschlagenen Fälle lagen an zu alten Clients (wir hatten es heute schon mit Windows XP SP1 zu tun), nicht durch LiveConfig verwaltete Let's-Encrypt-Zertifikate (da wurde die CA-Chain nicht aktualisiert) oder veralteten Servern (Debian 8 mit OpenSSL 1.0.2 ist problematisch).


    Mit aktuellen Systemen ist uns bislang kein einziger Fall bekannt.


    Zitat

    Danach ist auch der Anzeige Fehler in LC behoben, bei dem jeweiligen Zertifikat.


    Dass LiveConfig Let's-Encrypt-Zertifikate derzeit als "abgelaufen" anzeigt ist ein lokales Problem, das gerade behoben wird (nur ein Darstellungsfehler, die Zertifikate an sich sind gültig und auch korrekt installiert).


    Viele Grüße


    -Klaus Keppler

    Konkretes Beispiel aus unseren Support Tickets:
    Windows 10 20H2
    iPhone 12 (keine Ahnung welches OS)


    Aber es ist immer eine Drittsoftware im Spiel!
    Die vermutlich ggü. einer alten OpenSSL Bibliothek gelinkt ist.


    Und es trifft nicht LiveConfig! Sondern nur Webseiten! Also kein wirkliches LC Problem.


    Mein Workaround oben führt auch eher zu unerwünschten Querwirkungen und nicht ans Ziel.
    Warum auch immer es bei einem Kunden geholfen hat.


    Auf Serverseite können wir vermutlich echt nichts machen, außer eben von LE weg zu wechseln solange bis es sich beruhigt hat und die meisten Anwendungen aktualisiert wurden.

    Hier die kuriose Geschichte + Lösung von meinem Problem:


    Ausgangslage:
    Exchange-Server benutzt meinen Debian Liveconfig-Server mit LetsEncrypt als Smarthost (SMTP-Relay). Seit gestern blieben die Mails in der Queue vom Exchange mit "CertExpired" Fehler.


    Habe das Zertifikat in Liveconfig geprüft, neu erzeugt, etc. aber alles ok. Exchange geprüft etc, auch alles ok.
    Dann habe ich mir mal die Stammzertifikate vom Windows Server angeguckt und siehe da, völlig veraltet und "ISRG Root X1" fehlte. Aber warum, sollten sich ja automatisch aktualisieren. Einstellungen durchsucht, nix gefunden.
    Also mal testweise per Internet Explorer auf meinen Liveconfig Webserver. Dürfte ja auch nicht laden. Aber die Seite lädt, Zertifikat, als auch der Pfad sind ok. Ich zurück zu den Stammzertifikaten und siehe da, alle aktualisiert. :eek:


    Mein Fazit, surfe regelmässig auf Windows Servern mit dem Internet-Explorer, damit die Stammzertifikate akutell gehalten werden...

    Nach einer langen Debug Nacht bin ich einen Schritt weiter aber habe noch keine Lösung!


    Ein simpler CURL Test zeigt auf, dass ein Teil unsere Server ein Problem mit dem ISRG Root X1 Zertifikat hat.
    Alle Server sind dank SaltStack absolut identisch! Aber trotzdem haben einige Server das Problem, dass sie das neue Zertifikat nicht nutzen.


    Der Fehler äußert sich zum Bsp. darin, dass roundcube keine Verbindung mit dem Mailserver herstellen kann.
    (Dazu muss natürlich der Mailserver mit einem LE Zertifikat abgesichert sein. Wird ein alternatives Zert. verwendet, funktioniert es wieder.)
    Log von RC:

    Code
    SMTP Error: Connection failed: Failed to connect socket: fsockopen(): unable to connect to ssl://smtp.domain.de:465 (Unknown error)


    Test mit CURL auf valid-isrgrootx1.letsencrypt.org


    Testschritt 2 - kann OpenSSL auf das Zertifikat zugreifen:

    Code
    # openssl x509 -in ISRG_Root_X1.crt -noout -text
Can't open ISRG_Root_X1.crt for reading, No such file or directory
140091262317696:error:02001002:system library:fopen:No such file or directory:../crypto/bio/bss_file.c:69:fopen('ISRG_Root_X1.crt','r')
140091262317696:error:2006D080:BIO routines:BIO_new_file:no such file:../crypto/bio/bss_file.c:76:
unable to load certificate


    >> NEIN


    Ist das System kompatibel?

    Code
    # openssl version
OpenSSL 1.1.1d  10 Sep 2019


    OpenSSL >= 1.1 wird als kompatibel gelistet


    Code
    # cat /etc/*release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION="10 (buster)"


# apt list --installed ca-certificates
ca-certificates... 20200601~deb10u2 all  [installiert]


    Aktuelles CA Bundle ist installiert


    Einmal checken ob das Zertifikat via dpkg konfiguriert wurde (* beim entsprechenden Zertifikat)

    Code
    # dpkg-reconfigure ca-certificates


    >> JA


    Ist das ISRG Root X1 Zertifikat auch wirklich installiert?!

    Code
    # awk -v cmd='openssl x509 -noout -subject' '
    /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt
...
Subject: O = Digital Signature Trust Co., CN = DST Root CA X3
...
subject=C = US, O = Internet Security Research Group, CN = ISRG Root X1
...


    >> JA


    Ist das Zertifikat auch wirklich in /etc/ssl/certs/ca-certificates.crt enthalten?

    Code
    grep 'MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw' /etc/ssl/certs/ca-certificates.crt


    >> Ja


    Und jetzt gehen mir im Moment die Ideen aus.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden