The following provides troubleshooting tips to help you get back on track and includes solutions or workarounds for common errors.
To troubleshoot unexpected behavior in SignServer, enable more detailed (debug) logging by running the following command in the JBoss CLI:
- Start JBoss CLI:
- Run the following commands to enable DEBUG logging:
/subsystem=logging/logger=org.ejbca:write-attribute(name=level, value=DEBUG) /subsystem=logging/logger=org.cesecore:write-attribute(name=level, value=DEBUG) /subsystem=logging/logger=org.signserver:write-attribute(name=level, value=DEBUG)CODE
Transaction rolled back error
A transaction timeout can occur for requests that are taking longer time to finish than what is configured for database transactions in the application server.
Example of errors displayed in the log:
13:21:17,483 ERROR [org.jboss.as.ejb3.invocation] (http-/0.0.0.0:8443-1) JBAS014134: EJB Invocation failed on component ProcessSessionBean for method public abstract org.signserver.common.data.Response org.signserver.ejb.interfaces.ProcessSessionLocal.process(org.signserver.server.log.AdminInfo,org.signserver.common.WorkerIdentifier,org.signserver.common.data.Request,org.signserver.common.RequestContext) throws org.signserver.common.IllegalRequestException,org.signserver.common.CryptoTokenOfflineException,org.signserver.common.SignServerException: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back ... Caused by: javax.transaction.RollbackException: JBAS014585: Transaction 'TransactionImple < ac, BasicAction: 0:ffff7f000001:672b819:5911a12e:f8 status: ActionStatus.ABORTED >' was already rolled back at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:99) [jboss-as-ejb3-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] ... 100 more
Possible reasons include large file uploads and/or downloads, and/or slow network connections, slow HSM connection or HSM, or that contacting external servers takes a long time (CRL/OCSP fetching or time-stamping etc).
- Since database transactions are not required if the worker is not configured to access the database, disabling the Limiting the number of signatures and Archiving. , and not using any s will resolve this issue. For more information, see
- Alternatively, if the Limiting the number of signatures and Archiving. or an must be used, reconfigure the application server with a higher value for the transaction timeout. For more information, see
P11NG / JackNJI11
There can be a conflict between the JNA implementation in SignServer and the one installed in the system. This can be seen as errors similar to the following:
- java.lang.UnsatisfiedLinkError: com.sun.jna.Native.malloc(J)J
- java.lang.UnsatisfiedLinkError: Can't obtain static newInstance method for class com.sun.jna.Structure
The solution is to remove JNA from the system (i.e. apt-get remove libjna-java) or to run Java with:
If a USER_NOT_LOGGED_IN error is encountered while using the Utimaco HSM, the solution is to enable the KeepAlive setting in the Utimaco configuration file
# Prevents expiring session after inactivity of 15 minutes KeepAlive = true
Cannot Produce CertificateVerify Signature
When using SignClient using a PKCS 11 token (e.g. a smart-card reader) for authenticating in some cases (e.g. both server and client running on Java 11) a cipher-suit-related error can occur:
ERROR [HTTPDocumentSigner] Failed sending request: Cannot produce CertificateVerify signature
As a workaround, SignClient can be forced to fall back to using TLS version 1.1 (as shown in the commented-out sample in script bin/signclient, a similar example is also present in the Windows batch file bin/signclient.cmd)
# In some cases, running SignClient authenticating with a P11 token # (e.g. a smartcard reader) could give cipher-suit errors, # In these cases, a workaround is to force the use of TLS version 1.1 JAVA_OPTS="$JAVA_OPTS -Djdk.tls.client.protocols=TLSv1.1 -Dhttps.protocols=TLSv1.1"
The SignServer Administration GUI is as of SignServer 5.2 deprecated in Signserver Enterprise and removed in the Community edition.
AdminGUI login using smartcard fails on 64-bit (x86_64) version of Windows
The 64-bit version of Oracle Java does not support PKCS#11. On Windows, use a 32-bit version of Java and the PKCS#11 shared library.
AdminGUI login using smartcard fails if path to DLL contains parenthesis
On versions prior to JDK 7u80 and 8 b91, the Java bug JDK-7196009 will cause issues with configuration paths containing parenthesis, for example:
c:\program files (x86)\middleware\pkcs11.dll.
As a workaround, make sure to install the middle-ware (PKCS#11/smartcard library) to a path not containing parenthesis.
IPv6 dualstack can give permission denied when trying to connect from AdminGUI
Connecting to SignServer over web services using the AdminGUI on Windows where both IPv4 and IPv6 are available, can give "permission denied".
As a workaround, edit the
signserver-gui.cmd and add the following to the command:
AdminGUI login using smartcard fails with some cards
The card prompts for the PIN but then does not ask for which certificate to login with. Instead, the following error message is shown: Received fatal alert: bad_certificate. The error message indicates that the server did not accept the provided certificate (that is the issuer was not in the server's truststore). However, for certain types of smartcards, the issue is caused by an inability to read a certificate from the card.
As a workaround, do the following:
- Start the GUI without the card inserted.
- Press Connect (without the card inserted).
- Ignore the error message slotListIndex is 0 but token has 0 slots.
- Insert the card and press Connect again.
- This time, after the PIN prompt you are asked for which certificate to login with.