[Interne Konsistenzprüfung ist fehlgeschlagen]

vor 47 Minuten schrieb Dantirae:

Hast du schon eine Lösung zu dem Problem gefunden?
Ich stehe gerade selbst auf der gleichen Leitung und soll Montag was abgeben, dass zwingend qualifiziert signiert werden muss.

Ich habe verschiedene Tests (in C#, Java und mit Adobe Acrobat Reader DC und Foxit Reader) durchgeführt und dabei festgestellt, dass zumindest der Weg über die Microsoft CryptoAPI (und dann weiter über den Microsoft BaseCSP und den Nexus Personal Minidriver und erst abschließend das PKCS#11 Modul "personal64.dll") leider nicht funktioniert. Ich habe hier den Nexus Personal Minidriver im Verdacht und über REINER SCT ein Ticket bei der Nexus Group aufgemacht.

Was geht sind die folgenden Wege:

1. Direkt über die PC/SC Schnittstelle
2. Über das Nexus Personal PKCS#11 Modul (personal64.dll), das dann wohl auch wieder über PC/SC geht.
3. Über eine quasi speziell für qualifizierte Signaturen gebaute Signatur-Software (habe das selbst mit dem kostenlosen SecSigner von SecCommerce ausprobiert, siehe https://seccommerce.com/secsigner/, aber es gibt auch andere wie z.B. von Secrypt). Diese Programme nutzen auch die PC/SC Schnittstelle

Die PC/SC Schnittstelle wird über die in Windows bereitgestellte WinSCard.dll angesprochen und muss durch den vom SmartCard-Hersteller bereitgestellten Treiber unterstützt werden (was bei REINER SCT natürlich der Fall ist). Die PKCS#11-Module kommen normalerweise vom SmartCard-Hersteller bzw. man nimmt die Open Source Bibliotheken von OpenSC. Für die D-TRUST-Karten eignet sich eben das von Nexus Personal bereitgestellte PKCS#11 Modul.

Leider ist der Weg über die PC/SC-Schnittstelle ziemlich komplex und man braucht hier Handbücher der SmartCard-Hersteller (z.B. D-TRUST, TeleSec). Und natürlich ist auch der Weg über PKCS#11 nicht einfach. Je nach Programmiersprache gibt es aber Produkte (z.B. von IAIK) oder Open Source NuGet Packages, die einem das Leben zumindest ein wenig erleichtern. 

[Interne Konsistenzprüfung ist fehlgeschlagen]

vor 12 Stunden schrieb René:

Schon versucht?:

https://helpx.adobe.com/acrobat/kb/key-does-not-exist-error-code-2148073485.html

https://helpx.adobe.com/acrobat/kb/error-creation-signature-could-completed.html

Vielen Dank!

Den ersten Beitrag hatte ich gesehen. Allerdings bezieht der sich auf einen anderen Fehlercode. Weiterhin habe ich das Kartenlesegerät (cyberJack RFID komfort) und die Software (Base Components 7.8.6 und Nexus Personal 5.3.1) gerade erst installiert. Deshalb gehe ich davon aus, dass die Treiber aktuell sind. Die Treiberversion des cyberJack ist 6.1.1.0 (Datum 23.3.2017).

Der andere Link bezieht sich auf andere Fehler. Allerdings habe ich mal die Zertifikate gelöscht. Die wurden dann wahrscheinlich von der Nexus Personal Middleware wieder erzeugt. Der Fehler verschwindet dadurch leider nicht.

 

[Signatur Adobe Acrobat]

Am 15.4.2020 um 12:33 schrieb Uli_easy:

Adobe Acrobat DC und auch Acrobat Reader DC funktionieren einwandfrei mit den oben beschriebenen Treibern.

Man braucht allerdings wirklich die Middleware Nexus Personal. Der Treiber für den Kartenleser (z.B. Reiner SCT Comfort) und den D-Trust Card Assistant. Dann wird das Zertifikat in Acrobat oder Reader angezeigt und es kann unterschrieben werden.

Ich habe eine D-Trust Test-Signaturkarte 3.1, einen Reiner SCT cyberJack RFID komfort, den T-Trust Card Assistant und Nexus Personal. Adobe Acrobat Reader DC erkennt den Reader und die Signatur, die PIN-Eingabe ist erfolgreich, aber dann meldet Adobe Acrobat Reader DC den folgenden Fehler:

Zur Sicherheit nochmal als Text: The Windows Cryptographic Service Provider reported an error: An internal consistency check failed. Error Code: 2148532225.

Die Fehlermeldung "An internal consistenc check failed" bekomme ich auch, wenn ich das mit C#/.Net versuche.

[Interne Konsistenzprüfung ist fehlgeschlagen]

Ein weiterer Versuch mit Adobe Acrobat Reader DC führt zur selben Fehlermeldung:

Mir ist nicht 100% klar, welche Komponente dafür verantwortlich ist. Ohne Anspruch auf Vollständigkeit kommen aus meiner Sicht in Frage:

• die D-Trust Card 3.1 (Testkarte),
• der D-Trust Card Assistant v3.7 oder
• die Nexus Personal Middleware v5.3.1.

Mein C# Testprogramm fängt eine Exception mit einem HRESULT-Wert von 0x80100001 (SCARD_F_INTERNAL_ERROR) und der Nachricht "An internal consistency check failed." Der HRESULT-Wert enstpricht dem Error Code 2148532225, den auch Adobe Acrobat Reader DC meldet. Mit der Information hätte ich aber am ehesten die SmartCard im Verdacht.

Wichtig zu verstehen ist, dass es "grundsätzlich" funktioniert, d.h. eine Signatur mit dem nicht-qualifizierten Authentisierungszertifikat, das sich neben dem qualifizierten Signaturzertifikat auf der SmartCard befindet, ist z.B. mit Word, dem Adobe Acrobat Reader DC und meinem C#-Testprogramm erfolgreich. Nur das qualifizierte Signaturzertifikat führt zu dem Fehler. Allerdings werden auch unterschiedliche Signaturalgorithmen benutzt. Das Signaturzertifikat gibt RSASSA-PSS an, während das Authentisierungszertifikat sha256RSA verwendet.

Ich wäre für jegliche Hinweise dankbar.

[Interne Konsistenzprüfung ist fehlgeschlagen]

Ich habe denselben Fehler mit einer Test-Signaturkarte 3.1 von D-Trust, einem CyberJack RFID komfort und der Nexus Personal Middleware. Das Signieren mit dem Authentisierungszertifikat funktioniert. Mit dem qualifizierten Zertifikat meldet Word einen Fehler, nachdem die PIN-Eingabe erfolgreich war. Versuche mit eigenem C#-Code (.NET Framework 4.7.2) scheitern mit derselben Fehlermeldung, die mszk angegeben hat (lediglich auf Englisch).

Auch bei mir lässt sich die Signatur mit dem Foxit Reader einfügen, wird dann aber als ungültig angezeigt. Die Fehlermeldung ist "Unexpected byte range values defining scope of signed data".

Gibt es hierfür ggf. bereits eine Lösung?