Re: [SignServer-develop] Luna SA configuration problem

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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
>