Genau, aktuell ist das für uns keine option. Mit scute bieten wir ein Modul mit dem wir unseren Kartensupport für Firefox und Thunderbird bereitstellen. Es war mal unsere bewusste Entscheidung das wir keine “Black Box” in form eines proprietären Treibermoduls zwischen uns und der Smartcard dulden wollten. Aber… wir sind ja doch ein bisschen pragmatisch 
In: ⚓ T6234 Implement access to smartcards via a generic pkcs#11 interface sollte das eigentlich implementiert werden. Das Ticket ist aber glaube ich etwas in vergessenheit geraten, ich habe da gerade mal gepingt.
Da kann man nur auf eine ordentliche Portion Pragmatismus hoffen. Wenn man sich eh schon schwer tut, mit der technischen Entwicklung schrittzuhalten, dann auch noch auf 100% Eigenentwicklung zu setzen, finde ich gelinde gesagt: originell.
Wozu gibt es denn Middleware? Bis ihr eine Kartengeneration integriert habt, ist die Zulassung für ein Kartenbetriebssystem abgelaufen ( z. B. STARCOS 3.5) und das nächste ist auf dem Markt ( z. B. STARCOS 3.7). So hinkt ihr ewig hinterher.
Übrigens, was auch noch zu qualifizierter elektronischer Signatur gehören würde, habe ich gerade einmal anhand von GPG 4.3.0 ausprobiert. QES müssen nämlich mit anderer QES-Software prüfbar sein. Und umgekehrt sollte eine QES-Software fremde QES-Signaturen prüfen können. Die Ergebnisse stehen gleich darunter:
-
Prüfen einer GPG-Signatur in Secsigner:
“Beim Einlesen der Daten ist ein Fehler aufgetreten: Die Daten entsprechen keinem gültigen Signaturformat. DER decoder found unknown tag: 13” -
Prüfen einer echten QES-Signatur aus Secsigner mit GPG:
“Gültigkeitsprüfung fehlgeschlagen: Nicht unterstützte CMS Version.”
und
“gpgsm: ksba_cms_parse failed: Nicht unterstützte CMS Version” -
Zeitstempeleinholung? Nicht möglich.
-
Zeitstempelüberprüfung? Nicht möglich.
Und schon der Versuch, zu signieren mit Okular:
Ergebnis sind zwei 0-Byte-Dateien, okular_CCLiMM.png und okular_tibyrx.pdf
Frohes Schaffen! 
Frohes Schaffen!
Danke für Deine Tests und Hinweise!
Es geht halt nur Schritt für Schritt, da GnuPG nicht über die Entwicklungsresourcen verfügt, wie manche Großanbieter.
Zwischenstücke sind durchaus möglich, denke ich, allerdings nur, wenn sie komplett überprüfbar sind (also Freie Software). Ich finde die Strategie schon in Ordnung, zu sagen wir möchten etwas machen, was langfristiger haltbar ist, offen und überprüfbar (also im Quelltext sichtbar). Wenn ich mich erinnere, wieviele proprietäre Krypto-Lösungen wieder verschwunden sind, dann halte ich langsamer für vielversprechender.
Gruß
Bernhard
Hallo alant,
wäre es möglich, dass du hier ein mit Secsigner signiertes Test-Pdf zur Verfügung stellst? Dann können wir versuchen, das damit zu debuggen.
Du kannst die Datei auch gerne mit Verweis auf diesen Thread an info at gnupg.com schicken, wenn dir das lieber ist.
Hallo eebb,
es geht viel einfacher: wenn du diesen Thread aufmerksam gelesen hast, dann weißt du, daß du den Secsigner kostenlos herunterladen und installieren kannst. Dann kannst du beliebig viele Signaturen erzeugen (sowohl integrierte als auch abgetrennte), und zwar mit deiner eigenen Signaturkarte. So kommst du ohne meine persönlichen Daten aus.
Wenn du keine Signaturkarte hast, stellen Signaturkartenherausgeber Entwicklern auch Testkarten zur Verfügung.
Hi alant,
aus unserer Sicht ist das nicht einfacher. Wir müssen dann verschiedene Kombinationen von Signaturkarten und Einstellungen ausprobieren, um die zu finden, die nicht funktionieren. Es gibt in unseren Testdaten mit Secsigner signierte Pdfs deren Prüfung funktioniert.
Wohingegen du schon eine Kombination vorliegen hast, die nicht funktioniert und die offensichtlich in der Praxis Anwendung findet.
Aber war ja auch nur ne Frage, dann müssen wir selber schauen.
Hallo alant,
noch eine Frage:
Würdest du uns denn ein unsigniertes Dokument zum Testen zur Verfügung stellen?
Also ein datenschutzmäßig unbedenkliches Dokument, was, wenn du es signiertst, zu den von dir beschriebenen Fehlermeldungen führt?
Unser Okular und Poppler Experte (der nicht Deutschsprachig ist) meinte, das wäre hilfreich bei der weiteren Analyse des Problems.
Der aktuelle Stand (soweit ich das verstehe) ist, dass die zugrundeliegende Softwarebibliothek Poppler mit manchen Dokumenten Probleme hat. Einige nicht funktionierende Dokumente sind gefunden, aber wir wissen nicht, ob mit den Testfällen dein Problemfall abgedeckt ist.
Hi,
die beA-Signatur ist weiterhin ein Problem, wenn ich dieses Thread richtig verstehe.
@eebb wie kann ich helfen?
Ich bekomme folgenden Fehler, wenn ich versuche, eine PDF zu signieren: Could not sign. Invalid certificate password or could not write to …
Hallo und Danke für dein Hilfsangebot!
Dieses Ticket hier bezieht sich allerdings vermutlich um ein ganz anderes Problem als bei dir bzw. eine generelle Diskussion, vor allem dazu, welche Karten unterstützt werden und welche Formulare problematisch sind. Und es ist auch sehr unübersichtlich geworden …
Du solltest also in jedem Fall ein neues Ticket erstellen, bitte unter help-en, wenn möglich, da unser Hauptentwickler für die GnuPG-Version von Okular nicht deutsch spricht.
Aber prüfe vorher, ob du am Speicherort für das Dokuments Schreibrechte hast, das ist die häufigste Ursache für die von dir genannte Meldung.
Und bei deiner Fehlerbeschreibung wäre wichtig, dass du deine Bertriebssystemsversion und die Versionsnummer von GnuPG-Okular nennst, ob Signieren mit dem Zertifikat in Kleopatra funktioniert und ggf. wer der Herausgeber deines QES zertifikats ist.
Gerne!
Ich habe hier gepostet: German beA (lawyer) certificate problems (Okular and Kleopatra) - User-ID invalid
Falls Informationen in dem Post fehlen, bitte ein Hinweis und ich aktualisiere.
Danke
Leider klappt bei mir die Kombination aus ReinerSCT und d-trust karte unter opensuse 15.6 nicht. gpgsm --learn-card gibt viele Zeilen aus, und am Ende gpgsm: error learning card: Kein passendes Gerät gefunden
In .gnupg\scdaemon.conf habe ich pcsc-shared ergänzt.
gpg-card gibt bei mir Error reading card: Karte nicht vorhanden aus. Und wenn ich in kleopatra auf Sartcard-Verwaltung, gehe sehe ich Bitte schließen Sie eine kompatible Smartcard an.... . Unter Firefox sehe ich die Smartcard von D-trust und meine Zertifikate. Gibts irgendeinen Tipp, wie ich weiterkomme?
@aheinecke kannst Du mir irgendeinen Tipp geben, wie ich hier weiter kommen? Wenn es bei Euch funktioniert, sollte es doch irgendwie unter openSuSE 15.6 zum laufen zu bringen sein. Liegt es vielleicht an älteren Versionenen in openSuSE? Evtl. kann ich mit flatpack die aktuellen installieren?
Hallo,
ich habe mir sagen lassen, dass die Reiner Leser problematisch sind. Hast du vielleicht einen anderen mit dem du testen könntest? Im Flossshop die 3 mit SCM im Namen funktionieren gut mit gpg: Smartcard Leser | Security / Privacy | FLOSS Shop DE
OpenSuse müsste eigentlich recht aktuell sein, was sind denn die Versionsnummern der beteiligten Komponennten?
Hab gerade einen Leser von SCM bestellt. Werde hier berichten, ob es klappt.
Welche Versionsnummer möchtest Du genau wissen? Vom Kartenleser oder von irgendwelchen libraries?
definitiv von gpg, ich bin nicht sicher, was sonst noch hilfreich wäre für die Experten. Und weiß auch nicht, wie Suse die verschiedenen Komponenten paketiert. Scdaemon version, falls es nicht beim gpg Paket dabei ist.
die Version vom gpg2 Paket ist 2.4.4 und scdaemon ist mit dabei, zumindest die Dateien /usr/lib/scdaemon und /usr/lib/udev/rules.d/60-scdaemon.rules
Der Leser ist jetzt da. Unter kleopatra sehe ich immer noch keine smart cards. pcsc_scan gibt folgende Ausgabe:
Using reader plug'n play mechanism
Scanning present readers...
0: Identiv SCR3500 C Contact Reader [CCID Interface] (55592327603370) 00 00
Mon Apr 14 12:47:23 2025
Reader 0: Identiv SCR3500 C Contact Reader [CCID Interface] (55592327603370) 00 00
Event number: 13
Card state: Card inserted, Shared Mode,
ATR: 3B D2 18 00 81 31 FE 58 C9 04 11
ATR: 3B D2 18 00 81 31 FE 58 C9 04 11
+ TS = 3B --> Direct Convention
+ T0 = D2, Y(1): 1101, K: 2 (historical bytes)
TA(1) = 18 --> Fi=372, Di=12, 31 cycles/ETU
129032 bits/s at 4 MHz, fMax for Fi = 5 MHz => 161290 bits/s
TC(1) = 00 --> Extra guard time: 0
TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1
-----
TD(2) = 31 --> Y(i+1) = 0011, Protocol T = 1
-----
TA(3) = FE --> IFSC: 254
TB(3) = 58 --> Block Waiting Integer: 5 - Character Waiting Integer: 8
+ Historical bytes: C9 04
Category indicator byte: C9 (proprietary format)
+ TCK = 11 (correct checksum)
Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B D2 18 00 81 31 FE 58 C9 04 11
Identity Card in Slovakia with security chip and e-signature issued after 2021-06-21 (eID)