Warum wird das Root-Zertifikat direkt nach dem Import als “ultimativ” vertrauenswürdig bezeichnet, obwohl ich es vorher aus der trustlist.txt entfernt und danach Kleopatra neu gestartet hatte? Es steht nach dem Import auch nicht mehr drin.
Mein 2. Problem: Warum gelingt zwar der Import des BT32-Zertifikats, inklusive der Hierarchiedarstellung, aber beim Öffnen des Zertifikats mit Doppelklick switcht das Zertifikat nach jedem Kleopatra-Neustart auf Status “Ungültig”? Die Fingerabdrücke habe ich überprüft, die Zertifikate sind beide gültig.
Vom BT32 signierte Benutzerzertifikate sind natürlich auch bei jedem Öffnen “Ungültig”.
Hi @alant, zwei kurze Rückfrage: welche Gpg4win Version verwendest du?
Und sind das die gleichnamigen Zertifikate von der Datev Webseite?
Zu 1: “ultimativ” zeigt bei S/MIME Zertifikaten an, dass es ein Root Zertifikat ist, dem man vertraut hat. Wenn du ihm nicht mehr vertrauen willst, kannst du das Vertrauen entzeihen, indem du im Menü Zertifikate → “Wurzelzertifikat nicht vertrauen” wählst. Dann wird das sofort in Kleopatra angezeigt. Und die Nachfrage, ob man dem Zertifikat vertrauen will, kommt dann nicht mehr.
Wenn du statt dessen den Eintrag in der trustlist.txt löschst, muss du in Kleopatra Extras → “Hintergrundprozesse neu starten” ausführen, weil der Trustlevel sonst nicht aktualisiert wird in Kleopatra.
Ich vermute 2) ist ein Folgeproblem, starte erst mal die Hintergrundprozesse neu und schau dann nochmal.
Ich habe sie allerdings aus meinem Thunderbird-Speicher geholt und den Dateinamen umbenannt für das Forum hier.
! Da muß man drauf kommen, dort im Menü nach dieser Funktion zu suchen. Das wäre doch ein schöner Punkt für das Kontextmenü des Stammzertifikats. Dort gibt es nämlich fast nur ausgegraute Punkte. Danke!
Danke, das habe ich nach dem Post noch bemerkt, daß danach die Löschung erst in GPG angekommen war.
Jetzt habe ich das ganze nochmal probiert, wurde explizit nach dem Root-Zertifikat gefragt, ob ich dem vertrauen will, nach “Ja” habe ich das BT32 importiert, und das erhält in der Übersicht auch den Status “beglaubigt”. Erst wenn man es per Doppelklick öffnet, heißt es “Aktualisierung läuft” und dann “ungültig”. Und das paßt eben nicht.
Ergänzung: GPG4Win 5.1.0 (Windows 11 64 bit) inzwischen. Aktualisiert habe ich nur, weil der Fehler auch mit der vorher installierten Version schon auftrat.
Das Problem war, dass das Kontextmenü mittlerweile sehr lang war. Daher haben wir dort Funktionen, die man nur selten braucht, raus geworfen.
Ich kann es nicht nachvollziehen: Bei meinem kurzen Test mit GPG4Win 5.1.0 wird das BT 32 Zertifikat mit Vertrauenswürdigkeit “vollständig” angezeigt. Auch nach öffnen der Details und “Aktualsierung läuft”.
Schau mal bitte in den Kleopatra Einstellungen unter S/MIME Prüfung nach. Was ist da bei dir angehakt? Meine Vermutung ist, dass du einen Haken bei “Zertifikate online bestätigen (OSCP)” gesetzt hast. Wenn ich die Option anhake (ohne einen Server zu setzen) wird das Zertifikat auch bei mir nach Öffnen der Details als “ungültig” angezeigt. Grund dafür dürfte sein, dass kein Server erreicht werden konnte.
Ich schaue mal, ob ich in Erfahrung bringen kann, ob dies das gewünschte Verhalten ist.
Da kann ich nur auf eine negative Antwort hoffen. Überhaupt ist, wie an einigen Stellen der GUI, unklar, was durch das Deaktivieren bewirkt wird: wird hier eine OCSP-Prüfung generell ausgeschaltet? Was schlecht wäre.
Oder ist das eine Option zur Angabe eines zusätzlichen OCSP-Responders, die man deaktivieren kann? Hier stellte sich die Frage nach dem Sinn: X.509-Zertifikate tragen generell den Pfad zu ihrer Überprüfung in sich, manipulationssicher.
Auch die deutsche Wortwahl ist unklar. X.509-Zertifikate werden (außer bei QES) nicht online positiv “bestätigt”, sondern offline, durch eine gültige Signatur des höherrangigen, ggf. als vertrauenswürdig gesetzten Zertifikats. OCSP liefert (außer bei QES) nur eine Negativantwort (“nein, dieses Zertifikat ist nicht gesperrt”.
Das liegt daran, daß das “Kontext”-Menü nicht differenziert zwischen OpenPGP- und S/MIME-Zertifikaten. Vieles von dem Ausgegrauten hat bei S/MIME keine Funktion. Stattdessen fehlen sinnvolle Funktionen wie “Wurzelzertifikat nicht vertrauen” bei S/MIME-Rootzertifikaten.
Immerhin diese Frage konnte ich mir jetzt mit Blick auf meine Firewall selbst beantworten: wenn man im Zertifikat auf “Aktualisieren” drückt, will Kleopatra eine Verbindung zum LDAP-Server von DATEV haben, auch bei “deaktiviertem” “Zertifikate online bestätigen (OCSP)”.
Dann handelt es sich bei dieser Option wohl um einen zusätzlichen Serverpfad? Oder etwas ganz anderes? Es ist ein Ratespiel.