Refresh vom Schlüsselserver fehlgeschlagen: Zertifikat abgelaufen

… aber gerne:

  1. Systemsteuerung aufrufen
  2. Oben rechts ins Suchfeld eingeben: zert
  3. Klick auf “Computerzertifikate…”, bzw." Benutzerzertifikate…"
  4. ggf. Klick auf “Ja”
  5. Doppelklick auf “Zwischenzertifizierungsstellen”
  6. Klick auf “Zertifikate” zwei Zeilen tiefer
  7. Rechtsklick auf “Let’s encrypt…”
  8. Klick auf “Löschen”
  9. ggf. Warnhinweis positiv bestätigen
  10. 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.

Viele Grüße
Stefan

Stefan,
danke für die Beschreibung!

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.

Gruß
Bernhard

… genau so!

Was für ein angenehmes Profi-Forum… echt wohltuend!

Viele Grüße
Stefan

Auch nach der Aktualisierung dieser Dateien bleibt das Problem bei meinem System bestehen (Windows 10 Pro).

Das Veröffentlichen und das Abrufen von Schlüsseln ist nicht möglich und wird mit einer Fehlermeldung belohnt.

Gibt es noch weitere Lösungen dieses Problems?

Screenshot 2021-11-17 160733.jpg

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.

Gruß,
Bernhard

Hallo Bernhard,

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.

Hast Du noch einen Tipp für mich?

LG, André

Hi Bernhard,
jetzt hat es ohne Veränderungen einfach so funktioniert.
Danke!
LG, André

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.)

Schön, dass das Problem weg ist. :slight_smile:

Gruß,
Bernhard

Hallo beisammen,

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…

gibt es weitere Vorschläge?!?

Grüße,
Christian

Hallo Christian,

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. :wink:
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).)

Gruß
Bernhard

Hallo Bernhard und Christian,

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

Gruß,
Flo

dirmngr_2022-01-06.log (10.4 KB)

Hallo Flo,

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.

Gruß
Bernhard

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?

Hallo Florian,
danke für Deine weitere Analyse!

Magst Du die auf Englisch entweder auf gnupg-dev@ schicken oder
an dev.gnupg.org einreichen?

(Schade das ignore-cert in der Konfig nicht geht, meistens gehen alle Kommandozeilenoptionen dort auch. Lohnt vielleicht auch eine Nachfrage!)

Viele Grüße
Bernhard

Hallo Bernhard,

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?

Gruß,
Flo

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.

Vielen Dank im Voraus,
Bernhard

Hallo Florian,

zwei Hinweise von Werner zu diesem Fall:

  • 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.

Gruß,
Bernhard

Hallo Bernhard,

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 :slight_smile:

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.

Gruß,
Flo

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.)