Hi, I've updated DogTag to the current modules available (FC11 x86_64): dogtag-pki-ca-ui-1.3.1-1.fc11.noarch dogtag-pki-common-ui-1.3.1-1.fc11.noarch dogtag-pki-console-ui-1.3.1-1.fc11.noarch pki-ca-1.3.3-1.fc11.noarch pki-common-1.3.3-1.fc11.noarch pki-console-1.3.1-1.fc11.noarch pki-java-tools-1.3.1-1.fc11.noarch pki-native-tools-1.3.0-5.fc11.x86_64 pki-selinux-1.3.4-1.fc11.noarch pki-setup-1.3.4-1.fc11.noarch pki-silent-1.3.2-1.fc11.noarch pki-symkey-1.3.2-3.fc11.x86_64 pki-util-1.3.0-5.fc11.noarch I've installed and successfully tested a Utimaco CryptoServer HSM on the operating system, including adding it to secmod.db (in the /var/lib/subca01/alias directory), generating a RSA key-pair, issuing a self-signed and listing the objects using certutil (the attached hsm-config.txt file shows sample output). I've modified CS.cfg in /etc/subca01 to include this token (as the attached modules.txt file shows). I've even restarted pki-cad services after adding the HSM to secmod.db, to ensure that the DogTag code reads secmod.db with the CryptoServer configured in it. However, when it comes time to install a Subordinate CA, the KeyStore page claims that the Utimaco HSM is not found (see keystore-page.png) even though it is correctly listed on the page under "Supported Security Modules". What am I missing? How do I get DogTag to use the HSM to generate the key-pair? Thanks. Arshad Noor StrongAuth, Inc. _______________________________________________ Pki-users mailing list Pki-users(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-users

Hi, I've updated DogTag to the current modules available (FC11 x86_64): dogtag-pki-ca-ui-1.3.1-1.fc11.noarch dogtag-pki-common-ui-1.3.1-1.fc11.noarch dogtag-pki-console-ui-1.3.1-1.fc11.noarch pki-ca-1.3.3-1.fc11.noarch pki-common-1.3.3-1.fc11.noarch pki-console-1.3.1-1.fc11.noarch pki-java-tools-1.3.1-1.fc11.noarch pki-native-tools-1.3.0-5.fc11.x86_64 pki-selinux-1.3.4-1.fc11.noarch pki-setup-1.3.4-1.fc11.noarch pki-silent-1.3.2-1.fc11.noarch pki-symkey-1.3.2-3.fc11.x86_64 pki-util-1.3.0-5.fc11.noarch I've installed and successfully tested a Utimaco CryptoServer HSM on the operating system, including adding it to secmod.db (in the /var/lib/subca01/alias directory), generating a RSA key-pair, issuing a self-signed and listing the objects using certutil (the attached hsm-config.txt file shows sample output). I've modified CS.cfg in /etc/subca01 to include this token (as the attached modules.txt file shows). I've even restarted pki-cad services after adding the HSM to secmod.db, to ensure that the DogTag code reads secmod.db with the CryptoServer configured in it. However, when it comes time to install a Subordinate CA, the KeyStore page claims that the Utimaco HSM is not found (see keystore-page.png) even though it is correctly listed on the page under "Supported Security Modules". What am I missing? How do I get DogTag to use the HSM to generate the key-pair? Thanks. Arshad Noor StrongAuth, Inc. _______________________________________________ Pki-users mailing list Pki-users(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-users

Hi Arshad, Just a thought. Did you try removing the space for your token name? Christina Arshad Noor wrote: > Can someone from the DogTag team explain the process by which > the installation servlet "finds" PKCS11 modules/HSMs and logs > into them? Alternatively, if you can point me to the specific > source module that performs this, I'd be happy to look at it > myself. > > I'm still baffled by our inability to have the installation > servlet find the Utimaco HSM module, despite the fact that > modutil sees it: > > $ pet105:~> modutil -dbdir /var/lib/subca01/alias -nocertdb -list > > Listing of PKCS #11 Modules > ----------------------------------------------------------- > 1. NSS Internal PKCS #11 Module > slots: 2 slots attached > status: loaded > > slot: NSS Internal Cryptographic Services > token: NSS Generic Crypto Services > > slot: NSS User Private Key and Certificate Services > token: NSS Certificate DB > > 2. CryptoServer > library name: /usr/bin/libcs2_pkcs11.so > slots: 1 slot attached > status: loaded > > slot: CryptoServer Device '/dev/cs2' - Slot No: 0 > token: CBUAE TEST > ----------------------------------------------------------- > > > There were some SELinux errors, but I fixed all of them; despite > all calls now being successful, the installation servlet will > still not see the HSM. > > Thanks. > > Arshad Noor > StrongAuth, Inc. > > _______________________________________________ > Pki-users mailing list > Pki-users(a)redhat.com > https://www.redhat.com/mailman/listinfo/pki-users

Arshad, I'm curious. The unsupported modules are supposed to be picked up by the configuration module. That means, you don't need to add those configModules in the CS.cfg. Can you try doing that? If that works, I'd be interested in knowing if the token name with space contributed to any part of the issue too. Chistina Arshad Noor wrote: > Hi Christina, > > Good to hear from you again. > > I changed the token name and removed the space, but nothing changed, > unfortunately: > > Listing of PKCS #11 Modules > ----------------------------------------------------------- > 1. NSS Internal PKCS #11 Module > slots: 2 slots attached > status: loaded > > slot: NSS Internal Cryptographic Services > token: NSS Generic Crypto Services > > slot: NSS User Private Key and Certificate Services > token: NSS Certificate DB > > 2. CryptoServer > library name: /usr/bin/libcs2_pkcs11.so > slots: 1 slot attached > status: loaded > > slot: CryptoServer Device '/dev/cs2' - Slot No: 0 > token: CBUAETEST > ----------------------------------------------------------- > > The debug file for the new CA instance shows: > > ------------------------------------------- > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: display() > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got > module NSS Internal PKCS #11 Module > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: supported > modules count= 4 > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got from > config module: NSS Internal PKCS #11 Module > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: module > found: NSS Internal PKCS #11 Module > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token > nick name=NSS Generic Crypto Services > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token > logged in?false > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token is > present?true > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token NSS > Generic Crypto Services not to be added > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token > nick name=Internal Key Storage Token > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token > logged in?true > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token is > present?true > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding > module NSS Internal PKCS #11 Module > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got from > config module: nfast > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding > module nfast > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got from > config module: lunasa > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding > module lunasa > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got from > config module: CryptoServer > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding > module CryptoServer > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel subpanelno =9 > ------------------------------------------- > > The CS.cfg for this instance has the following: > > ------------------------------------------- > preop.configModules.count=4 > ... > preop.configModules.module3.commonName=CryptoServer > preop.configModules.module3.imagePath=../img/clearpixel.gif > preop.configModules.module3.userFriendlyName=Utimacos's CryptoServer > Hardware Security Module > preop.module.token=CBUAETEST > ------------------------------------------- > > Arshad Noor > StrongAuth, Inc. > > Christina Fu wrote: >> Hi Arshad, >> >> Just a thought. Did you try removing the space for your token name? >> >> Christina >> >> Arshad Noor wrote: >>> Can someone from the DogTag team explain the process by which >>> the installation servlet "finds" PKCS11 modules/HSMs and logs >>> into them? Alternatively, if you can point me to the specific >>> source module that performs this, I'd be happy to look at it >>> myself. >>> >>> I'm still baffled by our inability to have the installation >>> servlet find the Utimaco HSM module, despite the fact that >>> modutil sees it: >>> >>> $ pet105:~> modutil -dbdir /var/lib/subca01/alias -nocertdb -list >>> >>> Listing of PKCS #11 Modules >>> ----------------------------------------------------------- >>> 1. NSS Internal PKCS #11 Module >>> slots: 2 slots attached >>> status: loaded >>> >>> slot: NSS Internal Cryptographic Services >>> token: NSS Generic Crypto Services >>> >>> slot: NSS User Private Key and Certificate Services >>> token: NSS Certificate DB >>> >>> 2. CryptoServer >>> library name: /usr/bin/libcs2_pkcs11.so >>> slots: 1 slot attached >>> status: loaded >>> >>> slot: CryptoServer Device '/dev/cs2' - Slot No: 0 >>> token: CBUAE TEST >>> ----------------------------------------------------------- >>> >>> >>> There were some SELinux errors, but I fixed all of them; despite >>> all calls now being successful, the installation servlet will >>> still not see the HSM. >>> >>> Thanks. >>> >>> Arshad Noor >>> StrongAuth, Inc. >>> >>> _______________________________________________ >>> Pki-users mailing list >>> Pki-users(a)redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-users >>

I'm afraid it didn't pick up the new module, Christina. modutil shows it correctly, but as you can see from the attached PNG, the servlet did not find the HSM.

Based on Michael StJohn's postings and some feedback I have from the vendor, it appears that the 32-bit version of DogTag may be working; but we're testing on a 64-bit version of Fedora 11 and DogTag. Could that be causing the problem? The PKCS11 library from the HSM vendor is 64-bit. Arshad Noor StrongAuth, Inc. Arshad Noor wrote: > So, if I understand you correctly, you want me to: > > 1) Make sure that the module is configured correctly in the > new CA instance's alias/secmod.db file; and > > 2) Remove all references to the new HSM from CS.cfg, use a > default CS.cfg, so that your configuration module code > adds it to CS.cfg based on what's configured in secmod.db? > > Will get back to you in about 15 minutes. > > Arshad Noor > StrongAuth, Inc. > > Christina Fu wrote: >> Arshad, >> >> I'm curious. The unsupported modules are supposed to be picked up >> by the configuration module. That means, you don't need to add >> those configModules in the CS.cfg. >> Can you try doing that? >> If that works, I'd be interested in knowing if the token name with >> space contributed to any part of the issue too. >> >> Chistina >> >> Arshad Noor wrote: >>> Hi Christina, >>> >>> Good to hear from you again. >>> >>> I changed the token name and removed the space, but nothing changed, >>> unfortunately: >>> >>> Listing of PKCS #11 Modules >>> ----------------------------------------------------------- >>> 1. NSS Internal PKCS #11 Module >>> slots: 2 slots attached >>> status: loaded >>> >>> slot: NSS Internal Cryptographic Services >>> token: NSS Generic Crypto Services >>> >>> slot: NSS User Private Key and Certificate Services >>> token: NSS Certificate DB >>> >>> 2. CryptoServer >>> library name: /usr/bin/libcs2_pkcs11.so >>> slots: 1 slot attached >>> status: loaded >>> >>> slot: CryptoServer Device '/dev/cs2' - Slot No: 0 >>> token: CBUAETEST >>> ----------------------------------------------------------- >>> >>> The debug file for the new CA instance shows: >>> >>> ------------------------------------------- >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: display() >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got >>> module NSS Internal PKCS #11 Module >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: >>> supported modules count= 4 >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got >>> from config module: NSS Internal PKCS #11 Module >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: module >>> found: NSS Internal PKCS #11 Module >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token >>> nick name=NSS Generic Crypto Services >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token >>> logged in?false >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token >>> is present?true >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token >>> NSS Generic Crypto Services not to be added >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token >>> nick name=Internal Key Storage Token >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token >>> logged in?true >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token >>> is present?true >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding >>> module NSS Internal PKCS #11 Module >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got >>> from config module: nfast >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding >>> module nfast >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got >>> from config module: lunasa >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding >>> module lunasa >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got >>> from config module: CryptoServer >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding >>> module CryptoServer >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel >>> subpanelno =9 >>> ------------------------------------------- >>> >>> The CS.cfg for this instance has the following: >>> >>> ------------------------------------------- >>> preop.configModules.count=4 >>> ... >>> preop.configModules.module3.commonName=CryptoServer >>> preop.configModules.module3.imagePath=../img/clearpixel.gif >>> preop.configModules.module3.userFriendlyName=Utimacos's >>> CryptoServer Hardware Security Module >>> preop.module.token=CBUAETEST >>> ------------------------------------------- >>> >>> Arshad Noor >>> StrongAuth, Inc. >>> >>> Christina Fu wrote: >>>> Hi Arshad, >>>> >>>> Just a thought. Did you try removing the space for your token name? >>>> >>>> Christina >>>> >>>> Arshad Noor wrote: >>>>> Can someone from the DogTag team explain the process by which >>>>> the installation servlet "finds" PKCS11 modules/HSMs and logs >>>>> into them? Alternatively, if you can point me to the specific >>>>> source module that performs this, I'd be happy to look at it >>>>> myself. >>>>> >>>>> I'm still baffled by our inability to have the installation >>>>> servlet find the Utimaco HSM module, despite the fact that >>>>> modutil sees it: >>>>> >>>>> $ pet105:~> modutil -dbdir /var/lib/subca01/alias -nocertdb -list >>>>> >>>>> Listing of PKCS #11 Modules >>>>> ----------------------------------------------------------- >>>>> 1. NSS Internal PKCS #11 Module >>>>> slots: 2 slots attached >>>>> status: loaded >>>>> >>>>> slot: NSS Internal Cryptographic Services >>>>> token: NSS Generic Crypto Services >>>>> >>>>> slot: NSS User Private Key and Certificate Services >>>>> token: NSS Certificate DB >>>>> >>>>> 2. CryptoServer >>>>> library name: /usr/bin/libcs2_pkcs11.so >>>>> slots: 1 slot attached >>>>> status: loaded >>>>> >>>>> slot: CryptoServer Device '/dev/cs2' - Slot No: 0 >>>>> token: CBUAE TEST >>>>> ----------------------------------------------------------- >>>>> >>>>> >>>>> There were some SELinux errors, but I fixed all of them; despite >>>>> all calls now being successful, the installation servlet will >>>>> still not see the HSM. >>>>> >>>>> Thanks. >>>>> >>>>> Arshad Noor >>>>> StrongAuth, Inc. >>>>> >>>>> _______________________________________________ >>>>> Pki-users mailing list >>>>> Pki-users(a)redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pki-users >>>> >> > > _______________________________________________ > Pki-users mailing list > Pki-users(a)redhat.com > https://www.redhat.com/mailman/listinfo/pki-users _______________________________________________ Pki-users mailing list Pki-users(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-users

Interesting; it did not: # pet105:~> modutil -dbdir /var/lib/subca01/alias/ -nocertdb -list Listing of PKCS #11 Modules ----------------------------------------------------------- 1. NSS Internal PKCS #11 Module slots: 2 slots attached status: loaded slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services slot: NSS User Private Key and Certificate Services token: NSS Certificate DB 2. CryptoServer library name: /usr/bin/libcs2_pkcs11.so slots: 1 slot attached status: loaded slot: CryptoServer Device '/dev/cs2' - Slot No: 0 token: CBUAETEST ----------------------------------------------------------- # pet105:~> TokenInfo /var/lib/subca01/alias Database Path: /var/lib/subca01/alias Found external module 'NSS Internal PKCS #11 Module' # pet105:~> And there were no SELinux errors in the audit log.

Arshad Noor StrongAuth, Inc. Chandrasekar Kannan wrote: > > Looks like the NSS layer has no problems identifying the token. > can you use this tool and see if the JSS layer can see it as well ? > > http://www.redhat.com/docs/manuals/cert-system/8.0/cli/html/TokenInfo.html > >

No luck. ------------- # pet105:~> setenforce 0 # pet105:~> TokenInfo /var/lib/subca01/alias Database Path: /var/lib/subca01/alias Found external module 'NSS Internal PKCS #11 Module' # pet105:~> ------------- Output from audit.log: ------------- type=MAC_STATUS msg=audit(1271980444.565:345): enforcing=0 old_enforcing=1 auid=500 ses=5 type=SYSCALL msg=audit(1271980444.565:345): arch=c000003e syscall=1 success=yes exit=1 a0=3 a1=7fff300dfb20 a2=1 a3=fffffff8 items=0 ppid=32217 pid=32292 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts4 ses=5 comm="setenforce" exe="/usr/sbin/setenforce" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) ------------- Arshad Noor StrongAuth, Inc. Chandrasekar Kannan wrote: > On 04/22/2010 04:44 PM, Arshad Noor wrote: >> Interesting; it did not: >> >> # pet105:~> modutil -dbdir /var/lib/subca01/alias/ -nocertdb -list >> >> Listing of PKCS #11 Modules >> ----------------------------------------------------------- >> 1. NSS Internal PKCS #11 Module >> slots: 2 slots attached >> status: loaded >> >> slot: NSS Internal Cryptographic Services >> token: NSS Generic Crypto Services >> >> slot: NSS User Private Key and Certificate Services >> token: NSS Certificate DB >> >> 2. CryptoServer >> library name: /usr/bin/libcs2_pkcs11.so >> slots: 1 slot attached >> status: loaded >> >> slot: CryptoServer Device '/dev/cs2' - Slot No: 0 >> token: CBUAETEST >> ----------------------------------------------------------- >> # pet105:~> TokenInfo /var/lib/subca01/alias >> Database Path: /var/lib/subca01/alias >> Found external module 'NSS Internal PKCS #11 Module' >> # pet105:~> >> >> And there were no SELinux errors in the audit log. > > Can you 'setenforce 0' (putting selinux to permissive mode ) > and try one more time ?. > > >> >> Arshad Noor >> StrongAuth, Inc. >> >> >> Chandrasekar Kannan wrote: >>> >>> Looks like the NSS layer has no problems identifying the token. >>> can you use this tool and see if the JSS layer can see it as well ? >>> >>> http://www.redhat.com/docs/manuals/cert-system/8.0/cli/html/TokenInfo.html >>> >>> > _______________________________________________ Pki-users mailing list Pki-users(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-users

On 04/26/2010 09:51 AM, Arshad Noor wrote: > Do you have any update on the JSS issue, Chandrasekar? Thanks. I don't. We may need to debug the JSS code to figure out what the problem is.... > > Arshad Noor > StrongAuth, Inc. > > Arshad Noor wrote: >> No luck. >> >> ------------- >> # pet105:~> setenforce 0 >> # pet105:~> TokenInfo /var/lib/subca01/alias >> Database Path: /var/lib/subca01/alias >> Found external module 'NSS Internal PKCS #11 Module' >> # pet105:~> >> ------------- >> >> Output from audit.log: >> >> ------------- >> type=MAC_STATUS msg=audit(1271980444.565:345): enforcing=0 >> old_enforcing=1 auid=500 ses=5 >> type=SYSCALL msg=audit(1271980444.565:345): arch=c000003e syscall=1 >> success=yes exit=1 a0=3 a1=7fff300dfb20 a2=1 a3=fffffff8 items=0 >> ppid=32217 pid=32292 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 >> egid=0 sgid=0 fsgid=0 tty=pts4 ses=5 comm="setenforce" >> exe="/usr/sbin/setenforce" >> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) >> ------------- >> >> Arshad Noor >> StrongAuth, Inc. >> >> Chandrasekar Kannan wrote: >>> On 04/22/2010 04:44 PM, Arshad Noor wrote: >>>> Interesting; it did not: >>>> >>>> # pet105:~> modutil -dbdir /var/lib/subca01/alias/ -nocertdb -list >>>> >>>> Listing of PKCS #11 Modules >>>> ----------------------------------------------------------- >>>> 1. NSS Internal PKCS #11 Module >>>> slots: 2 slots attached >>>> status: loaded >>>> >>>> slot: NSS Internal Cryptographic Services >>>> token: NSS Generic Crypto Services >>>> >>>> slot: NSS User Private Key and Certificate Services >>>> token: NSS Certificate DB >>>> >>>> 2. CryptoServer >>>> library name: /usr/bin/libcs2_pkcs11.so >>>> slots: 1 slot attached >>>> status: loaded >>>> >>>> slot: CryptoServer Device '/dev/cs2' - Slot No: 0 >>>> token: CBUAETEST >>>> ----------------------------------------------------------- >>>> # pet105:~> TokenInfo /var/lib/subca01/alias >>>> Database Path: /var/lib/subca01/alias >>>> Found external module 'NSS Internal PKCS #11 Module' >>>> # pet105:~> >>>> >>>> And there were no SELinux errors in the audit log. >>> >>> Can you 'setenforce 0' (putting selinux to permissive mode ) >>> and try one more time ?. >>> >>> >>>> >>>> Arshad Noor >>>> StrongAuth, Inc. >>>> >>>> >>>> Chandrasekar Kannan wrote: >>>>> >>>>> Looks like the NSS layer has no problems identifying the token. >>>>> can you use this tool and see if the JSS layer can see it as well ? >>>>> >>>>> http://www.redhat.com/docs/manuals/cert-system/8.0/cli/html/TokenInfo.html >>>>> >>>>> >>> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users(a)redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users _______________________________________________ Pki-users mailing list Pki-users(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-users

On 4/26/2010 10:46 PM, Christina Fu wrote: > Actually, I did spend some time looking into JSS code. The result was > inconclusive. The code appeared to be reasonable. I do suspect, > however, without looking closely at the code, that somehow the module > is unloaded somewhere along the way. > I'm curious whether this is an issue on this particular HSM, or if > it's a matter of handling external modules (including software > modules) in general. > Has anyone had any success installing/using certicom module on this > platform, for example? > > Again, I did not see any email from another member (StJohns?) that you > mentioned claiming success with Utimaco HSM on a 32 bit machine... > could you please forward the email? > Another thing is, I'm not familiar with Utimaco HSM, but you might > want to find out how to turn on debugger. > > Otherwise, try turning on NSS debugging, which might give you some clue. > > Christina > Hi Christina - I had to put work on this aside for a few days, but am getting back to it. I've had uneven results. The time that I got the HSM to show up with the slots, but I didn't get the "Login" button. This time, I didn't even get the HSM to show up. The first time, I added the HSM manually, the second via a mod to the create script. Still working my way through it. I modified pki_create_instance to add both the Utimaco library and the Coolkey PKCS11 libary. I had to turn off SELinux enforcement to get Coolkey to show up on the list, but even then, the Utimaco lib didn't. I haven't had a chance to go back and check again. Mike _______________________________________________ Pki-users mailing list Pki-users(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-users

OK - Using my recompiled/relinked version of the Utimaco library on Fedora 12 - 32 bit. I can consistently get the Utimaco library to show up in the list with the three slots I've initialized. BUT - none of those show up with the "Login" button. The reason I couldn't get it to work before was because of the coolkey library... if that libary is loaded (name "coolkey"), modutil and TokenInfo both see it, but only the coolkey library gets listed on the setup page. I deleted the coolkey library, restarted the server and the Utimaco slots showed up. I re-added the coolkey library with the name "zcoolkey", restarted the server - only the Utimaco slots showed up. - At this point I got suspicious and tried one more thing. I deleted the Utimaco library with the name "utimaco", restarted the server. The zcoolkey library showed up. Hmm..... looks like for some reason, only the first module (alphabetically) is being listed/loaded. Mike On 4/27/2010 8:51 PM, Arshad Noor wrote: > Was this on a 32-bit or 64-bit environment, Mike? I was planning to > test this with the 32-bit version of Fedora 11, based on your assertion > that it worked. But, now it appears that this might be unpredictable. > Is that right? > > Arshad Noor > StrongAuth, Inc. > > Michael StJohns wrote: >> On 4/26/2010 10:46 PM, Christina Fu wrote: >>> Actually, I did spend some time looking into JSS code. The result >>> was inconclusive. The code appeared to be reasonable. I do >>> suspect, however, without looking closely at the code, that somehow >>> the module is unloaded somewhere along the way. >>> I'm curious whether this is an issue on this particular HSM, or if >>> it's a matter of handling external modules (including software >>> modules) in general. >>> Has anyone had any success installing/using certicom module on this >>> platform, for example? >>> >>> Again, I did not see any email from another member (StJohns?) that >>> you mentioned claiming success with Utimaco HSM on a 32 bit >>> machine... could you please forward the email? >>> Another thing is, I'm not familiar with Utimaco HSM, but you might >>> want to find out how to turn on debugger. >>> >>> Otherwise, try turning on NSS debugging, which might give you some >>> clue. >>> >>> Christina >>> >> >> Hi Christina - >> >> I had to put work on this aside for a few days, but am getting back >> to it. I've had uneven results. The time that I got the HSM to show >> up with the slots, but I didn't get the "Login" button. This time, I >> didn't even get the HSM to show up. The first time, I added the HSM >> manually, the second via a mod to the create script. Still working >> my way through it. >> >> I modified pki_create_instance to add both the Utimaco library and >> the Coolkey PKCS11 libary. I had to turn off SELinux enforcement to >> get Coolkey to show up on the list, but even then, the Utimaco lib >> didn't. I haven't had a chance to go back and check again. >> >> Mike >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users(a)redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users

OK - Using my recompiled/relinked version of the Utimaco library on Fedora 12 - 32 bit. I can consistently get the Utimaco library to show up in the list with the three slots I've initialized. BUT - none of those show up with the "Login" button. The reason I couldn't get it to work before was because of the coolkey library... if that libary is loaded (name "coolkey"), modutil and TokenInfo both see it, but only the coolkey library gets listed on the setup page. I deleted the coolkey library, restarted the server and the Utimaco slots showed up. I re-added the coolkey library with the name "zcoolkey", restarted the server - only the Utimaco slots showed up. - At this point I got suspicious and tried one more thing. I deleted the Utimaco library with the name "utimaco", restarted the server. The zcoolkey library showed up. Hmm..... looks like for some reason, only the first module (alphabetically) is being listed/loaded. Mike On 4/27/2010 8:51 PM, Arshad Noor wrote: > Was this on a 32-bit or 64-bit environment, Mike? I was planning to > test this with the 32-bit version of Fedora 11, based on your assertion > that it worked. But, now it appears that this might be unpredictable. > Is that right? > > Arshad Noor > StrongAuth, Inc. > > Michael StJohns wrote: >> On 4/26/2010 10:46 PM, Christina Fu wrote: >>> Actually, I did spend some time looking into JSS code. The result >>> was inconclusive. The code appeared to be reasonable. I do >>> suspect, however, without looking closely at the code, that somehow >>> the module is unloaded somewhere along the way. >>> I'm curious whether this is an issue on this particular HSM, or if >>> it's a matter of handling external modules (including software >>> modules) in general. >>> Has anyone had any success installing/using certicom module on this >>> platform, for example? >>> >>> Again, I did not see any email from another member (StJohns?) that >>> you mentioned claiming success with Utimaco HSM on a 32 bit >>> machine... could you please forward the email? >>> Another thing is, I'm not familiar with Utimaco HSM, but you might >>> want to find out how to turn on debugger. >>> >>> Otherwise, try turning on NSS debugging, which might give you some >>> clue. >>> >>> Christina >>> >> >> Hi Christina - >> >> I had to put work on this aside for a few days, but am getting back >> to it. I've had uneven results. The time that I got the HSM to >> show up with the slots, but I didn't get the "Login" button. This >> time, I didn't even get the HSM to show up. The first time, I added >> the HSM manually, the second via a mod to the create script. Still >> working my way through it. >> >> I modified pki_create_instance to add both the Utimaco library and >> the Coolkey PKCS11 libary. I had to turn off SELinux enforcement >> to get Coolkey to show up on the list, but even then, the Utimaco >> lib didn't. I haven't had a chance to go back and check again. >> >> Mike >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users(a)redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users

Appreciate everything you're mentioning about this, Mike; can you clarify one last item? What do you mean by the following statement? Thanks. Arshad Noor StrongAuth, Inc. Michael StJohns wrote: > > > Add utimaco to the pkicreate script in /usr/bin

All it seems to be doing is adding the PKCS11 library to the secmod.db for the new instance it is creating - something one can do manually even after the instance has been created.

You do have to restart the service so the servlet sees the new module in secmod.db, but I don't think it does anything else. Arshad Noor StrongAuth, Inc. P.S. How I miss the old Java installation wizard CS had; it was simple, elegant and allowed for significant configuration in the wizard. You could have an instance of a CA up and running in less than 5 minutes. Between rpm, perl scripts, HTML and servlets, the new installation process appears to have made installation one of the most complex parts of setting up a DogTag PKI. What a pity.

I've run into an issue that seems to be unresolved from a thread back in Nov 2009: https://www.redhat.com/archives/pki-users/2009-November/msg00017.html Bugzilla apparently has the fix and the server.xml has the right values for clientAuth, but the bad MAC error keeps appearing for every HTTPS page in my test installation. Is there any resolution to John Dorovski's problem? His last message remains unanswered.