Oh blimey!! Thanks Gary :) Now the card displays firmware version as 1.1.2...
And one more thing.. I went back and tried configuring from the scratch, and I found that the issue is with openssl (6731839 & 6725903 and a few others) So I added the Solaris patches with corrections for those bugs and Apache now works with mod_ssl!! RSA and AES are now offloaded to the card.. I still have some problems with mod_nss though and I imagine I may have to recompile nss again (mod_nss is derived from mod_ssl and hence I think it probably makes use of Openssl as well, right?). I shall try this and see if it works.. On Mon, Aug 24, 2009 at 8:51 PM, <Gary.Morton at sun.com> wrote: > On 08/23/09 22:31, Sandeep Cavale wrote: > >> >> Yes.. I did upgrade to firmware 1.1 update 2... And I also installed all >> the patches that came with that update. >> >> This is what I get with "scadiag" >> >> # scadiag -V mca0 >> scadiag (Sun Crypto Accelerator 6000) 1.1 >> Copyright 2006 Sun Microsystems, Inc. >> All rights reserved. >> Use is subject to license terms. >> >> The board status as shown in scamgr show status is: >> Board Status >> ---------------------------------------------------------------- >> Device Info: >> * Hardware Version: 1.4.50 >> * Bootrom Version : 1.0.4 >> * Firmware Version: 1.1.0 >> > > > You did not install the fw patch (the version would be 1.1.2). In the tar > there's a directory > > /Sun_Crypto_Acc_6000-1_1-u2-Solaris/Solaris/firmware/Patches > sr1-ubrm-31> ls > 128364-02 128371-02 > > You need to install 128371-02 via patchadd. After install you must install > the firmware on to the card - the patchadd just places the files on the > files system and not the card. > > you can use scamgr to do the upgrade. > > > load firmware /usr/lib/crypto/firmware/sca/sca6000fw > > you must then reset the card. > > -gary > > > > >> >> I have also attached the /var/adm/messages >> >> Again, we seem to have no problems running Tomcat web server (configured >> to use the card via JSSE). We can see that aesbytes, aesjobs, casubmit, >> cbsubmit, dhderive, dhkeygen, rsaprivate, sha1bytes, sha1hmacbytes, >> sha1hmacjobs, sha1jobs are the counters that increase in kstat indicating >> that all these operations are being done on the card... >> >> Only Apache(with mod_ssl or mod_nss) cannot access the hashing algorithms >> :( >> We would like the Apache web server to be able to make full use of the >> card just like Tomcat.. >> >> Kindly let us know if there is anything wrong with the configuration or if >> something is not properly initialised.. >> >> >> On Fri, Aug 21, 2009 at 9:03 PM, <Gary.Morton at sun.com <mailto: >> Gary.Morton at sun.com>> wrote: >> >> On 08/21/09 07:15, Sandeep Cavale wrote: >> >> Hi, >> >> I upgraded the firmware to 1.1.. >> >> >> You pulled down 1.1 update 2, correct? Did you install all of the >> patches included in that download as well? Can you send me the >> output from scadiag -v mca0 >> >> >> >> The cryptoadm lists the HMAC algs: >> mca/0: >> >> >> CKM_SHA_1,CKM_SHA512,CKM_DES_CBC,CKM_DES3_CBC,CKM_AES_CBC,CKM_AES_CTR,CKM_DES_CBC_PAD,CKM_DES3_CBC_PAD,CKM_AES_CBC_PAD,CKM_SHA_1_HMAC,CKM_SHA512_HMAC,CKM_SHA_1_HMAC_GENERAL,CKM_SHA512_HMAC_GENERAL,CKM_RSA_X_509,CKM_RSA_PKCS,CKM_DSA,CKM_DH_PKCS_KEY_PAIR_GEN,CKM_DH_PKCS_DERIVE,CKM_ECDSA_KEY_PAIR_GEN,CKM_ECDH1_DERIVE,CKM_ECDSA,CKM_RSA_PKCS_KEY_PAIR_GEN,CKM_DSA_KEY_PAIR_GEN,CKM_DES_KEY_GEN,CKM_DES2_KEY_GEN,CKM_DES3_KEY_GEN,CKM_AES_KEY_GEN,CKM_DES_CBC_PAD,CKM_DES3_CBC_PAD,CKM_AES_CBC_PAD,CKM_DES_CBC,CKM_DES3_CBC,CKM_AES_CBC,CKM_AES_CTR,CKM_RSA_X_509,CKM_RSA_PKCS,0x80004653 >> >> >> But now we seem to have stranger problems :( >> >> I tried 2 things with Apache >> >> i) When I used mod_nss, something funny seems to be happening >> with the card. Here's what the nss logs say: >> >> [Fri Aug 21 17:17:19 2009] [info] Configuring server for SSL >> protocol >> [Fri Aug 21 17:17:19 2009] [info] In FIPS mode, enabling TLSv1 >> [Fri Aug 21 17:17:19 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] >> [Fri Aug 21 17:17:19 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] >> [Fri Aug 21 17:17:19 2009] [info] Using nickname ksfips:certfips. >> [Fri Aug 21 17:17:19 2009] [error] Certificate not verified: >> 'ksfips:certfips' >> -------------------------------------------------------------------------> >> Note certificate is found but not verified >> [Fri Aug 21 17:17:19 2009] [error] SSL Library Error: -8156 >> Issuer certificate is invalid >> [Fri Aug 21 17:17:23 2009] [info] Configuring server for SSL >> protocol >> [Fri Aug 21 17:17:23 2009] [info] In FIPS mode, enabling TLSv1 >> [Fri Aug 21 17:17:23 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] >> [Fri Aug 21 17:17:23 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] >> [Fri Aug 21 17:17:23 2009] [info] Using nickname ksfips:certfips. >> [Fri Aug 21 17:17:23 2009] [error] Certificate not found: >> 'ksfips:certfips' >> -------------------------------------------------------------------------> >> Cannot find it anymore!! >> [Fri Aug 21 17:17:23 2009] [info] Configuring server for SSL >> protocol >> [Fri Aug 21 17:17:23 2009] [info] In FIPS mode, enabling TLSv1 >> [Fri Aug 21 17:17:23 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] >> [Fri Aug 21 17:17:23 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] >> [Fri Aug 21 17:17:23 2009] [info] Using nickname ksfips:certfips. >> [Fri Aug 21 17:17:23 2009] [error] Certificate not found: >> 'ksfips:certfips' >> [Fri Aug 21 17:17:23 2009] [info] Configuring server for SSL >> protocol >> >> >> If I try listing using "cryptoadm list -v", the hardware >> providers which earlier listed mca/0 is now empty!!! >> >> >> That would indicate the card has unregistered/crashed. Can you send >> o/p from /var/adm/messages. There are some important bug fixes in >> the patches in that update 2 download so lets make sure they are >> installed. >> >> -gary >> >> >> This seems to be similar to these bugs: >> https://bugzilla.redhat.com/show_bug.cgi?id=446851 and >> https://bugzilla.mozilla.org/show_bug.cgi?id=434043 though I use >> the latest NSS 3.12.3 >> >> >> ii) Secondly I replaced mod_nss with mod_ssl >> >> I still get the "same bad mac errror" but surprisingly if I >> disable the HMAC algs (which I really do not want to do) Apache >> starts working. This was pointed to me by this discussion: >> >> http://mail.opensolaris.org/pipermail/crypto-discuss/2007-December/000442.html >> < >> http://mail.opensolaris.org/pipermail/crypto-discuss/2007-December/000442.html >> > >> >> >> Only that with kstat I observe except rsaprivate, all other >> operations are not offloaded to the card at all (I'd like to >> have all operations especially RSA, AES offloaded to the card) >> >> I have also verified that the case is the same with firmware 1.0 >> for mod_ssl >> >> The above problem seems to be a bug >> (http://bugs.opensolaris.org/view_bug.do?bug_id=6606361) and my >> Solaris machine has the patch 127128-11 which is having this >> correction. I am not sure why I still have to use the workaround >> mentioned inspite of having the fix >> >> I know my posts are really getting lengthy , but any guidance >> will be truly appreciated :) >> >> >> >> >> On Fri, Aug 21, 2009 at 1:48 AM, <Gary.Morton at sun.com >> <mailto:Gary.Morton at sun.com> <mailto:Gary.Morton at sun.com >> <mailto:Gary.Morton at sun.com>>> wrote: >> >> >> You should download the 1.1 code - the 1.0 code does not >> support this. >> >> http://www.sun.com/products/networking/downloads.html >> >> >> -gary >> >> >> On 08/20/09 11:22, Sandeep Cavale wrote: >> >> Thanks Gary.. >> The guide seems to be 1.1 but the firmware we have is 1.0.. >> Anyway I shall give it a try, not sure if it would work >> with 1.0 >> Is there any other way to get the HMAC algorithms >> accessible >> from NSS/mod_nss/cryptoadm without firmware upgrade to 1.1 ? >> Because JSSE/JCE can access them with existing firmware.. >> >> >> On Thu, Aug 20, 2009 at 8:29 PM, <Gary.Morton at sun.com >> <mailto:Gary.Morton at sun.com> >> <mailto:Gary.Morton at sun.com <mailto:Gary.Morton at sun.com>> >> <mailto:Gary.Morton at sun.com <mailto:Gary.Morton at sun.com> >> >> <mailto:Gary.Morton at sun.com >> <mailto:Gary.Morton at sun.com>>>> wrote: >> >> If you are going to use the sca 6000 for hmac you will >> need to >> enable some options in the mca.conf driver config file: >> >> take a look at the user's guide for details - you will >> need >> to add >> entries for >> >> enable-hmac=1; >> >> and then assuming you are running the card in FIPS >> mode (only >> sha1 >> is available in FIPS mode) >> >> enable-multipart-sha1=1; >> >> You need to reboot for the config changes to take effect. >> >> -gary >> >> >> On 08/20/09 07:38, Sandeep Cavale wrote: >> >> Hi, >> >> We have a problem with running Apache mod_nss with >> SCA6000 in >> FIPS mode.. >> When we disable the "Sun Metaslot", so that nss >> can use >> only the >> Hardware token completely, we get the following >> error when we >> try to connect to our server from openssl: >> >> # openssl s_client -connect localhost:443 -tls1 >> -state >> CONNECTED(00000005) >> SSL_connect:before/connect initialization >> SSL_connect:SSLv3 write client hello A >> SSL_connect:SSLv3 read server hello A >> depth=0 /C=US/ST=California/L=Santa >> Clara/O=Sun/OU=Org/CN=nobody >> verify error:num=18:self signed certificate >> verify return:1 >> depth=0 /C=US/ST=California/L=Santa >> Clara/O=Sun/OU=Org/CN=nobody >> verify return:1 >> SSL_connect:SSLv3 read server certificate A >> SSL_connect:SSLv3 read server done A >> SSL_connect:SSLv3 write client key exchange A >> SSL_connect:SSLv3 write change cipher spec A >> SSL_connect:SSLv3 write finished A >> SSL_connect:SSLv3 flush data >> *SSL3 alert read:fatal:bad record mac >> >> ---------------------------------------------------------------*> >> The fatal error!! >> SSL_connect:failed in SSLv3 read finished A >> 1723:error:140943FC:SSL >> routines:SSL3_READ_BYTES:sslv3 >> alert bad >> record >> mac:../../../../common/openssl/ssl/s3_pkt.c:1052:SSL >> alert number 20 >> 1723:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl >> handshake >> failure:../../../../common/openssl/ssl/s3_pkt.c:529: >> >> >> According to a thread on Opensolaris forum >> ( >> http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120 >> < >> http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120> >> < >> http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120 >> < >> http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120>> >> < >> http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120 >> < >> http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120> >> < >> http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120 >> < >> http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120>>> >> < >> http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120 >> < >> http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120> >> < >> http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120 >> < >> http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120>> >> < >> http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120 >> < >> http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120> >> < >> http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120 >> < >> http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120>>>>) >> >> >> "By default, the SCA 6000 does not export any hash >> algorithm to >> user space apps because the hw can not support >> multi-part >> operations" >> >> Output of cryptoadm confirms this: >> bash-3.00# cryptoadm list -m provider=mca/0 >> *mca/0*: >> *---------------------------------------------------------------*> >> our Sun Crypto Accelerator >> >> >> CKM_SHA_1,CKM_DES_CBC,CKM_DES3_CBC,CKM_AES_CBC,CKM_AES_CTR,CKM_DES_CBC_PAD,CKM_DES3_CBC_PAD,CKM_AES_CBC_PAD,CKM_RSA_X_509,CKM_RSA_PKCS,CKM_DSA,CKM_DH_PKCS_KEY_PAIR_GEN,CKM_DH_PKCS_DERIVE,CKM_RSA_PKCS_KEY_PAIR_GEN,CKM_DSA_KEY_PAIR_GEN,CKM_DES_KEY_GEN,CKM_DES2_KEY_GEN,CKM_DES3_KEY_GEN,CKM_AES_KEY_GEN,CKM_DES_CBC_PAD,CKM_DES3_CBC_PAD,CKM_AES_CBC_PAD,CKM_DES_CBC,CKM_DES3_CBC,CKM_AES_CBC,CKM_AES_CTR,CKM_RSA_X_509,CKM_RSA_PKCS,0x80004653 >> >> (CKM_SHA_1 is the only hashing algorithm we see) >> This probably means that since I am forcing the NSS >> to >> use only >> hardware token (by disabling Sun Metaslot), even >> the HMAC >> hashing algorithm is being looked for in the SCA6000 >> card. But >> since it does not expose any hashing algorithm it >> fails to >> decode the hash client sends after change cipher spec >> msg, right? >> >> However if using JCE I list out all the supported >> algorithms of >> SCA6000, I see even these hashing algs amongst >> them: Mac.HmacSHA384 >> Mac.HmacSHA512 >> Mac.HmacMD5 >> Mac.SslMacMD5 >> Mac.HmacSHA1 >> Mac.SslMacSHA1 >> Mac.HmacSHA256 >> >> So, I tried configuring Tomcat to use the SCA6000 >> as its JSSE >> provider, and as I had guessed this worked without a >> glitch (by >> this I mean connecting with openssl) !!! I believe >> that's >> because for JSSE the above hashing algs are >> visible. To >> confirm >> this, I disabled these hashing algorithms in the >> sca6000.cfg >> file used by the JSSE provider and trying with >> openssl I >> get an >> error similar to Apache web server: >> >> # openssl s_client -connect localhost:443 -tls1 >> -state >> CONNECTED(00000005) >> SSL_connect:before/connect initialization >> SSL_connect:SSLv3 write client hello A >> SSL_connect:SSLv3 read server hello A >> depth=0 /C=US/ST=California/L=Santa >> Clara/O=Sun/OU=Org/CN=nobody >> verify error:num=18:self signed certificate >> verify return:1 >> depth=0 /C=US/ST=California/L=Santa >> Clara/O=Sun/OU=Org/CN=nobody >> verify return:1 >> SSL_connect:SSLv3 read server certificate A >> SSL_connect:SSLv3 read server key exchange A >> SSL_connect:SSLv3 read server done A >> SSL_connect:SSLv3 write client key exchange A >> SSL_connect:SSLv3 write change cipher spec A >> SSL_connect:SSLv3 write finished A >> SSL_connect:SSLv3 flush data >> *SSL3 alert read:fatal:unexpected_message* >> >> ----------------------------------------------------------------------------------------> >> Again after client's change cipher spec >> SSL_connect:failed in SSLv3 read finished A >> 2089:error:140943F2:SSL >> routines:SSL3_READ_BYTES:sslv3 alert >> unexpected >> >> message:../../../../common/openssl/ssl/s3_pkt.c:1052:SSL >> alert >> number 10 >> 2089:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl >> handshake >> failure:../../../../common/openssl/ssl/s3_pkt.c:529: >> >> >> So the question is, how is JSSE able to access the >> hashing >> algorithms while NSS cannot?? Our SCA card and web >> servers have >> to be running in FIPS mode too... >> Any help is greatly appreciated.. >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> crypto-discuss mailing list >> crypto-discuss at opensolaris.org >> <mailto:crypto-discuss at opensolaris.org> >> <mailto:crypto-discuss at opensolaris.org >> <mailto:crypto-discuss at opensolaris.org>> >> <mailto:crypto-discuss at opensolaris.org >> <mailto:crypto-discuss at opensolaris.org> >> <mailto:crypto-discuss at opensolaris.org >> <mailto:crypto-discuss at opensolaris.org>>> >> >> >> http://mail.opensolaris.org/mailman/listinfo/crypto-discuss >> >> >> >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/crypto-discuss/attachments/20090825/f5a95f9e/attachment.html>
