On Aug 13, 6:54 pm, Rishi <rishirenj...@gmail.com> wrote: > On Aug 13, 1:32 pm, Rishi <rishirenj...@gmail.com> wrote: > > > > > > > On Aug 13, 6:13 am, Nelson B Bolyard <nel...@bolyard.me> wrote: > > > > On 2009-08-12 03:43 PDT, Rishi Renjith wrote: > > > > > Hello, > > > > I tried creating a NSS database, linking it with crypto card and > > > > connecting using apache mod_nss. Everything works fine, except that the > > > > *rsaprivate *jobs are not getting increased in the kstat of the card. > > > > This is essentially the same issue that Rishi reported yesterday. > > > I think he is not seeing our replies. > > > > > *bash-3.00# modutil -list -dbdir . * > > > > Listing of PKCS #11 Modules > > > > 2. Sun Crypto Accelerator > > > > library name: /usr/lib/libpkcs11.so > > > > slots: 2 slots attached > > > > status: loaded > > > > > slot: Sun Metaslot > > > > token: Sun Metaslot > > > > > slot: Sun Crypto Softtoken > > > > token: Sun Software PKCS#11 softtoken > > > > There's obviously no crypto accelerator there. > > > > > Generating key. This may take a few moments... > > > > > Enter Password or Pin for "Sun Software PKCS#11 softtoken": > > > > The above prompt confirms that the key was generated in Sun's pure > > > software token, not in the SCA 6000 crypto accelerator token. > > > > When the SCA 6000 is properly configured, it shows up as one of the slot > > > and tokens in the list of slots and tokens (shown above) for the module > > > /usr/lib/libpkcs11.so. I searched today through Sun's public > > > documentation > > > trying to find out how to register the SCA 6000 with the MetaSlot so that > > > it would show up in that list, and could not find any documentation about > > > that. :( > > > > Sorry. > > > > /Nelson > > > Sorry, I was not receiving the replies you had posted earlier as I did > > not subscribe to the list. > > > When I do a cryptoadm list to list the providers, there are no s/w > > providers for RSA, as below. > > bash-3.00# cryptoadm list > > > User-level providers: > > Provider: /usr/lib/security/$ISA/pkcs11_kernel.so > > Provider: /usr/lib/security/$ISA/pkcs11_softtoken_extra.so > > > Kernel software providers: > > des > > aes256 > > arcfour2048 > > blowfish448 > > sha1 > > sha2 > > md5 > > swrand > > > Kernel hardware providers: > > mca/0 > > > I went through the documentation of the SCA6000 > > athttp://dlc.sun.com/pdf/819-5536-11/819-5536-11.pdf > > This is that they say... > > "Configuring Sun Metaslot to Use the Sun Crypto Accelerator 6000 > > Keystore > > > Through Sun Metaslot, only one keystore can be accessed. By default > > Sun Metaslot > > uses the Solaris Softtoken keystore. To access the Sun Crypto > > Accelerator 6000 > > keystore through Sun Metaslot, you must use one of the following > > configurations. > > ■ Configure Sun Metaslot to use the Sun Crypto Accelerator 6000 > > keystore systemwide > > using cryptoadm(1M). > > Enter the following command to use the Sun Crypto Accelerator 6000 > > keystore. > > For the example in this section, ks is the name of the Sun Crypto > > Accelerator 6000 > > cryptoadm enable metaslot token=ks > > This command forces a global change throughout the system, which > > causes all > > applications on the system to use the Sun Crypto Accelerator 6000 > > keystore by > > default." > > > I had done this earlier, nevertheless, I tried it again today as below > > > bash-3.00# cryptoadm list -v metaslot > > System-wide Meta Slot Configuration: > > ------------------------------------ > > Status: enabled > > Sensitive Token Object Automatic Migrate: disabled > > Persistent object store token: Military.602889 > > > Detailed Meta Slot Information: > > ------------------------------- > > actual status: enabled. > > Description: Sun Metaslot > > Token Present: True > > Token Label: Sun Metaslot > > Manufacturer ID: Sun Microsystems, Inc. > > Model: 1.0 > > Serial Number: > > Hardware Version: 0.0 > > Firmware Version: 0.0 > > UTC Time: > > PIN Length: 0-253 > > Flags: CKF_RNG CKF_LOGIN_REQUIRED CKF_USER_PIN_INITIALIZED > > CKF_TOKEN_INITIALIZED CKF_SO_PIN_LOCKED > > > bash-3.00# cryptoadm enable metaslot token="Military.602889" > > bash-3.00# > > > bash-3.00# modutil -list -dbdir . > > > 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. Sun Crypto Accelerator > > library name: /usr/lib/libpkcs11.so > > slots: 2 slots attached > > status: loaded > > > slot: Sun Metaslot > > token: Sun Metaslot > > > slot: Sun Crypto Softtoken > > token: Sun Software PKCS#11 softtoken > > ----------------------------------------------------------- > > bash-3.00# modutil -disable "NSS Internal PKCS #11 Module" -dbdir . > > WARNING: Performing this operation while the browser is running could > > cause > > corruption of your security databases. If the browser is currently > > running, > > you should exit browser before continuing this operation. Type > > 'q <enter>' to abort, or <enter> to continue: > > > Slot "NSS Internal Cryptographic Services" disabled. > > Slot "NSS User Private Key and Certificate Services" disabled. > > > bash-3.00# modutil -disable "Sun Crypto Accelerator" -dbdir . > > WARNING: Performing this operation while the browser is running could > > cause > > corruption of your security databases. If the browser is currently > > running, > > you should exit browser before continuing this operation. Type > > 'q <enter>' to abort, or <enter> to continue: > > > Slot "Sun Metaslot" disabled. > > Slot "Sun Crypto Softtoken" disabled. > > > bash-3.00# modutil -enable "Sun Crypto Accelerator" -slot "Sun > > Metaslot" -dbdir . > > WARNING: Performing this operation while the browser is running could > > cause > > corruption of your security databases. If the browser is currently > > running, > > you should exit browser before continuing this operation. Type > > 'q <enter>' to abort, or <enter> to continue: > > > Slot "Sun Metaslot" enabled. > > > Another strange thing is that when I check the kstat output, the > > AESjobs are getting incremented. This means that somehow the NSS is > > using the crypto hardware for symmetric jobs, but for asymmetric jobs, > > it is not using the h/w card. And also if you use it through JSSE, the > > card is correctly used for RSA jobs. > > > Is there any possibility the RSA jobs are getting done by the " NSS > > Internal PKCS #11 Module" that gets created automatically when we > > create the DB? It is clear from the previous mail that the the > > certificates and keys are stored in the card, only that the RSA jobs > > are not offloaded to the crypto card. I can retrieve even using pktool > > giving my hardware keystore as below. > > > bash-3.00# pktool list token=Military.602889 objtype=both > > Enter pin for Military.602889: > > Found 8 keys. > > Key #1 - RSA private key: > > Key #2 - RSA private key: sanCert > > Key #3 - RSA private key: > > Key #4 - RSA private key: > > Key #5 - RSA private key: > > Key #6 - RSA private key: > > Key #7 - RSA private key: fips999 > > Key #8 - RSA private key: > > Found 3 keys. > > Key #1 - AES: VSAT_AES_KEY (1077504064 bits) 256 bits > > Key #2 - AES: smc_encrptor (1077507264 bits) 256 bits > > Key #3 - AES: smcAesEncryptor (1077506944 bits) 256 bits > > Found 8 certificates. > > 1. (X.509 certificate) > > Label: ismc_cert > > ID: 4e:75:2a:9b:4a:76:c1:46:2d:9a:ec:76:de:16:17:e0:8d:07:ff: > > 42 > > Subject: CN=sandeeprc.eu.org > > Issuer: O=Root CA, OU=http://www.cacert.org, CN=CA Cert > > Signing Authority, emailaddress=supp...@cacert.org > > Serial: 0x0747A9 > > X509v3 Subject Alternative Name: > > DNS:sandeeprc.eu.org, othername:<unsupported> > > > 2. (X.509 certificate) > > Label: CACERT CA > > ID: c8:1e:42:ce:da:0b:c1:d6:5c:90:51:b0:eb: > > 86:79:e2:9d:d6:c0:67 > > Subject: O=Root CA, OU=http://www.cacert.org, CN=CA Cert > > Signing Authority, emailaddress=supp...@cacert.org > > Issuer: O=Root CA, OU=http://www.cacert.org, CN=CA Cert > > Signing Authority, emailaddress=supp...@cacert.org > > Serial: 0x00 > > Finally I found a solution!!! Googled till cows came home and finally > found that if you add METASLOT_DISABLED=false in env variables, then > rsa jobs get offloaded to the crypto card. But it still gives me "ssl > handshake failure", this i think i should ask in the mod_nss forum. > > Thanks!!!!
OK , we have made some progress, we could disable the softtoken by commenting the line softtoken_extra.so in mca.conf in /kernel/drv/. Now we got an SSL handshake error "bad MAC". This we thought would be because the crypto card does not support hashing algorithms in 1.0 firmware, hence we updated the firmware of sca6000 to 1.1. Again created the keystore in the card. Created new NSS DB as before, and created certificates in the keystore. -Verified that the certificates are stored in the keystore using "pktool list token=ks objtype=both". It listed both the RSA private key and cert. -cryptoadm list -v, shows mca0 as a hardware provider, indicating that the card is properly configured. -modutil -list -dbdir . displays the keystore as a token as METASLOT_ENABLED is set to false. Now the issue is that whenever we try to access the certificates through NSS using apache mod_nss, it finds the certificate for the first time and on subsequent tries, fails. Actually it tries to access the cert from the card a huge number of times and fails. Also the mca/ 0 disappears from the cryptoadm list -v output. Now the card is shown as failed and we have to reboot to get the card working again. This happens only if we use NSS to connect to the card. If we use JSSE to directly access the card, we can access the certs and pvt key successfully. below is a sample of the logs generated. "Wed Aug 19 13:31:59 2009] [info] Configuring server for SSL protocol [Wed Aug 19 13:31:59 2009] [info] In FIPS mode, enabling TLSv1 [Wed Aug 19 13:31:59 2009] [debug] nss_engine_init.c(765): FIPS mode enabled, permitted SSL ciphers are: [+rsa_3des_sha,+fips_3des_sha, +rsa_aes_128_sha,+rsa_aes_256_sha] [Wed Aug 19 13:31:59 2009] [debug] nss_engine_init.c(770): Configuring permitted SSL ciphers [+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,- rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,- fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,- rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha] [Wed Aug 19 13:31:59 2009] [info] Using nickname militaryks:cert111. [Wed Aug 19 13:31:59 2009] [error] Certificate not verified: 'militaryks:cert111' [Wed Aug 19 13:31:59 2009] [error] SSL Library Error: -8156 Issuer certificate is invalid [Wed Aug 19 13:32:02 2009] [debug] proxy_util.c(1786): proxy: worker ajp://localhost:8009/smc/login already initialized [Wed Aug 19 13:32:02 2009] [debug] proxy_util.c(1786): proxy: worker ajp://localhost:8009/smc/app already initialized [Wed Aug 19 13:32:02 2009] [debug] proxy_util.c(1786): proxy: worker ajp://localhost:8009/smc/login already initialized [Wed Aug 19 13:32:02 2009] [debug] proxy_util.c(1786): proxy: worker ajp://localhost:8009/smc/app already initialized [Wed Aug 19 13:32:02 2009] [debug] proxy_util.c(1786): proxy: worker ajp://localhost:8009/smc/login already initialized [Wed Aug 19 13:32:02 2009] [debug] proxy_util.c(1786): proxy: worker ajp://localhost:8009/smc/app already initialized [Wed Aug 19 13:32:02 2009] [debug] proxy_util.c(1786): proxy: worker ajp://localhost:8009/smc/login already initialized [Wed Aug 19 13:32:02 2009] [debug] proxy_util.c(1786): proxy: worker ajp://localhost:8009/smc/app already initialized [Wed Aug 19 13:32:02 2009] [debug] proxy_util.c(1786): proxy: worker ajp://localhost:8009/smc/login already initialized [Wed Aug 19 13:32:02 2009] [debug] proxy_util.c(1786): proxy: worker ajp://localhost:8009/smc/app already initialized [Wed Aug 19 13:32:02 2009] [info] Configuring server for SSL protocol [Wed Aug 19 13:32:02 2009] [info] In FIPS mode, enabling TLSv1 [Wed Aug 19 13:32:02 2009] [debug] nss_engine_init.c(765): FIPS mode enabled, permitted SSL ciphers are: [+rsa_3des_sha,+fips_3des_sha, +rsa_aes_128_sha,+rsa_aes_256_sha] [Wed Aug 19 13:32:02 2009] [debug] nss_engine_init.c(770): Configuring permitted SSL ciphers [+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,- rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,- fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,- rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha] [Wed Aug 19 13:32:02 2009] [info] Using nickname militaryks:cert111. [Wed Aug 19 13:32:02 2009] [error] Certificate not found: 'militaryks:cert111' [Wed Aug 19 13:32:02 2009] [info] Configuring server for SSL protocol [Wed Aug 19 13:32:02 2009] [info] In FIPS mode, enabling TLSv1 [Wed Aug 19 13:32:02 2009] [debug] nss_engine_init.c(765): FIPS mode enabled, permitted SSL ciphers are: [+rsa_3des_sha,+fips_3des_sha, +rsa_aes_128_sha,+rsa_aes_256_sha] [Wed Aug 19 13:32:02 2009] [debug] nss_engine_init.c(770): Configuring permitted SSL ciphers [+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,- rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,- fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,- rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha] [Wed Aug 19 13:32:02 2009] [info] Using nickname militaryks:cert111. [Wed Aug 19 13:32:02 2009] [error] Certificate not found: 'militaryks:cert111' [Wed Aug 19 13:32:02 2009] [info] Configuring server for SSL protocol" I see that someone had a similar issue with NSS, described here https://bugzilla.redhat.com/show_bug.cgi?id=446851 and https://bugzilla.mozilla.org/show_bug.cgi?id=434043 The NSS version we use is 3.12.3. Any hints or helps are appreciated. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
