Menu
▾
▴
signserver-develop
You can subscribe to this list here.
| 2008 |
Jan
(1) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(4) |
Dec
|
| 2010 |
Jan
(1) |
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2012 |
Jan
(1) |
Feb
(8) |
Mar
(10) |
Apr
|
May
(12) |
Jun
(2) |
Jul
(28) |
Aug
(15) |
Sep
(12) |
Oct
(2) |
Nov
|
Dec
(16) |
| 2013 |
Jan
(30) |
Feb
(1) |
Mar
|
Apr
(11) |
May
(2) |
Jun
(11) |
Jul
(15) |
Aug
(4) |
Sep
(1) |
Oct
(10) |
Nov
(1) |
Dec
(2) |
| 2014 |
Jan
(8) |
Feb
(13) |
Mar
(12) |
Apr
(24) |
May
(2) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(2) |
Oct
(1) |
Nov
(2) |
Dec
(1) |
| 2015 |
Jan
(3) |
Feb
(6) |
Mar
|
Apr
|
May
(7) |
Jun
(7) |
Jul
(3) |
Aug
(5) |
Sep
(1) |
Oct
(8) |
Nov
(6) |
Dec
|
| 2016 |
Jan
|
Feb
(3) |
Mar
(5) |
Apr
(9) |
May
(26) |
Jun
(8) |
Jul
|
Aug
|
Sep
(11) |
Oct
(8) |
Nov
(1) |
Dec
(2) |
| 2017 |
Jan
(4) |
Feb
(7) |
Mar
(7) |
Apr
(4) |
May
(1) |
Jun
(5) |
Jul
(3) |
Aug
(3) |
Sep
(1) |
Oct
(4) |
Nov
(5) |
Dec
(1) |
| 2018 |
Jan
(4) |
Feb
(1) |
Mar
(1) |
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(2) |
Dec
|
| 2020 |
Jan
(3) |
Feb
|
Mar
(2) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2025 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Markus K. <ma...@pr...> - 2017-01-09 09:37:03
|
On 01/06/2017 04:33 PM, Jose Alberto wrote: > Hi. > > I am use SignServer 4.0, i have integrate with HSM for pkcs11. > > And various worker. all work fine. without problem. > > > For this moment, my certificate for https copy from PKI (EJBCA). > tomcat.keystore and trusstore.keystore And i use the certificate pcks12 > of EJBCA. for solve the autentication. > > > The Problem: I want generate certificate personalized for https of > SignServer. But always error on Firefox (always chrome and IE) for > example: > > SEC_ERROR_INADEQUATE_KEY_USAGE > > > I use keytool, generate csr for csr upload on ejbca, ejbca download > jks, but no run. > > I use direct ejbca, download jks, but no run. > > > What is the process for generate SSL for Jboss using EJBCA? > > Thanks. > > Sorry for my English. > > -- > ############################# > # Sistema Operativo: Debian # > # Caracas, Venezuela # > ############################# > Hi Jose, It sounds like the certificate you have issued are not valid for TLS server authentication. Probably it is missing the appropriate key usage and/or the external key usage for TLS server authentication. This is more of an EJBCA mailing list question I suppose but when issuing your certificate from EJBCA you can use the SERVER certificate profile (or a profile cloned from it). That profile should already have working key usage and extended key usage set. Cheers, Markus Save time and money with an Enterprise support subscription. Please see www.primekey.se for more information. https://www.primekey.se/technologies/products-overview/ https://www.primekey.se/service-support/support/ RSA(R) Conference 2017 ---------------------- San Francisco | February 13-17 | Moscone Center Come visit us in booth #627 at RSA Conference 2017! Want a free expo pass? Click https://www.rsaconference.com/events/us17/register and use the code: XE7PRMKEY |
|
From: Jose A. <j....@gm...> - 2017-01-06 15:33:12
|
Hi. I am use SignServer 4.0, i have integrate with HSM for pkcs11. And various worker. all work fine. without problem. For this moment, my certificate for https copy from PKI (EJBCA). tomcat.keystore and trusstore.keystore And i use the certificate pcks12 of EJBCA. for solve the autentication. The Problem: I want generate certificate personalized for https of SignServer. But always error on Firefox (always chrome and IE) for example: SEC_ERROR_INADEQUATE_KEY_USAGE I use keytool, generate csr for csr upload on ejbca, ejbca download jks, but no run. I use direct ejbca, download jks, but no run. What is the process for generate SSL for Jboss using EJBCA? Thanks. Sorry for my English. -- ############################# # Sistema Operativo: Debian # # Caracas, Venezuela # ############################# |
|
From: Markus K. <ma...@pr...> - 2016-12-20 11:56:25
|
On 12/18/2016 10:12 PM, Jaime Hablutzel wrote: > To the date (December 2016), are there any plans to support officialy > TW4S oficially in any of its sole control levels?. > Hi Jaime, It is currently not planned on the road map. However, the road map could change if there is a customer demand or if someone is willing to support the development either financially and/or by contributing patches. We have not yet looked into the details regarding what would be needed to implement something like this. Suggestions are welcome. > Hi Markus > > Best thanks for your response. I think is correct, that level 2 sole control > must be supported by the SSCD or HSM if you consider the Slide 15. What's > about the slide 17? If I understand slide 17 right, level 2 sole control can > also implemented with a "simpler" shaping, because the signing server is > responsible for the multi factor authentication of the signer. The SSCD > itself is "only" responsible for nonce creation and the validation of the > nonce + 1 factor SAD hash and DTBS (e.g. document hash). Under the adoption > that a SSCD supports level 2 sole control, does the SignServer is able to > produces signed hashes with level 2 sole control by default? If not, what > has to be modified and what are the estimated effort? > > Cheers, > André > Cheers, Markus PrimeKey Solutions Save time and money with an Enterprise support subscription. Please see www.primekey.se for more information. https://www.primekey.se/technologies/products-overview/ https://www.primekey.se/service-support/support/ |
|
From: Jaime H. <hab...@gm...> - 2016-12-18 21:12:35
|
To the date (December 2016), are there any plans to support officialy TW4S oficially in any of its sole control levels?. Hi Markus Best thanks for your response. I think is correct, that level 2 sole control must be supported by the SSCD or HSM if you consider the Slide 15. What's about the slide 17? If I understand slide 17 right, level 2 sole control can also implemented with a "simpler" shaping, because the signing server is responsible for the multi factor authentication of the signer. The SSCD itself is "only" responsible for nonce creation and the validation of the nonce + 1 factor SAD hash and DTBS (e.g. document hash). Under the adoption that a SSCD supports level 2 sole control, does the SignServer is able to produces signed hashes with level 2 sole control by default? If not, what has to be modified and what are the estimated effort? Cheers, André -----Ursprüngliche Nachricht----- Von: Markus Kilås [mailto:markus@...] Gesendet: Montag, 4. April 2016 10:08 An: signserver-develop@... Betreff: Re: [SignServer-develop] SigServer - Level 2 sole control On 03/31/2016 09:34 AM, André Clerc wrote: > Dear SignServer developper > > > > On behalf of a customer, I send you this e-mail because he is > interested in a signing solution. Unlike to CRS, where a CA creates > and sign certificates, the customer would like to have signed hash values (e.g.: > hash of a document, code, etc.). These hash values refer to a document > will be produced by an external application (please see illustration > below or in the attachment). > > > > cid:image002.png@... > > > > > > As a special criteria the customer is interested in particular for a > possible implementation of the *level 2 sole control* regarding TS 419 > 241 respectively EN 419 241. Our understanding with respect to level 2 > sole control have I added to the PS. If EJBCA dose currently not > support level 2 sole control, what is the size of the estimated > effort/cost and what kind problems there are still to be resolved. > > > > Your sincerely > > André Clerc > > > > *PS:*Our understanding with respect to Level 2 Sole Control is such > that, a commitment to release a signature have to be protect by > multiple factors. One allowed way for a multi-factor authentication is > provided by the signature creation device itself. Another method is a > multi-factor authentication of the signer by the server signing > application followed by a commitment protect by 1 factor (please > review the attached diagram in the slide 13 and 17) in a secure way. > Hi André, I have only had a quick look but from what I have seen I agree with your understanding that in the level 2 you would need to have some support for this provided by the SSCD itself. I am not sure what devices exists with this functionality though. Cheers, Markus > > > > > > > -- > > André Clerc > > Expert IT Security Consultant > > > > *TEMET AG* > > Basteiplatz 5, CH-8001 Zürich > > T: +41 79 222 22 54 | Büro: +41 44 302 24 42 > > andre.clerc@... <mailto:andre.clerc@...>|http://www.temet.ch <http://www.temet.ch/> > <http://www.temet.ch/> <http://www.temet.ch/%3E>; ---------------------------------------------------------------------------- -- _______________________________________________ SignServer-develop mailing list SignServer-develop@... https://lists.sourceforge.net/lists/listinfo/signserver-develop |
|
From: Markus K. <ma...@pr...> - 2016-11-01 15:00:08
|
On 10/31/2016 06:50 PM, Jose Alberto wrote: > On Mon, Oct 31, 2016 at 6:02 AM, Markus Kilås <ma...@pr... > <mailto:ma...@pr...>> wrote: > > On 10/31/2016 01:08 AM, Jose Alberto wrote: > > Hi. > > > > > > I Use SignServer 4.0 on Debian 8 amd64 with mariadb. > > > > The problem is when page demo, i tried upload pdf. ===>>> signed > ====> > > download pdf, and open with acrobat reader, show error in the > > certificate. > > > > signserver getstatus brief all > > Current version of server is : SignServer CE 4.0.0 > > > > Status of CryptoWorker with id 1 (CryptoTokenP11) is: > > Worker status : Active > > Token status : Active > > > > Status of Signer with id 2 (PDFSigner) is: > > Worker status : Offline > > Token status : Active > > Signings : 0 > > > > Errors: > > - Certificate does not match key > > - Key usage limit exceeded or not initialized > > > > > > > > The certificate is on another PKI. But the request (csr) Must > > generate from server on pkcs11? > > > > > > > > My HSM is Utimaco Lan. > > > > Thanks, sorry for my english. > > > > > > Jose A > > > > Hi Jose, > Yes, the error shown in the PDF Reader is most likely because the error > in the PDFSigner. > > The error "certificate does not match key" means that the certificate > installed for the PDFSigner is not for the key in the crypto token. > > When you get a certificate for the key you need to make sure the CSR is > generated using the key the PDFSigner will be using. > Check in your PDFSigner that you have: > - CRYPTOTOKEN=CryptoTokenP11 > - DEFAULTKEY with the name of the key you want to use > > Then generate the CSR using CLI or GUI and make sure the name of the > right key is specified. > > Then finally when you get the certificate, install it in the PDFSigner. > > There is no idea trying to sign anything until the "Worker status" is > "Active". > > > Regards, > Markus Kilås > PrimeKey Solutions > > Save time and money with an Enterprise support subscription. Please see > www.primekey.se <http://www.primekey.se> for more information. > https://www.primekey.se/technologies/products-overview/ > <https://www.primekey.se/technologies/products-overview/> > https://www.primekey.se/service-support/support/ > <https://www.primekey.se/service-support/support/> > > Thanks Markus. > > I Solve generated request (csr) from signserver pkcs11. > > signserver generatecertreq 1 "C=US,CN=firma" SHA256WithRSA peticion.csr > > My result: > > signserver getstatus brief all > Current version of server is : SignServer CE 4.0.0 > > > Status of CryptoWorker with id 1 (CryptoTokenP11) is: > Worker status : Active > Token status : Active > > Status of Signer with id 2 (PDFSigner) is: > Worker status : Active > Token status : Active > Signings : 0 > Great that it is working. Cheers, Markus -- Kind regards, Markus Kilås PKI Specialist PrimeKey Solutions AB Lundagatan 16 SE-171 63 Solna Sweden Phone: +46 70 424 94 85 Email: mar...@pr... https://www.primekey.se |
|
From: Jose A. <j....@gm...> - 2016-10-31 17:50:33
|
Thanks Markus. I Solve generated request (csr) from signserver pkcs11. signserver generatecertreq 1 "C=US,CN=firma" SHA256WithRSA peticion.csr My result: signserver getstatus brief all Current version of server is : SignServer CE 4.0.0 Status of CryptoWorker with id 1 (CryptoTokenP11) is: Worker status : Active Token status : Active Status of Signer with id 2 (PDFSigner) is: Worker status : Active Token status : Active Signings : 0 On Mon, Oct 31, 2016 at 6:02 AM, Markus Kilås <ma...@pr...> wrote: > On 10/31/2016 01:08 AM, Jose Alberto wrote: > > Hi. > > > > > > I Use SignServer 4.0 on Debian 8 amd64 with mariadb. > > > > The problem is when page demo, i tried upload pdf. ===>>> signed ====> > > download pdf, and open with acrobat reader, show error in the > > certificate. > > > > signserver getstatus brief all > > Current version of server is : SignServer CE 4.0.0 > > > > Status of CryptoWorker with id 1 (CryptoTokenP11) is: > > Worker status : Active > > Token status : Active > > > > Status of Signer with id 2 (PDFSigner) is: > > Worker status : Offline > > Token status : Active > > Signings : 0 > > > > Errors: > > - Certificate does not match key > > - Key usage limit exceeded or not initialized > > > > > > > > The certificate is on another PKI. But the request (csr) Must > > generate from server on pkcs11? > > > > > > > > My HSM is Utimaco Lan. > > > > Thanks, sorry for my english. > > > > > > Jose A > > > > Hi Jose, > Yes, the error shown in the PDF Reader is most likely because the error > in the PDFSigner. > > The error "certificate does not match key" means that the certificate > installed for the PDFSigner is not for the key in the crypto token. > > When you get a certificate for the key you need to make sure the CSR is > generated using the key the PDFSigner will be using. > Check in your PDFSigner that you have: > - CRYPTOTOKEN=CryptoTokenP11 > - DEFAULTKEY with the name of the key you want to use > > Then generate the CSR using CLI or GUI and make sure the name of the > right key is specified. > > Then finally when you get the certificate, install it in the PDFSigner. > > There is no idea trying to sign anything until the "Worker status" is > "Active". > > > Regards, > Markus Kilås > PrimeKey Solutions > > Save time and money with an Enterprise support subscription. Please see > www.primekey.se for more information. > https://www.primekey.se/technologies/products-overview/ > https://www.primekey.se/service-support/support/ > > > ------------------------------------------------------------ > ------------------ > The Command Line: Reinvented for Modern Developers > Did the resurgence of CLI tooling catch you by surprise? > Reconnect with the command line and become more productive. > Learn the new .NET and ASP.NET CLI. Get your free copy! > http://sdm.link/telerik > _______________________________________________ > SignServer-develop mailing list > Sig...@li... > https://lists.sourceforge.net/lists/listinfo/signserver-develop > -- ############################# # Sistema Operativo: Debian # # Caracas, Venezuela # ############################# |
|
From: Markus K. <ma...@pr...> - 2016-10-31 10:03:09
|
On 10/31/2016 01:08 AM, Jose Alberto wrote: > Hi. > > > I Use SignServer 4.0 on Debian 8 amd64 with mariadb. > > The problem is when page demo, i tried upload pdf. ===>>> signed ====> > download pdf, and open with acrobat reader, show error in the > certificate. > > signserver getstatus brief all > Current version of server is : SignServer CE 4.0.0 > > Status of CryptoWorker with id 1 (CryptoTokenP11) is: > Worker status : Active > Token status : Active > > Status of Signer with id 2 (PDFSigner) is: > Worker status : Offline > Token status : Active > Signings : 0 > > Errors: > - Certificate does not match key > - Key usage limit exceeded or not initialized > > > > The certificate is on another PKI. But the request (csr) Must > generate from server on pkcs11? > > > > My HSM is Utimaco Lan. > > Thanks, sorry for my english. > > > Jose A > Hi Jose, Yes, the error shown in the PDF Reader is most likely because the error in the PDFSigner. The error "certificate does not match key" means that the certificate installed for the PDFSigner is not for the key in the crypto token. When you get a certificate for the key you need to make sure the CSR is generated using the key the PDFSigner will be using. Check in your PDFSigner that you have: - CRYPTOTOKEN=CryptoTokenP11 - DEFAULTKEY with the name of the key you want to use Then generate the CSR using CLI or GUI and make sure the name of the right key is specified. Then finally when you get the certificate, install it in the PDFSigner. There is no idea trying to sign anything until the "Worker status" is "Active". Regards, Markus Kilås PrimeKey Solutions Save time and money with an Enterprise support subscription. Please see www.primekey.se for more information. https://www.primekey.se/technologies/products-overview/ https://www.primekey.se/service-support/support/ |
|
From: Jose A. <j....@gm...> - 2016-10-31 00:08:58
|
Hi.
I Use SignServer 4.0 on Debian 8 amd64 with mariadb.
The problem is when page demo, i tried upload pdf. ===>>> signed ====>
download pdf, and open with acrobat reader, show error in the
certificate.
signserver getstatus brief all
Current version of server is : SignServer CE 4.0.0
Status of CryptoWorker with id 1 (CryptoTokenP11) is:
Worker status : Active
Token status : Active
Status of Signer with id 2 (PDFSigner) is:
Worker status : Offline
Token status : Active
Signings : 0
Errors:
- Certificate does not match key
- Key usage limit exceeded or not initialized
The certificate is on another PKI. But the request (csr) Must
generate from server on pkcs11?
My HSM is Utimaco Lan.
Thanks, sorry for my english.
Jose A
|
|
From: Markus K. <ma...@pr...> - 2016-10-17 16:27:33
|
Ok, great that it solved your problem. I was a bit confused though, and the point I wanted to make was that in my java.security list there is no SunPKCS11 and especially no LunaProvider and that those are not needed to be there for SignServer to work. But it is good to know that in case anyone needs the LunaProvider and SunPKCS11 as providers for some other reason then the order of them are important if I understood correctly. Cheers, Markus On 10/17/2016 05:33 PM, Blum, Jon wrote: > Hello Markus -- > > Did my second email not show up on the list? I sent an update about a > day later. It turns out my problem was twofold -- > > 1) The Luna JSP files needed for integration were in the wrong > directory (a lower subdirectory rather than jre/lib/ext) > 2) The order of the crypto providers was wrong -- the > sun.security.pkcs11.SunPKCS11 provider was missing, and the LunaProvider > was too high up the list > > Now that I've fixed those, the problem is resolved! > > Cheers, > Jon Blum > > On Tue, Oct 18, 2016 at 2:25 AM, Markus Kilås <ma...@pr... > <mailto:ma...@pr...>> wrote: > > Hi Jon, > > I am unable to reproduce the problem with the ProtectServer Emulator. > Both with SLOT_NUMBER and SLOT_LABEL works for me out of the box and I > only get the "Token label 'x' not found error" message for non-existing > label. > > Was the slot initialized (or assigned to the client) while SignServer > was running? In that case you might have to restart it for it to be able > to see the new token label. > > I never add the Luna provider to the java.security provider list. In > fact I don't even install it as SignServer uses PKCS#11 and sets up > SunPKCS11 by it self. > > So that should not be necessary. > > Note though that before SignServer 4 you would have to configure JBoss > to have access to sun.security.pkcs11 etc, see > https://www.signserver.org/doc/3.7.0/manual/installguide.html#JBoss%207/EAP%206%20and%20PKCS11 > <https://www.signserver.org/doc/3.7.0/manual/installguide.html#JBoss%207/EAP%206%20and%20PKCS11> > or use SignServer 4 where this has been fixed in an other way. > > Are you able to try again if you again get the problem if you remove the > providers from the list and restart SignServer? > > > Cheers, > Markus > > On 10/17/2016 07:43 AM, Blum, Jon wrote: > > Update on this -- I seem to have sorted out the problem! It turns out > > two elements were missing: > > > > 1) The Luna JSP files need to be present in the right directory: > > cd /usr/safenet/lunaclient/jsp/lib > > cp -r lib/LunaProvider.jar /usr/java/latest/jre/lib/ext > > cp -r lib/libLunaAPI.so /usr/java/latest/jre/lib/ext > > > > > > 2) The provider order in jre/lib/security/java.security should > have been: > > security.provider.1=sun.security.pkcs11.SunPKCS11 > > ${java.home}/lib/security/luna.cfg > > security.provider.2=sun.security.provider.Sun > > security.provider.3=sun.security.rsa.SunRsaSign > > security.provider.4=sun.security.ec.SunEC > > security.provider.5=com.sun.net.ssl.internal.ssl.Provider > > security.provider.6=com.sun.crypto.provider.SunJCE > > security.provider.7=com.safenetinc.luna.provider.LunaProvider > > (others below) > > > > (Note: I also had to create a luna.cfg file containing the following: > > name=LunaSA > > library=/usr/safenet/lunaclient/lib/libCryptoki2_64.so > > slot=1 > > ) > > > > With these features in place, the Luna SA is accessible both from > Java's > > keytool and from SignServer. > > > > I would note that the documentation is a bit confusing -- I think the > > SignServer documentation assumes that the SunPKCS11 provider is > > installed by default, and the Luna SA documentation only mentions > it in > > a separate PKCS11 Providers Integration Guide! > > > > Cheers, > > Jon Blum > > > > > > > > > > On Mon, Oct 17, 2016 at 11:15 AM, Blum, Jon > <jon...@or... <mailto:jon...@or...> > > <mailto:jon...@or... > <mailto:jon...@or...>>> wrote: > > > > Hi -- I'm having a problem setting up my SignServer to talk to a > > Luna SA HSM. > > > > I've set up SignServer and tested the MRTDSODSigner repeatedly > with > > soft keys, so the rest of its configuration appears to be correct. > > > > The link between the Luna SA and the server is also set up > > correctly; running Luna's VTL tool shows the partition is visible > > like so: > > > > ---- > > [root@localhost bin]# ./vtl verify > > > > The following Luna SA Slots/Partitions were found: > > > > Slot Serial # Label > > ==== ======== ===== > > 1 520030014 epassport > > ---- > > > > But when I try to run SignServer's activatecryptotoken command, I > > get one of two failure results. If I specify the slot name with > > these parameters: > > > > SLOTLABELTYPE=SLOT_NAME > > SLOTLABELVALUE=epassport > > > > then when I run bin/signserver.sh activatecryptotoken, it fails in > > the init function: > > > > ---- > > Trying to activate crypto token of worker with id : 6 > > > > Crypto token is offline: > org.signserver.common.SignServerException: > > Failed to initialize crypto token: Token label 'epassport' not > found. > > ---- > > > > On the other hand, if I specify the slot number or slot index with > > these parameters: > > > > SLOTLABELTYPE=SLOT_NUMBER > > SLOTLABELVALUE=1 > > > > or > > > > SLOTLABELTYPE=SLOT_INDEX > > SLOTLABELVALUE=0 > > > > then the activatecryptotoken command gets past the init function, > > but fails when it actually tries to activate: > > > > ---- > > Trying to activate crypto token of worker with id : 5 > > > > Crypto token authentication failed: Activate failed: Failed to > > initialize PKCS11 provider slot '0'.: KeyStore instantiation > failed: > > PKCS11 not found: no such algorithm: PKCS11 for provider > > SunPKCS11-libCryptoki2_64.so-slot0 > > ---- > > > > In both cases the following lines have been uncommented in > > signserver_deploy.properties: > > > > cryptotoken.p11.lib.20.name <http://cryptotoken.p11.lib.20.name> > > <http://cryptotoken.p11.lib.20.name > <http://cryptotoken.p11.lib.20.name>>=SafeNet Luna SA > > cryptotoken.p11.lib.20.file=/usr/safenet/lunaclient/lib/libCryptoki2_64.so > > > > > > For what it's worth, the server is running CentOS 7 and JDK 1.8. > > And Luna's crypto provider has been added to > > jre/lib/security/java.security: > > > > security.provider.1=sun.security.provider.Sun > > security.provider.2=sun.security.rsa.SunRsaSign > > security.provider.3=com.safenetinc.luna.provider.LunaProvider > > security.provider.4=sun.security.ec.SunEC > > security.provider.5=com.sun.net.ssl.internal.ssl.Provider > > security.provider.6=com.sun.crypto.provider.SunJCE > > security.provider.7=sun.security.jgss.SunProvider > > security.provider.8=com.sun.security.sasl.Provider > > security.provider.9=org.jcp.xml.dsig.internal.dom.XMLDSigRI > > security.provider.10=sun.security.smartcardio.SunPCSC > > > > So... what could be missing, that it's not finding the PKCS11 > > algorithms? > > > > Cheers, > > Jon Blum > > > > > > > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > > > > > > > > _______________________________________________ > > SignServer-develop mailing list > > Sig...@li... > <mailto:Sig...@li...> > > https://lists.sourceforge.net/lists/listinfo/signserver-develop > <https://lists.sourceforge.net/lists/listinfo/signserver-develop> > > > > > > -- > Kind regards, > Markus Kilås > PKI Specialist > > PrimeKey Solutions AB > > Lundagatan 16 > SE-171 63 Solna > Sweden > > Phone: +46 70 424 94 85 <tel:%2B46%2070%20424%2094%2085> > Email: mar...@pr... <mailto:mar...@pr...> > > https://www.primekey.se > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > SignServer-develop mailing list > Sig...@li... > <mailto:Sig...@li...> > https://lists.sourceforge.net/lists/listinfo/signserver-develop > <https://lists.sourceforge.net/lists/listinfo/signserver-develop> > > -- Kind regards, Markus Kilås PKI Specialist PrimeKey Solutions AB Lundagatan 16 SE-171 63 Solna Sweden Phone: +46 70 424 94 85 Email: mar...@pr... https://www.primekey.se |
|
From: Blum, J. <jon...@or...> - 2016-10-17 15:33:51
|
Hello Markus -- Did my second email not show up on the list? I sent an update about a day later. It turns out my problem was twofold -- 1) The Luna JSP files needed for integration were in the wrong directory (a lower subdirectory rather than jre/lib/ext) 2) The order of the crypto providers was wrong -- the sun.security.pkcs11.SunPKCS11 provider was missing, and the LunaProvider was too high up the list Now that I've fixed those, the problem is resolved! Cheers, Jon Blum On Tue, Oct 18, 2016 at 2:25 AM, Markus Kilås <ma...@pr...> wrote: > Hi Jon, > > I am unable to reproduce the problem with the ProtectServer Emulator. > Both with SLOT_NUMBER and SLOT_LABEL works for me out of the box and I > only get the "Token label 'x' not found error" message for non-existing > label. > > Was the slot initialized (or assigned to the client) while SignServer > was running? In that case you might have to restart it for it to be able > to see the new token label. > > I never add the Luna provider to the java.security provider list. In > fact I don't even install it as SignServer uses PKCS#11 and sets up > SunPKCS11 by it self. > > So that should not be necessary. > > Note though that before SignServer 4 you would have to configure JBoss > to have access to sun.security.pkcs11 etc, see > https://www.signserver.org/doc/3.7.0/manual/installguide. > html#JBoss%207/EAP%206%20and%20PKCS11 > or use SignServer 4 where this has been fixed in an other way. > > Are you able to try again if you again get the problem if you remove the > providers from the list and restart SignServer? > > > Cheers, > Markus > > On 10/17/2016 07:43 AM, Blum, Jon wrote: > > Update on this -- I seem to have sorted out the problem! It turns out > > two elements were missing: > > > > 1) The Luna JSP files need to be present in the right directory: > > cd /usr/safenet/lunaclient/jsp/lib > > cp -r lib/LunaProvider.jar /usr/java/latest/jre/lib/ext > > cp -r lib/libLunaAPI.so /usr/java/latest/jre/lib/ext > > > > > > 2) The provider order in jre/lib/security/java.security should have > been: > > security.provider.1=sun.security.pkcs11.SunPKCS11 > > ${java.home}/lib/security/luna.cfg > > security.provider.2=sun.security.provider.Sun > > security.provider.3=sun.security.rsa.SunRsaSign > > security.provider.4=sun.security.ec.SunEC > > security.provider.5=com.sun.net.ssl.internal.ssl.Provider > > security.provider.6=com.sun.crypto.provider.SunJCE > > security.provider.7=com.safenetinc.luna.provider.LunaProvider > > (others below) > > > > (Note: I also had to create a luna.cfg file containing the following: > > name=LunaSA > > library=/usr/safenet/lunaclient/lib/libCryptoki2_64.so > > slot=1 > > ) > > > > With these features in place, the Luna SA is accessible both from Java's > > keytool and from SignServer. > > > > I would note that the documentation is a bit confusing -- I think the > > SignServer documentation assumes that the SunPKCS11 provider is > > installed by default, and the Luna SA documentation only mentions it in > > a separate PKCS11 Providers Integration Guide! > > > > Cheers, > > Jon Blum > > > > > > > > > > On Mon, Oct 17, 2016 at 11:15 AM, Blum, Jon <jon...@or... > > <mailto:jon...@or...>> wrote: > > > > Hi -- I'm having a problem setting up my SignServer to talk to a > > Luna SA HSM. > > > > I've set up SignServer and tested the MRTDSODSigner repeatedly with > > soft keys, so the rest of its configuration appears to be correct. > > > > The link between the Luna SA and the server is also set up > > correctly; running Luna's VTL tool shows the partition is visible > > like so: > > > > ---- > > [root@localhost bin]# ./vtl verify > > > > The following Luna SA Slots/Partitions were found: > > > > Slot Serial # Label > > ==== ======== ===== > > 1 520030014 epassport > > ---- > > > > But when I try to run SignServer's activatecryptotoken command, I > > get one of two failure results. If I specify the slot name with > > these parameters: > > > > SLOTLABELTYPE=SLOT_NAME > > SLOTLABELVALUE=epassport > > > > then when I run bin/signserver.sh activatecryptotoken, it fails in > > the init function: > > > > ---- > > Trying to activate crypto token of worker with id : 6 > > > > Crypto token is offline: org.signserver.common.SignServerException: > > Failed to initialize crypto token: Token label 'epassport' not found. > > ---- > > > > On the other hand, if I specify the slot number or slot index with > > these parameters: > > > > SLOTLABELTYPE=SLOT_NUMBER > > SLOTLABELVALUE=1 > > > > or > > > > SLOTLABELTYPE=SLOT_INDEX > > SLOTLABELVALUE=0 > > > > then the activatecryptotoken command gets past the init function, > > but fails when it actually tries to activate: > > > > ---- > > Trying to activate crypto token of worker with id : 5 > > > > Crypto token authentication failed: Activate failed: Failed to > > initialize PKCS11 provider slot '0'.: KeyStore instantiation failed: > > PKCS11 not found: no such algorithm: PKCS11 for provider > > SunPKCS11-libCryptoki2_64.so-slot0 > > ---- > > > > In both cases the following lines have been uncommented in > > signserver_deploy.properties: > > > > cryptotoken.p11.lib.20.name > > <http://cryptotoken.p11.lib.20.name>=SafeNet Luna SA > > cryptotoken.p11.lib.20.file=/usr/safenet/lunaclient/lib/ > libCryptoki2_64.so > > > > > > For what it's worth, the server is running CentOS 7 and JDK 1.8. > > And Luna's crypto provider has been added to > > jre/lib/security/java.security: > > > > security.provider.1=sun.security.provider.Sun > > security.provider.2=sun.security.rsa.SunRsaSign > > security.provider.3=com.safenetinc.luna.provider.LunaProvider > > security.provider.4=sun.security.ec.SunEC > > security.provider.5=com.sun.net.ssl.internal.ssl.Provider > > security.provider.6=com.sun.crypto.provider.SunJCE > > security.provider.7=sun.security.jgss.SunProvider > > security.provider.8=com.sun.security.sasl.Provider > > security.provider.9=org.jcp.xml.dsig.internal.dom.XMLDSigRI > > security.provider.10=sun.security.smartcardio.SunPCSC > > > > So... what could be missing, that it's not finding the PKCS11 > > algorithms? > > > > Cheers, > > Jon Blum > > > > > > > > > > ------------------------------------------------------------ > ------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > > > > > > > > _______________________________________________ > > SignServer-develop mailing list > > Sig...@li... > > https://lists.sourceforge.net/lists/listinfo/signserver-develop > > > > > > -- > Kind regards, > Markus Kilås > PKI Specialist > > PrimeKey Solutions AB > > Lundagatan 16 > SE-171 63 Solna > Sweden > > Phone: +46 70 424 94 85 > Email: mar...@pr... > > https://www.primekey.se > > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > SignServer-develop mailing list > Sig...@li... > https://lists.sourceforge.net/lists/listinfo/signserver-develop > |
|
From: Markus K. <ma...@pr...> - 2016-10-17 15:25:39
|
Hi Jon, I am unable to reproduce the problem with the ProtectServer Emulator. Both with SLOT_NUMBER and SLOT_LABEL works for me out of the box and I only get the "Token label 'x' not found error" message for non-existing label. Was the slot initialized (or assigned to the client) while SignServer was running? In that case you might have to restart it for it to be able to see the new token label. I never add the Luna provider to the java.security provider list. In fact I don't even install it as SignServer uses PKCS#11 and sets up SunPKCS11 by it self. So that should not be necessary. Note though that before SignServer 4 you would have to configure JBoss to have access to sun.security.pkcs11 etc, see https://www.signserver.org/doc/3.7.0/manual/installguide.html#JBoss%207/EAP%206%20and%20PKCS11 or use SignServer 4 where this has been fixed in an other way. Are you able to try again if you again get the problem if you remove the providers from the list and restart SignServer? Cheers, Markus On 10/17/2016 07:43 AM, Blum, Jon wrote: > Update on this -- I seem to have sorted out the problem! It turns out > two elements were missing: > > 1) The Luna JSP files need to be present in the right directory: > cd /usr/safenet/lunaclient/jsp/lib > cp -r lib/LunaProvider.jar /usr/java/latest/jre/lib/ext > cp -r lib/libLunaAPI.so /usr/java/latest/jre/lib/ext > > > 2) The provider order in jre/lib/security/java.security should have been: > security.provider.1=sun.security.pkcs11.SunPKCS11 > ${java.home}/lib/security/luna.cfg > security.provider.2=sun.security.provider.Sun > security.provider.3=sun.security.rsa.SunRsaSign > security.provider.4=sun.security.ec.SunEC > security.provider.5=com.sun.net.ssl.internal.ssl.Provider > security.provider.6=com.sun.crypto.provider.SunJCE > security.provider.7=com.safenetinc.luna.provider.LunaProvider > (others below) > > (Note: I also had to create a luna.cfg file containing the following: > name=LunaSA > library=/usr/safenet/lunaclient/lib/libCryptoki2_64.so > slot=1 > ) > > With these features in place, the Luna SA is accessible both from Java's > keytool and from SignServer. > > I would note that the documentation is a bit confusing -- I think the > SignServer documentation assumes that the SunPKCS11 provider is > installed by default, and the Luna SA documentation only mentions it in > a separate PKCS11 Providers Integration Guide! > > Cheers, > Jon Blum > > > > > On Mon, Oct 17, 2016 at 11:15 AM, Blum, Jon <jon...@or... > <mailto:jon...@or...>> wrote: > > Hi -- I'm having a problem setting up my SignServer to talk to a > Luna SA HSM. > > I've set up SignServer and tested the MRTDSODSigner repeatedly with > soft keys, so the rest of its configuration appears to be correct. > > The link between the Luna SA and the server is also set up > correctly; running Luna's VTL tool shows the partition is visible > like so: > > ---- > [root@localhost bin]# ./vtl verify > > The following Luna SA Slots/Partitions were found: > > Slot Serial # Label > ==== ======== ===== > 1 520030014 epassport > ---- > > But when I try to run SignServer's activatecryptotoken command, I > get one of two failure results. If I specify the slot name with > these parameters: > > SLOTLABELTYPE=SLOT_NAME > SLOTLABELVALUE=epassport > > then when I run bin/signserver.sh activatecryptotoken, it fails in > the init function: > > ---- > Trying to activate crypto token of worker with id : 6 > > Crypto token is offline: org.signserver.common.SignServerException: > Failed to initialize crypto token: Token label 'epassport' not found. > ---- > > On the other hand, if I specify the slot number or slot index with > these parameters: > > SLOTLABELTYPE=SLOT_NUMBER > SLOTLABELVALUE=1 > > or > > SLOTLABELTYPE=SLOT_INDEX > SLOTLABELVALUE=0 > > then the activatecryptotoken command gets past the init function, > but fails when it actually tries to activate: > > ---- > Trying to activate crypto token of worker with id : 5 > > Crypto token authentication failed: Activate failed: Failed to > initialize PKCS11 provider slot '0'.: KeyStore instantiation failed: > PKCS11 not found: no such algorithm: PKCS11 for provider > SunPKCS11-libCryptoki2_64.so-slot0 > ---- > > In both cases the following lines have been uncommented in > signserver_deploy.properties: > > cryptotoken.p11.lib.20.name > <http://cryptotoken.p11.lib.20.name>=SafeNet Luna SA > cryptotoken.p11.lib.20.file=/usr/safenet/lunaclient/lib/libCryptoki2_64.so > > > For what it's worth, the server is running CentOS 7 and JDK 1.8. > And Luna's crypto provider has been added to > jre/lib/security/java.security: > > security.provider.1=sun.security.provider.Sun > security.provider.2=sun.security.rsa.SunRsaSign > security.provider.3=com.safenetinc.luna.provider.LunaProvider > security.provider.4=sun.security.ec.SunEC > security.provider.5=com.sun.net.ssl.internal.ssl.Provider > security.provider.6=com.sun.crypto.provider.SunJCE > security.provider.7=sun.security.jgss.SunProvider > security.provider.8=com.sun.security.sasl.Provider > security.provider.9=org.jcp.xml.dsig.internal.dom.XMLDSigRI > security.provider.10=sun.security.smartcardio.SunPCSC > > So... what could be missing, that it's not finding the PKCS11 > algorithms? > > Cheers, > Jon Blum > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > > > > _______________________________________________ > SignServer-develop mailing list > Sig...@li... > https://lists.sourceforge.net/lists/listinfo/signserver-develop > -- Kind regards, Markus Kilås PKI Specialist PrimeKey Solutions AB Lundagatan 16 SE-171 63 Solna Sweden Phone: +46 70 424 94 85 Email: mar...@pr... https://www.primekey.se |
|
From: Blum, J. <jon...@or...> - 2016-10-17 05:43:23
|
Update on this -- I seem to have sorted out the problem! It turns out two
elements were missing:
1) The Luna JSP files need to be present in the right directory:
cd /usr/safenet/lunaclient/jsp/lib
cp -r lib/LunaProvider.jar /usr/java/latest/jre/lib/ext
cp -r lib/libLunaAPI.so /usr/java/latest/jre/lib/ext
2) The provider order in jre/lib/security/java.security should have been:
security.provider.1=sun.security.pkcs11.SunPKCS11
${java.home}/lib/security/luna.cfg
security.provider.2=sun.security.provider.Sun
security.provider.3=sun.security.rsa.SunRsaSign
security.provider.4=sun.security.ec.SunEC
security.provider.5=com.sun.net.ssl.internal.ssl.Provider
security.provider.6=com.sun.crypto.provider.SunJCE
security.provider.7=com.safenetinc.luna.provider.LunaProvider
(others below)
(Note: I also had to create a luna.cfg file containing the following:
name=LunaSA
library=/usr/safenet/lunaclient/lib/libCryptoki2_64.so
slot=1
)
With these features in place, the Luna SA is accessible both from Java's
keytool and from SignServer.
I would note that the documentation is a bit confusing -- I think the
SignServer documentation assumes that the SunPKCS11 provider is installed
by default, and the Luna SA documentation only mentions it in a separate
PKCS11 Providers Integration Guide!
Cheers,
Jon Blum
On Mon, Oct 17, 2016 at 11:15 AM, Blum, Jon <jon...@or...>
wrote:
> Hi -- I'm having a problem setting up my SignServer to talk to a Luna SA
> HSM.
>
> I've set up SignServer and tested the MRTDSODSigner repeatedly with soft
> keys, so the rest of its configuration appears to be correct.
>
> The link between the Luna SA and the server is also set up correctly;
> running Luna's VTL tool shows the partition is visible like so:
>
> ----
> [root@localhost bin]# ./vtl verify
>
> The following Luna SA Slots/Partitions were found:
>
> Slot Serial # Label
> ==== ======== =====
> 1 520030014 epassport
> ----
>
> But when I try to run SignServer's activatecryptotoken command, I get one
> of two failure results. If I specify the slot name with these parameters:
>
> SLOTLABELTYPE=SLOT_NAME
> SLOTLABELVALUE=epassport
>
> then when I run bin/signserver.sh activatecryptotoken, it fails in the
> init function:
>
> ----
> Trying to activate crypto token of worker with id : 6
>
> Crypto token is offline: org.signserver.common.SignServerException:
> Failed to initialize crypto token: Token label 'epassport' not found.
> ----
>
> On the other hand, if I specify the slot number or slot index with these
> parameters:
>
> SLOTLABELTYPE=SLOT_NUMBER
> SLOTLABELVALUE=1
>
> or
>
> SLOTLABELTYPE=SLOT_INDEX
> SLOTLABELVALUE=0
>
> then the activatecryptotoken command gets past the init function, but
> fails when it actually tries to activate:
>
> ----
> Trying to activate crypto token of worker with id : 5
>
> Crypto token authentication failed: Activate failed: Failed to initialize
> PKCS11 provider slot '0'.: KeyStore instantiation failed: PKCS11 not found:
> no such algorithm: PKCS11 for provider SunPKCS11-libCryptoki2_64.so-slot0
> ----
>
> In both cases the following lines have been uncommented in
> signserver_deploy.properties:
>
> cryptotoken.p11.lib.20.name=SafeNet Luna SA
> cryptotoken.p11.lib.20.file=/usr/safenet/lunaclient/lib/libCryptoki2_64.so
>
>
> For what it's worth, the server is running CentOS 7 and JDK 1.8. And
> Luna's crypto provider has been added to jre/lib/security/java.security:
>
> security.provider.1=sun.security.provider.Sun
> security.provider.2=sun.security.rsa.SunRsaSign
> security.provider.3=com.safenetinc.luna.provider.LunaProvider
> security.provider.4=sun.security.ec.SunEC
> security.provider.5=com.sun.net.ssl.internal.ssl.Provider
> security.provider.6=com.sun.crypto.provider.SunJCE
> security.provider.7=sun.security.jgss.SunProvider
> security.provider.8=com.sun.security.sasl.Provider
> security.provider.9=org.jcp.xml.dsig.internal.dom.XMLDSigRI
> security.provider.10=sun.security.smartcardio.SunPCSC
>
> So... what could be missing, that it's not finding the PKCS11 algorithms?
>
> Cheers,
> Jon Blum
>
>
|
|
From: Blum, J. <jon...@or...> - 2016-10-17 00:16:06
|
Hi -- I'm having a problem setting up my SignServer to talk to a Luna SA HSM. I've set up SignServer and tested the MRTDSODSigner repeatedly with soft keys, so the rest of its configuration appears to be correct. The link between the Luna SA and the server is also set up correctly; running Luna's VTL tool shows the partition is visible like so: ---- [root@localhost bin]# ./vtl verify The following Luna SA Slots/Partitions were found: Slot Serial # Label ==== ======== ===== 1 520030014 epassport ---- But when I try to run SignServer's activatecryptotoken command, I get one of two failure results. If I specify the slot name with these parameters: SLOTLABELTYPE=SLOT_NAME SLOTLABELVALUE=epassport then when I run bin/signserver.sh activatecryptotoken, it fails in the init function: ---- Trying to activate crypto token of worker with id : 6 Crypto token is offline: org.signserver.common.SignServerException: Failed to initialize crypto token: Token label 'epassport' not found. ---- On the other hand, if I specify the slot number or slot index with these parameters: SLOTLABELTYPE=SLOT_NUMBER SLOTLABELVALUE=1 or SLOTLABELTYPE=SLOT_INDEX SLOTLABELVALUE=0 then the activatecryptotoken command gets past the init function, but fails when it actually tries to activate: ---- Trying to activate crypto token of worker with id : 5 Crypto token authentication failed: Activate failed: Failed to initialize PKCS11 provider slot '0'.: KeyStore instantiation failed: PKCS11 not found: no such algorithm: PKCS11 for provider SunPKCS11-libCryptoki2_64.so-slot0 ---- In both cases the following lines have been uncommented in signserver_deploy.properties: cryptotoken.p11.lib.20.name=SafeNet Luna SA cryptotoken.p11.lib.20.file=/usr/safenet/lunaclient/lib/libCryptoki2_64.so For what it's worth, the server is running CentOS 7 and JDK 1.8. And Luna's crypto provider has been added to jre/lib/security/java.security: security.provider.1=sun.security.provider.Sun security.provider.2=sun.security.rsa.SunRsaSign security.provider.3=com.safenetinc.luna.provider.LunaProvider security.provider.4=sun.security.ec.SunEC security.provider.5=com.sun.net.ssl.internal.ssl.Provider security.provider.6=com.sun.crypto.provider.SunJCE security.provider.7=sun.security.jgss.SunProvider security.provider.8=com.sun.security.sasl.Provider security.provider.9=org.jcp.xml.dsig.internal.dom.XMLDSigRI security.provider.10=sun.security.smartcardio.SunPCSC So... what could be missing, that it's not finding the PKCS11 algorithms? Cheers, Jon Blum |
|
From: Markus K. <ma...@pr...> - 2016-09-22 14:41:15
|
The PrimeKey SignServer team is happy to announce the release of SignServer 4.0.0 community and enterprise editions, introducing the next generation SignServer. SignServer 4.0.0 is the next generation SignServer with 119 issues resolved since SignServer Enterprise 3.7.4 and a total of 198 issues resolved since SignServer Community Edition 3.7.0, some of the most noteworthy listed below: New Features and Improvements - Technology upgrade, including: - Updated to Java EE 6. - Major internal library updates such as for CESeCore and Bouncy Castle etc. - Internal API changes. - Build system changes. - Support for large files (Enterprise Edition only). - Support for RFC 5816 time-stamps. - More reliable calculation of free memory in Health Check. - Various Administration GUI improvements. Read the changelog in our issue tracker for full details: https://jira.primekey.se/browse/DSS Regards, PrimeKey SignServer Team |
|
From: Markus K. <ma...@pr...> - 2016-09-20 08:09:35
|
Hi all, As announced yesterday, at the first day of PrimeKey PKI Tech Days [1], SignServer 4.0 is about to get released. Stay tuned for the release later this week! [1] https://www.primekey.se/news-events/about-pki-tech-days-2016/ Cheers, Markus Kilås PrimeKey Solutions |
|
From: Markus K. <ma...@pr...> - 2016-09-20 08:03:28
|
On 09/19/2016 06:19 PM, Arnaud Defos wrote: > Hi everyone, > > If the HSM is unavailable (for example, if you unplug and plug the > network), the HSM becomes offline in signserver. What HSM/PKCS#11 shared library are you using? I believe this could be a bit different depending on which HSM is used if it would survive networking issues or not. > > If I try to generate a key, I have > a org.signserver.common.CryptoTokenOfflineException. > > I try to launch : > $> bin/signserver.sh activatecryptotoken 1 > and > $> bin/signserver.sh reload 1 > > But it doesn't work... HSM is still offline in signserver even if I can > ping it. The last reload here could be putting the (crypto) worker offline again as its configuration is again loaded from the database. You should do the activate command last. > > If I restart signserver, it works. What can I do without restarting > signserver ? > > Thanks for your answer ! > > > Arnaud > Cheers, Markus PrimeKey Solutions AB PrimeKey Solutions offers a commercial EJBCA & SignServer support subscription and training. Please see www.primekey.se or contact in...@pr... for more information. https://www.primekey.se/Services/Support/ https://www.primekey.se/Services/Training/ |
|
From: Arnaud D. <arn...@gm...> - 2016-09-19 16:19:30
|
Hi everyone, If the HSM is unavailable (for example, if you unplug and plug the network), the HSM becomes offline in signserver. If I try to generate a key, I have a org.signserver.common.CryptoTokenOfflineException. I try to launch : $> bin/signserver.sh activatecryptotoken 1 and $> bin/signserver.sh reload 1 But it doesn't work... HSM is still offline in signserver even if I can ping it. If I restart signserver, it works. What can I do without restarting signserver ? Thanks for your answer ! Arnaud |
|
From: Markus K. <ma...@pr...> - 2016-09-17 21:40:05
|
On 17 September 2016 16:00:02 CEST, "Blum, Jon" <jon...@or...> wrote: >Final update -- I think I've sorted out the problem! > >It was a Wildfly configuration issue -- Wildfly was set up to run as a >service with its own dedicated user, which was not the same user which >was >running the SignServer CLI. > >Basically, I turned on trace logging for the client functions in >conf/log4j.properties (changing the appropriate entries already in the >file >to TRACE level). This revealed that the system was trying to read an >authentication challenge file stored in /opt/wildfly/tmp/auth -- but it >didn't have permission for the directory. As a temporary workaround >I've >changed the folder permissions; in the longer term I'm going to have to >redefine the Wildfly user to put them in the same group. > >So, that point is resolved, and I can get back to proper configuration! > >--jon > > >On Sat, Sep 17, 2016 at 8:57 PM, Blum, Jon <jon...@or...> >wrote: > >> I hope the mailing list has finally accepted my subscription... >> >> Anyway, update: I'm now thinking the problem is most likely with my >> wildfly server configuration. I'd already tried to add an explicit >> remoting connection, and have now removed it, returning to the >default >> configuration... still no luck. At this point the only listener is >the >> default one, on 8080. >> >> So, a few more questions: >> >> 1) There's no way of telling from SignServer's client-side >command-line >> app whether the EJB connection is failing to reach the server, or >whether >> the server is rejecting the request -- right? Is there anything I >should >> be looking for in the server logs when I try to make a connection? >> >> 2) User IDs -- does SignServer require a specific Wildfly user ID to >be >> added to the jboss-ejb-client.properties file? (I've tried it with >and >> without, with no luck -- but it's possible that my user doesn't have >the >> right access. If I need a user, how should I set it up?) >> >> 3) Could the problem be with the following Wildfly commands, which >were >> listed under the JBoss 7 section of the SignServer install doc? I'm >not >> sure whether they apply to Wildfly. Could the presence of >> "jbossws.undefined.host" rather than 127.0.0.1 be causing it to miss >the >> connection? >> >> /subsystem=webservices:write-attribute(name=wsdl-host, >> value=jbossws.undefined.host) >> >> /subsystem=webservices:write-attribute(name=modify-wsdl-address, >> value=true) >> >> Thanks, >> Jon >> >> On Fri, Sep 16, 2016 at 11:07 PM, Markus Kilås <ma...@pr...> >wrote: >> >>> On 09/16/2016 02:36 PM, Blum, Jon wrote: >>> > Hello Markus -- thanks for your guidance here! >>> > >>> >>> (Jon, please subscribe to the list otherwise your responses will not >be >>> delivered to the other subscribers. >>> https://lists.sourceforge.net/lists/listinfo/signserver-develop) >>> >>> >> Just as you explore below the "No EJB recevier available for ..." >>> >> typically means that either SignServer/JBoss hasn't started up >>> >> completely or that the wrong connection configuration is used >from the >>> > CLI. >>> > >>> >> What you want to look for is that you get the EVENT: >SIGNSERVER_STARTUP >>> >> and not any error following it. >>> > >>> > Okay -- I can confirm that Wildlfly and SignServer are starting up >>> > successfully. From the end of server.log: >>> > >>> > 2016-09-16 01:18:48,894 INFO >>> > [org.signserver.server.log.SignServerLog4jDevice] (ServerService >Thread >>> > Pool -- 67) EVENT: SIGNSERVER_STARTUP; MODULE: SERVICE; >ADMINISTRATOR: >>> > StartServicesServlet.init; ISSUER: null; SERIAL_NUMBER: null; >WORKER_ID: >>> > null; msg: start services startup msg; VERSION: SignServer CE >3.7.0; >>> > REPLY_TIME:1474013928894 >>> > >>> > So if the server's running, and the pages are accessible on >>> > localhost:8080, it's got to be something wrong on the client side, >>> right? >>> >>> Yes likely, but it could still be a configuration issue on the >server >>> side for the EJB connector. But if you haven't touch those then I >>> suppose its the client side that is the problem. >>> >>> >>> > >>> > A couple of questions to help me hunt this down -- >>> > >>> > * Are there any other properties files which could affect the >client >>> > EJB connections, besides conf/jboss7/jboss-ejb-client.properties? >If >>> >>> I don't have a WildFly 10 installation at the moment but tested with >>> WildFly 9.0.2.Final and all changes I had to do on the client side >was >>> to edit conf/jboss7/jboss-ejb-client.properties to use port 8080 and >it >>> worked for me. >>> >>> I should also mention that since 3.7.x+ we have changed to instead >>> recommending to turn of the EJB interface on port 8080 and instead >add >>> it back on port 4447 but that is more from a security point as you >can >>> then stop access to the CLI on a network/firewall level just as >before. >>> This change will be available in the 4.0.0 manual which you can have >a >>> sneak peek into here: >>> https://www.signserver.org/sandbox/doc/4.0.0/manual/installg >>> uide.html#WildFly_9_SSL_configuration >>> >>> See the "Securing the CLI by removing...". >>> >>> > I've mis-set something in the build process, could it be including >an >>> > incorrect .properties file at build time? >>> Don't think so. Very few properties has any effect on the build >process. >>> Server-side properties are packaged in the EAR file when you run the >>> bin/ant deploy command and client-side properties like >jndi.properties >>> and the jboss-ejb-thing is read at runtime when running the CLI. >>> >>> > * Is there any way I can check specifically whether *EJB* >connections >>> > are accessible over port 8080? I can confirm the JSP pages are >showing >>> > properly over localhost:8080; but could the beans still be being >>> > blocked? (I did confirm that the beans are mapped to >>> > java:jboss/exported above, so they should be visible... right?) >>> >>> Besides running the CLI (as you did) and the AdminGUI (would give >same >>> error) - not any that I know of. Maybe WildFly has some tool for it? >>> >>> >>> Cheers, >>> Markus >>> >>> >> Great! That was interesting, thanks for sharing. Cheers, Markus -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. |
|
From: Blum, J. <jon...@or...> - 2016-09-17 14:00:13
|
Final update -- I think I've sorted out the problem! It was a Wildfly configuration issue -- Wildfly was set up to run as a service with its own dedicated user, which was not the same user which was running the SignServer CLI. Basically, I turned on trace logging for the client functions in conf/log4j.properties (changing the appropriate entries already in the file to TRACE level). This revealed that the system was trying to read an authentication challenge file stored in /opt/wildfly/tmp/auth -- but it didn't have permission for the directory. As a temporary workaround I've changed the folder permissions; in the longer term I'm going to have to redefine the Wildfly user to put them in the same group. So, that point is resolved, and I can get back to proper configuration! --jon On Sat, Sep 17, 2016 at 8:57 PM, Blum, Jon <jon...@or...> wrote: > I hope the mailing list has finally accepted my subscription... > > Anyway, update: I'm now thinking the problem is most likely with my > wildfly server configuration. I'd already tried to add an explicit > remoting connection, and have now removed it, returning to the default > configuration... still no luck. At this point the only listener is the > default one, on 8080. > > So, a few more questions: > > 1) There's no way of telling from SignServer's client-side command-line > app whether the EJB connection is failing to reach the server, or whether > the server is rejecting the request -- right? Is there anything I should > be looking for in the server logs when I try to make a connection? > > 2) User IDs -- does SignServer require a specific Wildfly user ID to be > added to the jboss-ejb-client.properties file? (I've tried it with and > without, with no luck -- but it's possible that my user doesn't have the > right access. If I need a user, how should I set it up?) > > 3) Could the problem be with the following Wildfly commands, which were > listed under the JBoss 7 section of the SignServer install doc? I'm not > sure whether they apply to Wildfly. Could the presence of > "jbossws.undefined.host" rather than 127.0.0.1 be causing it to miss the > connection? > > /subsystem=webservices:write-attribute(name=wsdl-host, > value=jbossws.undefined.host) > > /subsystem=webservices:write-attribute(name=modify-wsdl-address, > value=true) > > Thanks, > Jon > > On Fri, Sep 16, 2016 at 11:07 PM, Markus Kilås <ma...@pr...> wrote: > >> On 09/16/2016 02:36 PM, Blum, Jon wrote: >> > Hello Markus -- thanks for your guidance here! >> > >> >> (Jon, please subscribe to the list otherwise your responses will not be >> delivered to the other subscribers. >> https://lists.sourceforge.net/lists/listinfo/signserver-develop) >> >> >> Just as you explore below the "No EJB recevier available for ..." >> >> typically means that either SignServer/JBoss hasn't started up >> >> completely or that the wrong connection configuration is used from the >> > CLI. >> > >> >> What you want to look for is that you get the EVENT: SIGNSERVER_STARTUP >> >> and not any error following it. >> > >> > Okay -- I can confirm that Wildlfly and SignServer are starting up >> > successfully. From the end of server.log: >> > >> > 2016-09-16 01:18:48,894 INFO >> > [org.signserver.server.log.SignServerLog4jDevice] (ServerService Thread >> > Pool -- 67) EVENT: SIGNSERVER_STARTUP; MODULE: SERVICE; ADMINISTRATOR: >> > StartServicesServlet.init; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: >> > null; msg: start services startup msg; VERSION: SignServer CE 3.7.0; >> > REPLY_TIME:1474013928894 >> > >> > So if the server's running, and the pages are accessible on >> > localhost:8080, it's got to be something wrong on the client side, >> right? >> >> Yes likely, but it could still be a configuration issue on the server >> side for the EJB connector. But if you haven't touch those then I >> suppose its the client side that is the problem. >> >> >> > >> > A couple of questions to help me hunt this down -- >> > >> > * Are there any other properties files which could affect the client >> > EJB connections, besides conf/jboss7/jboss-ejb-client.properties? If >> >> I don't have a WildFly 10 installation at the moment but tested with >> WildFly 9.0.2.Final and all changes I had to do on the client side was >> to edit conf/jboss7/jboss-ejb-client.properties to use port 8080 and it >> worked for me. >> >> I should also mention that since 3.7.x+ we have changed to instead >> recommending to turn of the EJB interface on port 8080 and instead add >> it back on port 4447 but that is more from a security point as you can >> then stop access to the CLI on a network/firewall level just as before. >> This change will be available in the 4.0.0 manual which you can have a >> sneak peek into here: >> https://www.signserver.org/sandbox/doc/4.0.0/manual/installg >> uide.html#WildFly_9_SSL_configuration >> >> See the "Securing the CLI by removing...". >> >> > I've mis-set something in the build process, could it be including an >> > incorrect .properties file at build time? >> Don't think so. Very few properties has any effect on the build process. >> Server-side properties are packaged in the EAR file when you run the >> bin/ant deploy command and client-side properties like jndi.properties >> and the jboss-ejb-thing is read at runtime when running the CLI. >> >> > * Is there any way I can check specifically whether *EJB* connections >> > are accessible over port 8080? I can confirm the JSP pages are showing >> > properly over localhost:8080; but could the beans still be being >> > blocked? (I did confirm that the beans are mapped to >> > java:jboss/exported above, so they should be visible... right?) >> >> Besides running the CLI (as you did) and the AdminGUI (would give same >> error) - not any that I know of. Maybe WildFly has some tool for it? >> >> >> Cheers, >> Markus >> >> > |
|
From: Blum, J. <jon...@or...> - 2016-09-17 10:57:35
|
I hope the mailing list has finally accepted my subscription... Anyway, update: I'm now thinking the problem is most likely with my wildfly server configuration. I'd already tried to add an explicit remoting connection, and have now removed it, returning to the default configuration... still no luck. At this point the only listener is the default one, on 8080. So, a few more questions: 1) There's no way of telling from SignServer's client-side command-line app whether the EJB connection is failing to reach the server, or whether the server is rejecting the request -- right? Is there anything I should be looking for in the server logs when I try to make a connection? 2) User IDs -- does SignServer require a specific Wildfly user ID to be added to the jboss-ejb-client.properties file? (I've tried it with and without, with no luck -- but it's possible that my user doesn't have the right access. If I need a user, how should I set it up?) 3) Could the problem be with the following Wildfly commands, which were listed under the JBoss 7 section of the SignServer install doc? I'm not sure whether they apply to Wildfly. Could the presence of "jbossws.undefined.host" rather than 127.0.0.1 be causing it to miss the connection? /subsystem=webservices:write-attribute(name=wsdl-host, value=jbossws.undefined.host) /subsystem=webservices:write-attribute(name=modify-wsdl-address, value=true) Thanks, Jon On Fri, Sep 16, 2016 at 11:07 PM, Markus Kilås <ma...@pr...> wrote: > On 09/16/2016 02:36 PM, Blum, Jon wrote: > > Hello Markus -- thanks for your guidance here! > > > > (Jon, please subscribe to the list otherwise your responses will not be > delivered to the other subscribers. > https://lists.sourceforge.net/lists/listinfo/signserver-develop) > > >> Just as you explore below the "No EJB recevier available for ..." > >> typically means that either SignServer/JBoss hasn't started up > >> completely or that the wrong connection configuration is used from the > > CLI. > > > >> What you want to look for is that you get the EVENT: SIGNSERVER_STARTUP > >> and not any error following it. > > > > Okay -- I can confirm that Wildlfly and SignServer are starting up > > successfully. From the end of server.log: > > > > 2016-09-16 01:18:48,894 INFO > > [org.signserver.server.log.SignServerLog4jDevice] (ServerService Thread > > Pool -- 67) EVENT: SIGNSERVER_STARTUP; MODULE: SERVICE; ADMINISTRATOR: > > StartServicesServlet.init; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: > > null; msg: start services startup msg; VERSION: SignServer CE 3.7.0; > > REPLY_TIME:1474013928894 > > > > So if the server's running, and the pages are accessible on > > localhost:8080, it's got to be something wrong on the client side, right? > > Yes likely, but it could still be a configuration issue on the server > side for the EJB connector. But if you haven't touch those then I > suppose its the client side that is the problem. > > > > > > A couple of questions to help me hunt this down -- > > > > * Are there any other properties files which could affect the client > > EJB connections, besides conf/jboss7/jboss-ejb-client.properties? If > > I don't have a WildFly 10 installation at the moment but tested with > WildFly 9.0.2.Final and all changes I had to do on the client side was > to edit conf/jboss7/jboss-ejb-client.properties to use port 8080 and it > worked for me. > > I should also mention that since 3.7.x+ we have changed to instead > recommending to turn of the EJB interface on port 8080 and instead add > it back on port 4447 but that is more from a security point as you can > then stop access to the CLI on a network/firewall level just as before. > This change will be available in the 4.0.0 manual which you can have a > sneak peek into here: > https://www.signserver.org/sandbox/doc/4.0.0/manual/ > installguide.html#WildFly_9_SSL_configuration > > See the "Securing the CLI by removing...". > > > I've mis-set something in the build process, could it be including an > > incorrect .properties file at build time? > Don't think so. Very few properties has any effect on the build process. > Server-side properties are packaged in the EAR file when you run the > bin/ant deploy command and client-side properties like jndi.properties > and the jboss-ejb-thing is read at runtime when running the CLI. > > > * Is there any way I can check specifically whether *EJB* connections > > are accessible over port 8080? I can confirm the JSP pages are showing > > properly over localhost:8080; but could the beans still be being > > blocked? (I did confirm that the beans are mapped to > > java:jboss/exported above, so they should be visible... right?) > > Besides running the CLI (as you did) and the AdminGUI (would give same > error) - not any that I know of. Maybe WildFly has some tool for it? > > > Cheers, > Markus > > |
|
From: Markus K. <ma...@pr...> - 2016-09-16 13:07:44
|
On 09/16/2016 02:36 PM, Blum, Jon wrote: > Hello Markus -- thanks for your guidance here! > (Jon, please subscribe to the list otherwise your responses will not be delivered to the other subscribers. https://lists.sourceforge.net/lists/listinfo/signserver-develop) >> Just as you explore below the "No EJB recevier available for ..." >> typically means that either SignServer/JBoss hasn't started up >> completely or that the wrong connection configuration is used from the > CLI. > >> What you want to look for is that you get the EVENT: SIGNSERVER_STARTUP >> and not any error following it. > > Okay -- I can confirm that Wildlfly and SignServer are starting up > successfully. From the end of server.log: > > 2016-09-16 01:18:48,894 INFO > [org.signserver.server.log.SignServerLog4jDevice] (ServerService Thread > Pool -- 67) EVENT: SIGNSERVER_STARTUP; MODULE: SERVICE; ADMINISTRATOR: > StartServicesServlet.init; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: > null; msg: start services startup msg; VERSION: SignServer CE 3.7.0; > REPLY_TIME:1474013928894 > > So if the server's running, and the pages are accessible on > localhost:8080, it's got to be something wrong on the client side, right? Yes likely, but it could still be a configuration issue on the server side for the EJB connector. But if you haven't touch those then I suppose its the client side that is the problem. > > A couple of questions to help me hunt this down -- > > * Are there any other properties files which could affect the client > EJB connections, besides conf/jboss7/jboss-ejb-client.properties? If I don't have a WildFly 10 installation at the moment but tested with WildFly 9.0.2.Final and all changes I had to do on the client side was to edit conf/jboss7/jboss-ejb-client.properties to use port 8080 and it worked for me. I should also mention that since 3.7.x+ we have changed to instead recommending to turn of the EJB interface on port 8080 and instead add it back on port 4447 but that is more from a security point as you can then stop access to the CLI on a network/firewall level just as before. This change will be available in the 4.0.0 manual which you can have a sneak peek into here: https://www.signserver.org/sandbox/doc/4.0.0/manual/installguide.html#WildFly_9_SSL_configuration See the "Securing the CLI by removing...". > I've mis-set something in the build process, could it be including an > incorrect .properties file at build time? Don't think so. Very few properties has any effect on the build process. Server-side properties are packaged in the EAR file when you run the bin/ant deploy command and client-side properties like jndi.properties and the jboss-ejb-thing is read at runtime when running the CLI. > * Is there any way I can check specifically whether *EJB* connections > are accessible over port 8080? I can confirm the JSP pages are showing > properly over localhost:8080; but could the beans still be being > blocked? (I did confirm that the beans are mapped to > java:jboss/exported above, so they should be visible... right?) Besides running the CLI (as you did) and the AdminGUI (would give same error) - not any that I know of. Maybe WildFly has some tool for it? Cheers, Markus |
|
From: Blum, J. <jon...@or...> - 2016-09-16 12:36:26
|
Hello Markus -- thanks for your guidance here! > Just as you explore below the "No EJB recevier available for ..." > typically means that either SignServer/JBoss hasn't started up > completely or that the wrong connection configuration is used from the CLI. > What you want to look for is that you get the EVENT: SIGNSERVER_STARTUP > and not any error following it. Okay -- I can confirm that Wildlfly and SignServer are starting up successfully. From the end of server.log: 2016-09-16 01:18:48,894 INFO [org.signserver.server.log.SignServerLog4jDevice] (ServerService Thread Pool -- 67) EVENT: SIGNSERVER_STARTUP; MODULE: SERVICE; ADMINISTRATOR: StartServicesServlet.init; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: null; msg: start services startup msg; VERSION: SignServer CE 3.7.0; REPLY_TIME:1474013928894 So if the server's running, and the pages are accessible on localhost:8080, it's got to be something wrong on the client side, right? A couple of questions to help me hunt this down -- * Are there any other properties files which could affect the client EJB connections, besides conf/jboss7/jboss-ejb-client.properties? If I've mis-set something in the build process, could it be including an incorrect .properties file at build time? * Is there any way I can check specifically whether *EJB* connections are accessible over port 8080? I can confirm the JSP pages are showing properly over localhost:8080; but could the beans still be being blocked? (I did confirm that the beans are mapped to java:jboss/exported above, so they should be visible... right?) Thanks, Jon Blum On Fri, Sep 16, 2016 at 9:17 PM, Markus Kilås <ma...@pr...> wrote: > On 2016-09-16 09:42, Blum, Jon wrote: > > Hello all -- > > Hello Jon, > > > > > I'm doing an initial build and setup of SignServer from source, with the > > latest community version, as detailed on the Getting Started webpage. I > > know that this version predates Wildfly 10, but recent messages seem to > > indicate that it can at least basically function. > > > > The deployment appears to have been successful, everything is loading > > correctly in the Wildfly system log on startup and the sample JSP pages > > are displaying correctly... but the SignServer CLI at /bin/signserver > > won't run. > > > > The initial exception appears to be: > > Caused by: java.lang.IllegalStateException: EJBCLIENT000025: *No EJB > > receiver available for handling [appName:signserver, > > moduleName:SignServer-ejb, distinctName:] combination* for invocation > > context org.jboss.ejb.client.EJBClientInvocationContext@4493d195 > > > > It occurs at while getting the initial global configuration: > > at com.sun.proxy.$Proxy0.getGlobalConfiguration(Unknown Source) > > at > > org.signserver.admin.cli.defaultimpl.GetStatusCommand. > execute(GetStatusCommand.java:72) > > > > The JBoss JNDI name it's trying to retrieve is: > > *ejb:signserver/SignServer-ejb//GlobalConfigurationSessionBean > !org.signserver.ejb.interfaces.IGlobalConfigurationSession$IRemote > > * > > Just as you explore below the "No EJB recevier available for ..." > typically means that either SignServer/JBoss hasn't started up > completely or that the wrong connection configuration is used from the CLI. > > > According to the JBOSS server logfile, this bean has been successfully > > created and exported (under jboss/exported) on startup: > > > > 2016-09-15 01:07:12,446 INFO [org.jboss.as.ejb3.deployment] (MSC > > service thread 1-1) WFLYEJB0473: JNDI bindings for session bean named > > 'GlobalConfigurationSessionBean' in deployment unit 'subdeployment > > "SignServer-ejb.jar" of deployment "signserver.ear"' are as follows: > > > > > > java:global/signserver/SignServer-ejb/GlobalConfigurationSessionBean > !org.signserver.ejb.interfaces.IGlobalConfigurationSession$ILocal > > > > java:app/SignServer-ejb/GlobalConfigurationSessionBean > !org.signserver.ejb.interfaces.IGlobalConfigurationSession$ILocal > > > > java:module/GlobalConfigurationSessionBean!org.signserver.ejb. > interfaces.IGlobalConfigurationSession$ILocal > > > > java:global/signserver/SignServer-ejb/GlobalConfigurationSessionBean > !org.signserver.ejb.interfaces.IGlobalConfigurationSession$IRemote > > > > java:app/SignServer-ejb/GlobalConfigurationSessionBean > !org.signserver.ejb.interfaces.IGlobalConfigurationSession$IRemote > > > > java:module/GlobalConfigurationSessionBean!org.signserver.ejb. > interfaces.IGlobalConfigurationSession$IRemote > > * > > java:jboss/exported/signserver/SignServer-ejb/ > GlobalConfigurationSessionBean!org.signserver.ejb.interfaces. > IGlobalConfigurationSession$IRemote > > * > > That is good but it could happen that it gets undeployed later due to > some startup failure or that JBoss gets stuck at some point due to a > configuration issue. > > What you want to look for is that you get the EVENT: SIGNSERVER_STARTUP > and not any error following it. > > > > > So it looks like a connection problem. My APPSRV_HOME is set correctly > > to /opt/wildfly. I've successfully changed the connection port to 8080, > > as mentioned in a previous email on this list; here's my > > conf/jboss7/jboss-ejb-client.properties file: > > > > remote.connectionprovider.create.options.org.xnio. > Options.SSL_ENABLED=false > > remote.connections=default > > remote.connection.default.host=localhost > > #remote.connection.default.port = 4447 > > remote.connection.default.port = 8080 > > remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_ > NOANONYMOUS=false > > > > And yes, it should be hitting that properties file -- here's the > > classpath when I try to invoke /bin/signserver: > > > > -cp*/opt/signserver/conf/jboss7*:/opt/wildfly/bin/ > client/jboss-client.jar:/opt/signserver/conf:/opt/ > signserver/lib/SignServer-AdminCLI.jar:/opt/signserver/ > res/cesecore:/opt/signserver/lib/ext/clover-dir/lib/clover.jar: > > Assuming SignServer and JBoss starts up correctly all the way then yes, > the second thing to look for is to see that correct port is used just as > you are doing. I'm not really seeing any problem here though. > > > > > > > So the question becomes... what else could I be missing? It's either a > > Wildfly configuration issue or a client-side one; where else should I > look? > > > > Cheers, > > Jon BLum > > > > Regards, > Markus Kilås > PrimeKey Solutions AB > > Save time and money with an Enterprise support subscription. Please see > www.primekey.se for more information. > https://www.primekey.se/technologies/products-overview/ > https://www.primekey.se/service-support/support/ > > |
|
From: Markus K. <ma...@pr...> - 2016-09-16 11:17:33
|
On 2016-09-16 09:42, Blum, Jon wrote: > Hello all -- Hello Jon, > > I'm doing an initial build and setup of SignServer from source, with the > latest community version, as detailed on the Getting Started webpage. I > know that this version predates Wildfly 10, but recent messages seem to > indicate that it can at least basically function. > > The deployment appears to have been successful, everything is loading > correctly in the Wildfly system log on startup and the sample JSP pages > are displaying correctly... but the SignServer CLI at /bin/signserver > won't run. > > The initial exception appears to be: > Caused by: java.lang.IllegalStateException: EJBCLIENT000025: *No EJB > receiver available for handling [appName:signserver, > moduleName:SignServer-ejb, distinctName:] combination* for invocation > context org.jboss.ejb.client.EJBClientInvocationContext@4493d195 > > It occurs at while getting the initial global configuration: > at com.sun.proxy.$Proxy0.getGlobalConfiguration(Unknown Source) > at > org.signserver.admin.cli.defaultimpl.GetStatusCommand.execute(GetStatusCommand.java:72) > > The JBoss JNDI name it's trying to retrieve is: > *ejb:signserver/SignServer-ejb//GlobalConfigurationSessionBean!org.signserver.ejb.interfaces.IGlobalConfigurationSession$IRemote > * Just as you explore below the "No EJB recevier available for ..." typically means that either SignServer/JBoss hasn't started up completely or that the wrong connection configuration is used from the CLI. > According to the JBOSS server logfile, this bean has been successfully > created and exported (under jboss/exported) on startup: > > 2016-09-15 01:07:12,446 INFO [org.jboss.as.ejb3.deployment] (MSC > service thread 1-1) WFLYEJB0473: JNDI bindings for session bean named > 'GlobalConfigurationSessionBean' in deployment unit 'subdeployment > "SignServer-ejb.jar" of deployment "signserver.ear"' are as follows: > > > java:global/signserver/SignServer-ejb/GlobalConfigurationSessionBean!org.signserver.ejb.interfaces.IGlobalConfigurationSession$ILocal > > java:app/SignServer-ejb/GlobalConfigurationSessionBean!org.signserver.ejb.interfaces.IGlobalConfigurationSession$ILocal > > java:module/GlobalConfigurationSessionBean!org.signserver.ejb.interfaces.IGlobalConfigurationSession$ILocal > > java:global/signserver/SignServer-ejb/GlobalConfigurationSessionBean!org.signserver.ejb.interfaces.IGlobalConfigurationSession$IRemote > > java:app/SignServer-ejb/GlobalConfigurationSessionBean!org.signserver.ejb.interfaces.IGlobalConfigurationSession$IRemote > > java:module/GlobalConfigurationSessionBean!org.signserver.ejb.interfaces.IGlobalConfigurationSession$IRemote > * > java:jboss/exported/signserver/SignServer-ejb/GlobalConfigurationSessionBean!org.signserver.ejb.interfaces.IGlobalConfigurationSession$IRemote > * That is good but it could happen that it gets undeployed later due to some startup failure or that JBoss gets stuck at some point due to a configuration issue. What you want to look for is that you get the EVENT: SIGNSERVER_STARTUP and not any error following it. > > So it looks like a connection problem. My APPSRV_HOME is set correctly > to /opt/wildfly. I've successfully changed the connection port to 8080, > as mentioned in a previous email on this list; here's my > conf/jboss7/jboss-ejb-client.properties file: > > remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false > remote.connections=default > remote.connection.default.host=localhost > #remote.connection.default.port = 4447 > remote.connection.default.port = 8080 > remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false > > And yes, it should be hitting that properties file -- here's the > classpath when I try to invoke /bin/signserver: > > -cp*/opt/signserver/conf/jboss7*:/opt/wildfly/bin/client/jboss-client.jar:/opt/signserver/conf:/opt/signserver/lib/SignServer-AdminCLI.jar:/opt/signserver/res/cesecore:/opt/signserver/lib/ext/clover-dir/lib/clover.jar: Assuming SignServer and JBoss starts up correctly all the way then yes, the second thing to look for is to see that correct port is used just as you are doing. I'm not really seeing any problem here though. > > > So the question becomes... what else could I be missing? It's either a > Wildfly configuration issue or a client-side one; where else should I look? > > Cheers, > Jon BLum > Regards, Markus Kilås PrimeKey Solutions AB Save time and money with an Enterprise support subscription. Please see www.primekey.se for more information. https://www.primekey.se/technologies/products-overview/ https://www.primekey.se/service-support/support/ |
|
From: Blum, J. <jon...@or...> - 2016-09-16 08:00:15
|
Hello all --
I'm doing an initial build and setup of SignServer from source, with the
latest community version, as detailed on the Getting Started webpage. I
know that this version predates Wildfly 10, but recent messages seem to
indicate that it can at least basically function.
The deployment appears to have been successful, everything is loading
correctly in the Wildfly system log on startup and the sample JSP pages are
displaying correctly... but the SignServer CLI at /bin/signserver won't
run.
The initial exception appears to be:
Caused by: java.lang.IllegalStateException: EJBCLIENT000025: *No EJB
receiver available for handling [appName:signserver,
moduleName:SignServer-ejb, distinctName:] combination* for invocation
context org.jboss.ejb.client.EJBClientInvocationContext@4493d195
It occurs at while getting the initial global configuration:
at com.sun.proxy.$Proxy0.getGlobalConfiguration(Unknown Source)
at
org.signserver.admin.cli.defaultimpl.GetStatusCommand.execute(GetStatusCommand.java:72)
The JBoss JNDI name it's trying to retrieve is:
*ejb:signserver/SignServer-ejb//GlobalConfigurationSessionBean!org.signserver.ejb.interfaces.IGlobalConfigurationSession$IRemote*
According to the JBOSS server logfile, this bean has been successfully
created and exported (under jboss/exported) on startup:
2016-09-15 01:07:12,446 INFO [org.jboss.as.ejb3.deployment] (MSC service
thread 1-1) WFLYEJB0473: JNDI bindings for session bean named
'GlobalConfigurationSessionBean' in deployment unit 'subdeployment
"SignServer-ejb.jar" of deployment "signserver.ear"' are as follows:
java:global/signserver/SignServer-ejb/GlobalConfigurationSessionBean!org.signserver.ejb.interfaces.IGlobalConfigurationSession$ILocal
java:app/SignServer-ejb/GlobalConfigurationSessionBean!org.signserver.ejb.interfaces.IGlobalConfigurationSession$ILocal
java:module/GlobalConfigurationSessionBean!org.signserver.ejb.interfaces.IGlobalConfigurationSession$ILocal
java:global/signserver/SignServer-ejb/GlobalConfigurationSessionBean!org.signserver.ejb.interfaces.IGlobalConfigurationSession$IRemote
java:app/SignServer-ejb/GlobalConfigurationSessionBean!org.signserver.ejb.interfaces.IGlobalConfigurationSession$IRemote
java:module/GlobalConfigurationSessionBean!org.signserver.ejb.interfaces.IGlobalConfigurationSession$IRemote
*
java:jboss/exported/signserver/SignServer-ejb/GlobalConfigurationSessionBean!org.signserver.ejb.interfaces.IGlobalConfigurationSession$IRemote*
So it looks like a connection problem. My APPSRV_HOME is set correctly to
/opt/wildfly. I've successfully changed the connection port to 8080, as
mentioned in a previous email on this list; here's my
conf/jboss7/jboss-ejb-client.properties file:
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
#remote.connection.default.port = 4447
remote.connection.default.port = 8080
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
And yes, it should be hitting that properties file -- here's the classpath
when I try to invoke /bin/signserver:
-cp* /opt/signserver/conf/jboss7*:/opt/wildfly/bin/client/jboss-client.jar:/opt/signserver/conf:/opt/signserver/lib/SignServer-AdminCLI.jar:/opt/signserver/res/cesecore:/opt/signserver/lib/ext/clover-dir/lib/clover.jar:
So the question becomes... what else could I be missing? It's either a
Wildfly configuration issue or a client-side one; where else should I look?
Cheers,
Jon BLum
|
|
From: Tung, T. <tu...@sa...> - 2016-06-21 03:09:19
|
Dear Markus, Could you share me the root cause? when will signserver released 3.7.4 version? where could i download it now? this issue is happened in the signserver enterprise verion, isn’t it? Please confirm because we have a plan to buy signserver enterprise. Best Thanks, Tung. > On Jun 20, 2016, at 7:06 PM, Markus Kilås <ma...@pr...> wrote: > > On 06/20/2016 03:51 AM, Tung, Tran wrote: >>> On Jun 19, 2016, at 4:33 PM, Markus Kilås <ma...@pr... >>> <mailto:ma...@pr...>> wrote: >>> >>> On 06/16/2016 09:28 AM, Tung, Tran wrote: >>>> Dear Marcus, >>>> Please see the attached image. It show that the server is nearly 100% >>>> CPU usage when i load testing xml validator function >>>> >>> >>> Hi Tung, >>> >>> What configuration are you using for your validators? >>> Can you send your worker's configuration after dumping it from SignServer: >>> $ bin/signserver dumpproperties all workers-configuration.properties >>> >>> Remember to remove any passwords (if any) before sending it to the >>> mailing list. >>> >>> >>> Regards, >>> Markus >>> PrimeKey Solutions AB >>> >>> Save time and money with an Enterprise support subscription. Please see >>> www.primekey.se <http://www.primekey.se> for more information. >>> https://www.primekey.se/technologies/products-overview/ >>> https://www.primekey.se/service-support/support/ >>> >>> >> >> >> Dear Markus, >> Please find the attachment below. >> Please note that: com.stb.signserver.CertificateValidator plugin just >> return true for testing. >> >> Regards, >> Tung >> > > Hi Tung, > > I was finally able to reproduce the issue. > This will be fixed in 3.7.4. > > Regards, > Markus > PrimeKey Solutions AB > > PrimeKey Solutions offers a commercial EJBCA & SignServer support > subscription and training. Please see www.primekey.se or contact > in...@pr... for more information. > https://www.primekey.se/Services/Support/ > https://www.primekey.se/Services/Training/ > > Email này và những tài liệu đính kèm theo email là bảo mật và chỉ dành cho những cá nhân hoặc tổ chức được chỉ định nhận email. Nếu bạn không thuộc những người được chỉ định nhận email này, bạn vui lòng không sao chép, chuyển tiếp, tiết lộ thông tin hoặc sử dụng bất kỳ nội dung nào của email. Nếu bạn nhận được email này do lỗi của hệ thống, vui lòng xóa email này và tất cả các bản lưu khỏi hệ thống của bạn và thông báo ngay cho Sacombank theo email as...@sa... hoặc theo số điện thoại 1900 5555 88. Sacombank nghiêm cấm bất kỳ việc tiết lộ, sao chép, chuyển tiếp hoặc các hành động khác liên quan đến nội dung email này, trừ khi bạn là đối tượng được chỉ định nhận email. Chúng tôi không chịu trách nhiệm về vi rút máy tính, sai lạc dữ liệu, các trở ngại hoặc cản trở phát sinh từ hoặc liên quan đến email này. Xin vui lòng xem xét đến việc bảo vệ môi trường trước khi in. This email and any attachments to it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the addressee you should not copy, forward, disclose the whole email or any part of it. If you have received this message in error of system, please delete it from your system and notify Sacombank immediately by e-mail to as...@sa... or via telephone 1900 5555 88. Any disclosing, copying, distributing or taking action in reliance on the contents of this email are strictly prohibited, unless you are the intended recipient. Sacombank does not accept liability in connection with errors in the email, computer virus, data corruption, interference or delay arising from or in connection with this email. Please consider the environment before printing this email. |
8 messages has been excluded from this view by a project administrator.
