Klick auf “Computerzertifikate…”, bzw." Benutzerzertifikate…"
ggf. Klick auf “Ja”
Doppelklick auf “Zwischenzertifizierungsstellen”
Klick auf “Zertifikate” zwei Zeilen tiefer
Rechtsklick auf “Let’s encrypt…”
Klick auf “Löschen”
ggf. Warnhinweis positiv bestätigen
Alle Fenster schließen
Die allermeisten Schritte sind gewiss bekannt. Ich schreibe die
Schritte aber ganz bewusst so ausführlich auf, weil vielleicht
einmal jemand auf dasselbe Problem stößt, der/ die nicht so
versiert ist wie ihr.
Ja, so hatte ich es auch probiert, allerdings hatte ich das Zwischenzertifikat
nicht an dieser Stelle. Es wird allerdings vom Webserver geliefert - wie ich
mittlerweile herausgefunden habe. Und Microsoft liefert noch das ausgelaufene
Wurzel-Zertifikat aus. Das erklärt, warum ein Löschen des Zwischenzertifikats
allein wohl nicht ausreicht. Und es erklärt auch, warum ein erster Test auf einer
GNU/Linux Plattform das Problem nicht reproduziert hatte.
Hallo Andre,
wenn Du 2.2.32 oder 2.3.3 drüber installiert hast, dann ist kommt der Algorithmus mit dem “Trick” von Let’s encrypt grundsätzlich klar. Dein System braucht allerdings zusätzlich das “richtige” Wurzelzertifikat von Let’s encrypt. (Es gibt zwei sehr ähnlich aussehende Zertifikate, die gleich(?) heißen, das eine ist ein Zwischenzertifikat, dass andere das Wurzelzertifikat). Manche Windows-Systeme haben das neue Wurzelzertifikat wohl nicht, die Gründe sind mir bisher nicht bekannt.
Also: Nachsehen ob das richtige Let’s encrypt certificat von Microsoft schon reingekommen ist und notfalls über das System (und den offiziellen Weg) aktualisieren.
Sollt es trotzdem nicht gehen, gern hier melden. Vielleicht gibt es ja doch noch System mit anderen Problemen oder Schwierigkeiten.
vielen Dank für die schnelle Antwort.
Über den hier beschrieben Weg, die Zwischenzertifikate zu prüfen, finde ich kein Zertifikat, das mit “Let’s encrypt” in Verbindung gebracht werden könnte.
Ich bin hier ratlos, was an meinem fehlenden Fachwissen liegt.
Hi André,
vielleicht war entweder der alte Dienst (dirmngr) noch aktiv
oder in der Zwischenzeit hat Windows die neuen Wurzelzertifikate geholt.
(Persönlich habe ich noch nicht genau gefunden oder ermittelt, wann und wie Window die Liste seiner Wurzelzertifikate aktualisiert, ich weiß nur, dass es manchmal automatisch geschied.)
Ich klage über dasselbe Problem mit Kleopatra:
“gpg: Refresh vom Schl├╝sselserver fehlgeschlagen: Zertifikat abgelaufen”
Um das Problem zu beheben folgte ich euren Anweisungen so gut ich konnte:
ich installierte das neue GnuPG 2.2.32
ich versuchte das Let’ Encrypt Zertifikat zu löschen *)
ich habe alle Windows Updates angestoßen und installiert, um auf diesem Weg vielleicht zu einem gültigen (Wurzel- ?)Zertifikat zu kommen.
Hat alles nichts geholfen:
Amerkung *) Ich habe kein einziges Zertifikat mit “Let’s Encrypt” im Namen in “Certmgr”, dem Windows Zertifikate Manager gefunden - kein Zwischenzertifikat, kein Wurzelzertifikat.
Ich habe auf denWebseiten von Let’s encrypt versucht das Wurzelzertifikat selbst zu finden und zu Installieren.
Dabei stieß ich auf ein Zertifikat “R3” ausgestellt von “DST Root CA X3”, Was ich auch in meinem Zertificatemanager von Windows wiederfand, sowohl als Zwischenzertificat als auch ein Root Zertifikat.
Auch das Löschen dieser beiden Zertifikate änderte nichts am Verhalten von Kleopatra, ebensowenig wie die Instalation des Zertifikats von der Let’s Encrypt - Seite.
Ein weiterer Hinweis zu meinem (un-) Verständnis:
Auf meinem Raspi läuft ein Webserver mit Zertifikaten von Let’s Encrypt. Bei einem Besuch dieser Seiten kam es noch zu keiner Fehlermeldung, das das Zertifikat abgelaufen sei…
eine Möglichkeit wäre, das das Zertifikat von dem einen Keyserver, den Du benutzt, wirklich abgelaufen ist. Dann würde auch die aktuellste Software mit Wurzelzertifikaten nichts nutzen.
Magst Du den Keyserver angeben? (Dann kann ich auch hier mal schauen.)
Die andere Möglichkeit ist, erhöhte Diagnose-Ausgaben einzuschalten. In diesem Falle wäre das dirmngr. Also in die dirmngr.conf kannst Du log-file c:\XYZ und debug-level advanced einschalten, dann dirmngr neu starten (z.B. gpgconf --reload dirmngr) einen Abruf starten und schauen, was in der Logdatei steht.
(Achtung: In detaillierten Logs könnten persönliche Daten enthalten sein.)
Dein Raspi hat beim Besuch von Let’s Encrypt Webseiten vermutlich kein Problem,
weil dort andere Software und andere Wurzelzertifikate laufen und die Überprüfung der
Zertifikatskette vornehmen. (OpenSSL wurde allerdings auch von dem “Trick” der Let’s Encrypt Leute “überrascht”, ist nicht schön, kann aber passieren. Das Hauptproblem waren wohl mobil Geräte, die nicht mehr updatefähig sind (wie alte Androids).)
ich hake da kurz ein, da ich ebenfalls unter Windows 10 Pro dasselbe Problem habe.
Angehängt das Log nach den von Bernhard erwähnten Einträgen in der dirmngr.conf.
Verwendet wird aktuell Gpg4Win 4.0, über eine ältere Gpg4Win Installation drüber installiert.
Zur Info, was ich sonst noch so getan habe:
Ursprünglich auf Gpg4Win 4.0 aktualisiert, Rechner neugestartet, Problem immer noch vorhanden.
GnuPG manuell auf GnuPG 2.2.32 downgegraded. Alles neugestartet, Problem immer noch vorhanden.
Wieder eine ordentliche Gpg4Win 4.0 Installation durchgeführt
Windows Zertifikatsstore gecheckt, DST Root CA X3 entfernt, Windows neugestartet, DST Root CA X3 nach Neustart wieder vorhanden
DST Root CA X3 entfernt, das führt aber nur dazu, dass dirmngr jetzt aufgrund fehlenden Root Zertifikats scheitert:
2022-01-06 18:12:01 dirmngr[23756] DBG: find_cert_bysubject: certificate not in cache
2022-01-06 18:12:01 dirmngr[23756] DBG: chan_0x0000029c → INQUIRE SENDCERT_SKI C4A7B1A47B2C71FADBE14B9075FFC41560858910 /CN=DST Root CA X3,O=Digital Signature Trust Co.
2022-01-06 18:12:01 dirmngr[23756] DBG: chan_0x0000029c ← CAN
2022-01-06 18:12:01 dirmngr[23756] assuan_inquire(SENDCERT_SKI) fehlgeschlagen: Der IPC Aufruf wurde abgebrochen
2022-01-06 18:12:01 dirmngr[23756] DBG: find_cert_bysubject: certificate not returned by caller - doing lookup
2022-01-06 18:12:01 dirmngr[23756] Fehler beim Holen des Zertifikats mittels Subject: Konfigurationsfehler
2022-01-06 18:12:01 dirmngr[23756] issuer certificate {C4A7B1A47B2C71FADBE14B9075FFC41560858910} not found using authorityKeyIdentifier
2022-01-06 18:12:01 dirmngr[23756] Herausgeberzertifikat nicht gefunden
2022-01-06 18:12:01 dirmngr[23756] issuer certificate: #/CN=DST Root CA X3,O=Digital Signature Trust Co.
2022-01-06 18:12:01 dirmngr[23756] TLS handshake failed: Fehlendes Herausgeberzertifikat in der Kette
Nach etwas weiterer Recherche des Themas habe ich dann den dirmngr folgendermaßen manuell gestartet:
dirmngr --ignore-cert 48504E974C0DAC5B5CD476C8202274B24C8C7172 --daemon
Also nur das Zwischenzertifikat mit der alten Signatur deaktiviert. Solange der dirmngr mit dieser Option läuft, funktioniert es wie gewünscht.
Daher jetzt aber die folgenden Fragen…
a) kann ich dirmngr so konfigurieren, dass dieses Zertifikat auch beim automatischen Start deaktiviert wird?
b) warum wird dieses Zertifikat überhaupt berücksichtigt? Im Windows Zertifikatsstore ist es auf jeden Fall nicht, das hab ich sowohl manuell als auch per Hash Suche überprüft.
Ach ja, betrifft in meinem Fall nicht nur hkps://keys.openpgp.org, sondern auch hkps://keyserver.ubuntu.com
re 1) vermutlich kannst Du “ignore-cert” auch in dirmngr.conf eintragen. (Habe ich nicht getesten.)
re 2) Es wäre möglich, dass das Zwischenzertifikat auch vom TLS Server mitgeliefert wird, zumindest ist das bei TLS üblich. Irgendwo scheint sich allerdings doch noch ein Defekt in der Implementierung zu befinden, weil er eigentlich den validen Pfad der Zertifikate vorziehen sollte. Vielleicht fehlt das valide Wurzelzertifikat?
Erstmal sehr cool, dass Du eine andere Möglichkeit gefunden hast, dass es für Dich läuft, an ignore-cert hatte ich noch nicht gedacht.
Zu 1) ich glaube ich hatte es getestet und die Option wurde nicht erkannt, kann ich aber nochmal testen.
Zu 2) ich hab mir Mal den Commit angeschaut, der den Fehler beheben sollte. Durch die Änderung wird mit is_trusted_cert geprüft, ob das Zertifikat verwendet werden soll, und sobald das für eines passt, werden alle weiteren ignoriert. In is_trusted_cert wird aber nur geprüft, ob das zu prüfende Zertifikat im cert cache vorhanden ist. Eine Überprüfung, ob das Zertifikat expired ist, findet zumindest an der Stelle nicht statt. Ich hab jetzt noch nicht geprüft, ob das vor dem Hinzufügen eines Zertifikats zum Cache geprüft wird.
Ok, es wird tatsächlich beim Cache befüllen nicht geprüft. Hab an einer anderen Stelle im Code gesehen wie die Überprüfung auf den Gültigkeitszeitraum funktioniert. Wenn ich die Tage Mal Zeit habe, schreib ich das schnell runter.
Gäbe es einen Grund ein Zertifikat an der Stelle zu verwenden obwohl es in dem Zeitraum nicht gültig ist?
warte gerade auf dev.gnupg.org noch auf Freigabe meines Accounts.
Soll ich die Infos gleich hier hinzufügen (https://dev.gnupg.org/T5639) oder ein neues Issue aufmachen?
Hallo Flo,
vermutlich ist ein neues Issue besser, weil ein Teil der Probleme
mit der Lösung des alten Issues weggingen. Insofern ist Deine Analyse
für einen anderen Teil des Problems interessant.
Beim “Chain Verification Model” seien Zertifikate, welche aus dem Gültigkeitsbereich herausgelaufen sind, noch als gültig anzusehen. Es kann also sein, dass die Implementierung hier den passenden Standards folgt.
Die Option “ignore-cert” sollte auch in der dirmngr.conf gehen. Vielleicht fehlt ein Neustart des Dirmngrs, um den Effekt zu sehen.
zu 1) Ok, das entspräche dann ja auch genau der aktuellen Umsetzung
zu 2) Stellt sich raus, wenn man zwei unterschiedliche Versionen einer Software an unterschiedlichen Stellen im System hat, sollte man auch die korrekte Configdatei bearbeiten für die Version, die man gerade testen will… in der korrekten Datei eingetragen und dann ein Dirmngr Neustart funktioniert
Da ich aber an sich schon noch dem Grundproblem auf den Grund gehen will und nicht nur ein Symptom ausblenden, habe ich jetzt endlich noch meine Findings bei dev.gnupg.org ergänzt, bin leider nicht eher dazu gekommen.
Danke Florian!
(dev.gnupg.org ist - meiner Ansicht nach - besser geeignet, wenn wir jetzt tief in die Analyse rein müssen, weil Irgendwas ist da noch nicht voll verstanden.)