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
2 comments:
hello i installed signserver build succesful but i have this problem in signer setup
[root@localhost signserver-ce-3.6.2]# bin/signserver setproperties my-crypto-config.properties
Configuring properties as defined in the file : my-crypto-config.properties
Exception in thread "main" org.signserver.cli.spi.UnexpectedCommandFailureException: java.lang.IllegalStateException: No EJB receiver available for handling [appName:signserver,modulename:SignServer-ejb,distinctname:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@eb5a4f6
at org.signserver.admin.cli.defaultimpl.SetPropertiesCommand.execute(SetPropertiesCommand.java:57)
at org.signserver.cli.CommandLineInterface.execute(CommandLineInterface.java:97)
at org.signserver.admin.cli.AdminCLI.main(AdminCLI.java:51)
Caused by: java.lang.IllegalStateException: No EJB receiver available for handling [appName:signserver,modulename:SignServer-ejb,distinctname:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@eb5a4f6
at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:584)
at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:119)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104)
at com.sun.proxy.$Proxy0.genFreeWorkerId(Unknown Source)
at org.signserver.admin.cli.defaultimpl.SetPropertiesHelper.getGenId(SetPropertiesHelper.java:121)
at org.signserver.admin.cli.defaultimpl.SetPropertiesHelper.processWorkerProperty(SetPropertiesHelper.java:101)
at org.signserver.admin.cli.defaultimpl.SetPropertiesHelper.processKey(SetPropertiesHelper.java:77)
at org.signserver.admin.cli.defaultimpl.SetPropertiesHelper.processKey(SetPropertiesHelper.java:57)
at org.signserver.admin.cli.defaultimpl.SetPropertiesHelper.process(SetPropertiesHelper.java:48)
at org.signserver.admin.cli.defaultimpl.SetPropertiesCommand.execute(SetPropertiesCommand.java:52)
... 2 more
Can you help me thinks
Hi, it's best if you contact the Community mailing list, or PrimeKey.
See http://www.signserver.org/ for details.
Cheers,
Tomas
Post a Comment