SignServer 3.6 brings great improvements in both crypto token configuration and management. There is now the advantage of single crypto token configuration and, related to this, re-keying has become far more convenient.
In previous versions, the necessity to configure keystores (soft or PKCS#11) in each worker resulted in duplicated configuration. The repetitive steps couldn't be avoided even when all workers shared the same keystore or HSM slot.
From version 3.6 there is separation between worker and crypto token configuration, which eliminates duplicate configuration entirely. You simply set up a single crypto worker (a special type of worker). Other workers, using key-pairs in the same keystore or HSM slot, will then point to the singly configured crypto worker.
To everyone's satisfaction rekeying has improved as of version 3.6. Crypto workers now stay active as the keying process does not change the configuration of the crypto token. Entirely superfluous, special measures to avoid production halt are now history.
In practice, the process of rekeying (generating a new key-pair and getting a new certificate for it) always has to be done before the signer's certificate expires. In the Admin GUI every operation is accessed in the tool bar, from the corresponding buttons (screen shot below) which basically follow these five steps:
You can also get more information by writing "complete" instead of "brief" or by using the Admin GUI:
Single crypto token configuration
As crypto token configuration in SignServer 3.6 is now done in a single spot, management has become significantly simpler.In previous versions, the necessity to configure keystores (soft or PKCS#11) in each worker resulted in duplicated configuration. The repetitive steps couldn't be avoided even when all workers shared the same keystore or HSM slot.
From version 3.6 there is separation between worker and crypto token configuration, which eliminates duplicate configuration entirely. You simply set up a single crypto worker (a special type of worker). Other workers, using key-pairs in the same keystore or HSM slot, will then point to the singly configured crypto worker.
 |
| One crypto token and multiple workers |
 |
| Crypto token referenced from another worker |
Rekeying without production stop
Achieving rekeying without production stop used to be a bit of a hassle. Special care had to be taken to ensure that at least one signer was available to handle emerging requests.To everyone's satisfaction rekeying has improved as of version 3.6. Crypto workers now stay active as the keying process does not change the configuration of the crypto token. Entirely superfluous, special measures to avoid production halt are now history.
In practice, the process of rekeying (generating a new key-pair and getting a new certificate for it) always has to be done before the signer's certificate expires. In the Admin GUI every operation is accessed in the tool bar, from the corresponding buttons (screen shot below) which basically follow these five steps:
- Activate the worker
- Renew the key-pair
- Test the key-pair
- Generate CSR
- Install certificates
 |
| AdminGUI toolbar |
Step 2 previously put the worker in an off-line state but with the new crypto worker configuration this is not the case, and it can thus stay active at all times, greatly facilitating re-keying in production.
Trying it out
Let's configure a PDF signer which uses keys provided by a crypto worker.
Set up a new crypto worker configuration by copying the sample config file:
Set up a new crypto worker configuration by copying the sample config file:
$ cp doc/sample-configs/keystore-crypto-configuration.properties \ my-crypto-config.properties
Edit my-crypto-config.properties by changing the keystore path to point to the sample keystore provided:
GLOB.WORKERGENID1.CLASSPATH=\
org.signserver.server.signers.CryptoWorker
GLOB.WORKERGENID1.SIGNERTOKEN.CLASSPATH=\
org.signserver.server.cryptotokens.KeystoreCryptoToken
WORKERGENID1.NAME=CryptoTokenP12
WORKERGENID1.KEYSTORETYPE=PKCS12
WORKERGENID1.KEYSTOREPATH=\
/opt/signserver/res/test/dss10/dss10_signer1.p12
Apply the configuration (replace WORKERID with ID printed):
$ bin/signserver setproperties my-crypto-config.properties
$ bin/signserver reload WORKERID
Activate the crypto token in the crypto worker (password is "foo123"):
$ bin/signserver activatecryptotoken CryptoTokenP12
Set up a new PDF signer using your newly activated crypto worker:
$ cp doc/sample-configs/qs_pdfsigner_configuration.properties\ my-pdf-config.properties
Set my-pdf-config.properties to point to the crypto worker:
GLOB.WORKERGENID1.CLASSPATH=\
org.signserver.module.pdfsigner.PDFSigner
WORKERGENID1.NAME=PDFSigner
WORKERGENID1.AUTHTYPE=NOAUTH
WORKERGENID1.CRYPTOTOKEN=CryptoTokenP12
Apply the configuration (replace WORKERID with ID printed):
$ bin/signserver setproperties my-pdf-config.properties
$ bin/signserver reload WORKERID
View the status of the workers:
$ bin/signserver getstatus brief all
Current version of server is : SignServer CE 3.6.2 Status of CryptoWorker with id 1 (CryptoTokenP12) is: Worker status : Active Token status : Active Status of Signer with id 2 (PDFSigner) is: Worker status : Active Token status : Active Signings : 0
You can also get more information by writing "complete" instead of "brief" or by using the Admin GUI:
$ bin/signserver-gui
Posts
