Re: [SignServer-develop] Luna SA configuration problem

[Blum, J. <jon...@or...>]

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
>
>