David Sadler wrote: > We have made some progress but still having problems. > > This is what we have tried ... on SLES 10 SP1 , Suse Linux, IBM zSeries > hardware. > > on the NSS side we created a certificate DB with certutil > then added openCrypto to the DB with NSS modutil
> # modutil -dbdir /etc/apache2/SampleCertDBs/ -add opencryptoki > -libfile /usr/lib64/libopencryptoki.so > -mechanisms RSA:RC2:RC4:RC5:DES:SHA1:MD5:MD2:SSL:TLS > Using database directory /etc/apache2/SampleCertDBs... > RC=80400009 Status=0 errno=9 ThreadID=375c30 > ===> this gets an error that appears to be coming from z90crypt (the IBM > driver that i/f with the crypto hardware), we think that it is > caused by not having the openCryptoki CA in the NSS DB. > Module "opencryptoki" added to database. > however, it claims to have added the module to NSS module db. Yes, Whatever that message is complaining about, it's not fatal to the modutil -add operation, so maybe we can ignore it while we look at some other problems that are fatal. That error message is not from NSS, I would say, and I'd encourage you to ask the supplier of the z90crypt module or opencryptoki for an explanation. > # modutil -dbdir /etc/apache2/SampleCertDBs/ -list > Using database directory /etc/apache2/SampleCertDBs... > RC=80400009 Status=0 errno=9 ThreadID=375c30 I see you get that every time, but it's not fatal. weird. > 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. opencryptoki > library name: /usr/lib64/libopencryptoki.so > slots: 1 slot attached > status: loaded > > slot: Linux 2.6.16.46-0.12-default Linux (ICA) > token: openCryptoki > ----------------------------------------------------------- That all looks good. You now have two tokens that are capable of storing certs, a) NSS Certificate DB, and b) openCryptoki > webserver1:/etc/apache2 # > > when we try starting apache2 we get this in the log > [Mon Jul 28 16:13:49 2008] [info] Configuring server for SSL protocol > [Mon Jul 28 16:13:49 2008] [debug] nss_engine_init.c(556): Enabling SSL3 > [Mon Jul 28 16:13:49 2008] [debug] nss_engine_init.c(561): Enabling TLS > [Mon Jul 28 16:13:49 2008] [debug] nss_engine_init.c(732): Configuring > permitted SSL ciphers > [+rsa_rc4_128_md5,+rsa_rc4_128_sha,+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] > [Mon Jul 28 16:13:49 2008] [info] Using nickname openCryptoki:webserver1. > [Mon Jul 28 16:13:49 2008] [error] Certificate not verified: > 'openCryptoki:webserver1' > [Mon Jul 28 16:13:49 2008] [error] SSL Library Error: -8156 Issuer > certificate is invalid > [Mon Jul 28 16:13:49 2008] [error] Unable to verify certificate > 'openCryptoki:webserver1'. Add "NSSEnforceValidCerts off" to nss.conf so > the server can start until the problem can be resolved. That all makes sense to me. mod_nss is trying to verify that the server certificate has a valid cert chain, leading to a trusted issuer (trusted root) as part of startup, so that when it sends out the chain, the clients will be able to validate the server's cert chain. And it is reporting that it cannot validate the cert chain because the issuer cert that it has found is not a valid CA cert. There are many possible explanations for this, but chief among them are: - self-signed server cert - issuer cert that is not a CA cert, or is an X.509 v1 (not v3) cert. We need to know more about the certs in the server's cert chain in order to advise how to resolve that issue. > these are the certs in the db Not exactly. These are the certs in all the tokens (both of the two tokens that you have that can store certs). The certs in all tokens except the "NSS Certificate DB" token will have the token name prefixed to them, e.g. tokenname:certname whereas the certs in the NSS Certificate DB generally do NOT have the tokenname: prefix prepended to them. The results below show 3 certs in the NSS Certificate DB token, and one cert in the opencryptoki token. > webserver1:/etc/apache2 # certutil -L -h all -d /etc/apache2/SampleCertDBs > RC=80400009 Status=0 errno=9 ThreadID=375c00 > Enter Password or Pin for "openCryptoki": > SampleSSLServerCert u,u,u > SampleSSLClientCert u,u,u > SampleRootCA CTu,Cu,Cu > openCryptoki:webserver1 u,u,u > I do not know how the openCryptoki:webserver1 got in the DB It didn't. > we did not add it, Indeed not. That cert's not in the DB. > maybe modutil added it. No, it's in the opencryptoki token. > If we use "NSSEnforceValidCerts off" then Apache starts but we can not use > https. > > we see this in the log > [Mon Jul 28 16:17:48 2008] [info] Connection to child 0 established > (server webserver1.pdl.pok.ibm.com:443, client 10.10.80.147) > [Mon Jul 28 16:17:48 2008] [info] SSL input filter read failed. > [Mon Jul 28 16:17:48 2008] [error] SSL Library Error: -12215 MD5 digest > function failed So, the SSL library called the PKCS#11 module to do an MD5 digest computation, and the PKCS#11 module reported some kind of failure to do that simplest of crypto operations. :( This is a separate issue from the issue with the certificate not being verifiable. > Any suggestions on how to determine what is wrong? Well, ultimately, the PKCS#11 module refused to do an MD5 hash operation. Are you sure the device you have supports MD5? If so, then I think you need to ask the supplier for help with that. It is possible to use a debug build of NSS and use the PKCS#11 module interface tracing feature found in debug NSS libraries. That will give you a detailed history of exactly what all NSS asked the module to do, what what the module's responses were. Such a think would mostly be of value to the person(s) supporting the PKCS#11 module you're using. See http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn2.html for information about how to use the module tracing feature. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
