Skip to content

SignServer: a Java framework for centralised cryptographic operations

SignServer is an application framework written in Java that performs cryptographic operations on behalf of other applications. Instead of teaching every application in your organisation how to talk to a hardware security module, you run one signing service and let the others call it.

That is useful in two situations in particular: when the keys have to live in hardware that the existing enterprise applications cannot be connected to, and when the operations are sensitive enough that you want them managed and audited in exactly one place.

This post was written in 2008 and describes SignServer 3.x. The project is still maintained — it was developed by PrimeKey, the company behind EJBCA, which has since become part of Keyfactor, and the community edition is developed in the open at github.com/Keyfactor/signserver-ce. The feature list below reflects the state in 2008; the deployment model, the supported tokens and the administration interfaces have changed considerably since then.

What It Ships With

Out of the box, SignServer 3.0 provided a number of ready-to-use workers:

  • a time stamp authority compliant with RFC 3161
  • a PDF signer
  • an MRTD signer, for machine readable travel documents
  • a validation service framework
  • a group key service framework
  • a simple mail signer, for signing outgoing email

The server was designed for high availability and can be clustered.

Signing Tokens

The key material itself is held in what SignServer calls a sign token, and the framework abstracts over several kinds:

  • soft tokens backed by a PKCS#12 keystore
  • PKCS#11 HSM tokens, such as the Utimaco CryptoServer or the nCipher nShield
  • smart cards, via PrimeCardHSM

The soft token is the one to start with: it lets you set up and test the whole signing workflow on a laptop, and swapping it for a PKCS#11 token later is a configuration change rather than a rewrite.