Fehlermeldung: 250.002: Cannot sign request: secpkisecapp.fv: 1 documents could not be signed, because the timeout of -1 seconds for waiting for card and PIN has been hit.

Diese Fehlermeldung kann zwei Gründe haben.

1. Die Signaturkarte ist nicht im Kartenleser gesteckt und kann nicht gefunden werden.

2. Das SoftwareZertifikat ist nicht im SecPKIServer eingerichtet. (Nähere Informationen siehe "Wie kann ich dem SecPKIServer ein Software-Zertifikates zum Signieren hinzufügen?")

Fehlermeldung: ERROR:A SignUnit could not complete its signature task: 1 documents could not be signed, because the timeout of -1 seconds for waiting for card and PIN has been hit.

Wenn bei der Verwendung von Softwareschlüsseln Probleme auftreten, kann im Log des SecPKIserver überprüft werden, ob der Schlüssel tatsächlich verwendbar ist. Diese Information gibt der SecPKIServer aber nur bei einem Neustart in seinem Log aus.

Bei der Initialisierung eines Softwareschlüssels findet sich im Log des SecPKIServer ein Block ähnlich dem Folgenden:

11.02.2010 10:33:45:667 main: Initialising soft cert signature unit 10007
11.02.2010 10:33:45:840 main: Soft cert sign unit 10007 activated
11.02.2010 10:33:45:853 main: Will look for attribute certificates of the smart card in unit 10007 in the database.
11.02.2010 10:33:46:043 main: Return getUserCertificatesByCertHash[1] for UserIdId=1006
11.02.2010 10:33:46:073 main: target user certificate not found
11.02.2010 10:33:46:073 main: No attribute certificate for the smart card in unit 10007 was found in the data base. So none will be added to the signatures.
11.02.2010 10:33:46:073 main: No attribute certificate found for signing certificate associated to soft cert sign unit 10007. The certificate SN=861 belongs to zksa-test. The liability of the signature certificate is not limited. Therefore there may be no attribute certificate at all.
11.02.2010 10:33:46:073 main: The requested signature clearance time was limited to the expiry date of the signature certificate or decrypt certificate or any attribute certificate Sun Oct 25 13:04:51 CET 2015 soft cert sign unit 10007
11.02.2010 10:33:46:090 main: Soft cert signature unit 10007 ok.

Wichtig ist vor allem die letzte Meldung: Soft cert signature unit 10007 ok.
Dadurch wird angezeigt, dass der Softwareschlüssel richtig initialisiert wurde und verwendet werden kann.

Findet sich dagegen im Log ein Eintrag wie der folgende, ist der Schlüssel in der Datenbank deaktiviert worden und kann deshalb nicht verwendet werden.

main: Skipping soft cert signature sign unit 10000, because it was marked inactive in the data base.

Die einzige Abhilfe besteht in diesem Fall darin, den Softwareschlüssel in SecPKI neu anzulegen. Dazu muss in der SecPKI-Admin-Applikation unter SecPKIServer Verwaltung/Softwareschlüssel der Eintrag für den Schlüssel entfernt und ein neuer Eintrag angelegt werden.

Das benötigte Kontingent ist abhängig vom für die automatische Übersignatur gewählten Intervall. Dieses erklärt sich aus der Arbeitsweise bei der Übersignatur. Sobald eine Übersignatur ausgeführt wird, wird ein neuer Hashbaum erzeugt, falls Signaturen vorhanden sind, die noch nicht durch eine Übersignatur abgesichert sind. Einem einmal durch eine Übersignatur gesicherten Hashbaum können keine neuen Signaturen hinzugefügt werden. Für jeden im Archiv vorhandenen Hashbaum wird je Übersignaturvorgang jeweils ein Zeitstempel angefordert. Je weniger Signaturen am Tag verarbeitet werden, um so größer sollte das Intervall der Übersignaturen gewählt werden, um die Anzahl benötigter Zeitstempel zu reduzieren.

Den Port für die Kommunikation mit den Trustcenter geben die Trustcenter selbst vor. In der Praxis werden die Ports 80 und 8080 verwendet. Sie müssen demnach beide Ports für die Kommunikation zwischen SecPKIServer und Trustcenter freischalten (lassen).

Der SecPKIServer muss in jedem Fall installiert werden. Er wird nicht zwingend zum Signieren benötigt, aber für das Signatur-Archiv und das Validieren von Signaturen.

Die Massensignatur ist mit dem SecSigner nicht möglich. Diese Art der Signatur wird nur vom SecPKIServer unterstützt. Der SecSigner unterstützt die Stapelsignatur (jedoch nicht in der Applet-Version).

Es kann verschiedene Gründe geben, warum der SecPKIServer nicht erreicht werden kann:

1) Fehlermeldung: 250.070: communication error: seccommerce.sec.SecExceptionCommunication: Cannot open sockets to any of the SecPKIServers configured.

Sofern über Modawi keine Verbindung zum SecPKIServer aufgebaut werden kann, sollte der Pfad zum Zertifikat für die TLS-Verbindung in der "secpki.properties"-Datei kontrolliert werden. Wichtig ist, dass an dieser Stelle nicht der vollständige Pfad zum Zertifikat, sondern der Pfad ab "WEB-INF" angegeben wird.

z.B.: "seccommerce.secappservertlscert=WEB-INF/properties/secpkiCert.der"

Eine andere Möglichkeit ist, dass der SecPKIServer nicht gestartet ist. Dies sollte überprüft werden. Wenn der SecPKIServer gestartet wurde, kann es sein, dass der Port 25100 belegt ist (beispielsweise nimmt eine Oracle-DB häufig diesen Port ein). Um einen anderen Port zu konfigurieren, müssen Sie zwei Konfigurationsdateien anpassen:

Datei "\SecPKISecAppServer\www\admin\SecPKIAdmin.properties" Eintrag "seccommerce.secappserverport=25100"

Datei "\Tomcat6.0\webapps\modawi\WEB-INF\properties\secpki.properties" Eintrag "seccommerce.secappserverport.0=25100"

Versuchen Sie an diesen Stellen einen anderen Port (z.B. 25200) zu konfigurieren. Danach müssen Sie den Apache Tomcat und den SecPKI-Server neustarten.

Eine weitere Fehlerquelle ist, dass das Init-Script des SecPKIAdmins nicht gestartet wurde (siehe Abschnitt 3.3.2.1 "Datenbank" im "Modawi 2009 Handbuch - Installation") oder dass das eingerichtete Kennwort des Benutzers für die Signaturprüfung fehlerhaft ist.

2) Fehlermeldung: 250.002: seccommerce.secpki.api.SecPKIApiException: communication error: seccommerce.sec.SecExceptionCommunication: authentication error account: 'MODAWI' Status 1016 Status 102

In der "signatureApplication.properties"-Datei ist der PINACCOUNT für den Zugriff von Modawi auf den SecPKIServer konfiguriert. Dieser wurde durch das Skript "1. SecPKIServer_Application_User_Init-Script.txt" durch den SecPKIAdmin angelegt. Der angelegte PINACCOUNT-User muss mit den Einträgen in der "signatureApplication.properties"-Datei übereinstimmen.

Die Datei "secPKI-service-wrapper.conf" muss zu diesem Zweck angepasst werden. Speziell die Einträge für die entsprechende Datenbank müssen einkommentiert werden. Details sind  im "SecPKI_Handbuch" Abschnitt "4.7 SecPKI als Windows-Service starten" beschrieben.

Diese Fehlermeldung bedeutet, dass kein passendes Ausstellerzertifikat dem Mandanten im SecPKIServer zugewiesen wurde. Nähere Informationen dazu können im "Modawi 2009 Handbuch - Installation" im Abschnitt "3.3.4.1.4 Zuordnung der Trustcenter" und "3.3.4.1.5 Hinzufügen von Zertifikaten zu einem Trustcenter" nachgelesen werden.

Der SecPKIServer kümmert sich nicht nur um die Signaturprüfung, sondern auch um die Signaturerhaltung. Dafür wird ein Signaturerhaltung-Archiv vom SecPKIServer geführt. Die Signaturerhaltung erfolgt auf der Basis einer regelmäßigen Übersignatur von Hashbäumen, die aus den in den Dokumenten enthaltenen Signaturen erstellt werden.

Für die Übersignatur sind sogenannte Zeitstempel erforderlich, um den Zeitpunkt der Signatur verbindlich und rechtssicher festzuhalten. Die Zeitstempel wiederum werden von Trustcentern als Zusatzdienste angeboten.

Das Dokument wird für die Übermittlung von Modawi an den AWI-Client BASE64 kodiert. Je nach Einbindung der Modawi-Schnittstelle in das AWI-System liegt das Dokument entweder BASE64 kodiert oder als Binärdaten vor. Der SecSigner kann entweder als Applet oder über die eigene API angesprochen werden. Für das Applet wird das Dokument Base64 kodiert benötigt. Die SecSigner-API benötigt die Binärdaten des Dokuments.

Das folgende PDF-Dokument beschreibt den Vorgang beim Einrichten eines Software-Zertifikats: "Modawi_3_2_Einrichtung_Softwarezertifikate.pdf"

Bei Gateway-Zertifikaten liefern die Trustcenter leider keine vollständigen Softtoken (oder Keystore-Dateien) aus. Um den Antrag für das Gateway-Zertifikat beim Trustcenter stellen zu können, müssten Sie ein Vorgehen ähnlich dem unten unter 1. beschriebenen einschlagen:

1. Erzeugung des Certificate Signing Request
Zunächst müssen Sie ein CSR (Certificate Sign Request) erzeugen und läßt diesen von der CA signieren. Das signierte Zertifikat wird dann in ein PKCS12 Zertifikat konvertiert. Der Client erzeugt einen CSR:

openssl req -new -keyout client-req.csr -out client-req.csr -days 365

Hier werden der private Schlüssel sowie der CSR in die gleiche Datei geschrieben (das muss nicht zwingend so sein). Wenn möglich sollte der private Schlüssel getrennt vom Zertifikat gehandhabt werden und das lokale System nicht verlassen. Er wird später für die Konvertierung in das pkcs12 Format (Dateiendung .p12) benötigt.

2. CSR wird an das Trustcenter übermittelt
Das Trustcenter signiert den CSR und liefert das signierte Zertifikat zurück.

3. Erzeugung einer p12-Datei aus Zertifikat und privatem Schlüssel
Für die Kommunikation mit der ZKS und andere Zwecke wird ein Keystore im pkcs12 Format (.p12 oder .pfx) benötigt. Dieses kann aus dem Zertifikat und der Datei mit dem CSR mit dem folgenden Kommandoaufruf erzeugt werden:

openssl pkcs12 -export -in client-cert.pem -inkey client-cert.csr \
-out client-cert.p12 -name "Inhabername"

Hier wird noch einmal die CSR-Datei benötigt, welche zusätzlich den diesem Zertifikat zugeordneten privaten Schlüssel enthält.

Es gibt zwei Möglichkeiten, wie neue Signaturkartenbenutzer im SecPKIServer eingerichtet werden können:

Über den Sign-On Client kann sich der Benutzer selbst mit seiner Smartcard am SecPKIServer anmelden. Dazu muss über den Browser eine vorgegebene Adresse aufgerufen werden, über die der Client gestartet werden kann. Nach der Anmeldung kann der Administrator den Benutzer freischalten. Nähere Informationen zum Sign-On Client finden sich im SecPKIServer Handbuch.

Eine weitere Möglichkeit besteht darin, mithilfe des SecPKIAdmin neue Signaturkartenbenutzer anzulegen. Dazu bietet der SecPKIAdmin auf seiner Startseite die Möglichkeit, einen neuen Zugang (Button „Zugang anlegen“) anzulegen. Dieser Vorgang muss anhand der Signaturkarte des neuen Benutzers selbst durchgeführt werden.

Die Datei "secPKI-service-wrapper.conf" muss zu diesem Zweck angepasst werden. Details sind  im "SecPKI_Handbuch" Abschnitt "4.7 SecPKI als Windows-Service starten" beschrieben.

Die Signaturprüfung wird durch den SecPKIServer durchgeführt. Ob für jede Signaturprüfung eine OCSP-Abfrage (Online Certificate Status Protocol), eine Kontrolle der Sperrlisten (CRLs - Certificate Revocation List`s) oder keine Prüfung erfolgen soll, kann in der Konfiguration des SecPKIServers festgelegt werden.

Wir empfehlen eine OCSP-Abfrage und im Falle der Nichterreichbarkeit des Trustcenters eine Prüfung gegen die Sperrliste. Mit dieser Einstellung liefern wir den SecPKIServer aus.

Der Zeitstempel wird nur für das Übersignieren der Hashwerte im Signatur-Archiv benötigt. Dabei wird in einer Signatur die Uhrzeit vom Rechner gespeichert.

Bitte hier klicken für eine vergrößerte Darstellung.

Bitte klicken Sie hier für eine vergrößerte Darstellung.

Die Sperrlisten werden in der Datenbank des SecPKIServers gespeichert. Der Download der Sperrlisten erfolgt über den SecPKIAdmin, als Administrationsoberfläche des SecPKIServers. Über den SecPKIAdmin kann ein automatisierter Download der Sperrlisten konfiguriert werden, da diese regelmäßig aktualisiert werden sollten.

Zu beachten ist, dass die Sperrlisten sowohl von den Trustcentern als auch der Bundesnetzagentur (BNetzA) geladen werden müssen. Die Trustcenter bieten eine Downloadmöglichkeit per HTTP, wohingegen die BNetzA ausschließlich einen Zugang per LDAP zur Verfügung stellt. Dieser Umstand muss in der Administration der Firewall und dem Proxy-Server berücksichtigt werden.

Spätestens bevor ein Hashwert- oder Signatur-Algorithmus ungültig wird, ist eine Übersignatur mit einem zukunftssicheren Verfahren erforderlich. Grundsätzlich sollten Übersignaturen aber auch automatisch in bestimmten Abständen erfolgen, um sicherzustellen, dass gespeicherte Signaturen vor dem Ablaufen des jeweils verwendeten Zertifikats oder einer Sperrung des Zertifikats durch eine Übersignatur abgesichert sind.