Monday Jul 02, 2012

How to export ECC key and Cert from NSS DB and import into JKS keystore and Oracle Wallet

How to export ECC key and Cert from NSS DB and import into JKS keystore and Oracle Wallet

In this blog I will write about how to extract a cert and key from NSS Db and import it to a JKS Keystore and then import that JKS Keystore into Oracle Wallet.

1. Set Java Home

I pointed it to JRE 1.6.0_22

$ export JAVA_HOME=/usr/java/jre1.6.0_22/

2. Create a self signed ECC cert in NSS DB

I created NSS DB with self signed ECC certificate. If you already have NSS Db with ECC cert (and key) skip this step.

$export NSS_DIR=/export/home/nss/

$$NSS_DIR/certutil -N -d .

$$NSS_DIR/certutil -S -x -s "CN=test,C=US" -t "C,C,C" -n ecc-cert -k ec -q nistp192 -d .

3. Export ECC cert and key using pk12util

Use NSS tool pk12util to export this cert and key into a p12 file 

    $$NSS_DIR/pk12util -o ecc-cert.p12 -n ecc-cert -d . -W password

4. Use keytool to create JKS keystore and import this p12 file

4.1 Import p12 file created above into a JKS keystore


$JAVA_HOME/bin/keytool -importkeystore -srckeystore ecc-cert.p12 -srcstoretype PKCS12 -deststoretype JKS -destkeystore ecc.jks -srcstorepass password -deststorepass password -srcalias ecc-cert -destalias ecc-cert -srckeypass password -destkeypass password -v

But if an error as shown is encountered,


keytool error: java.security.UnrecoverableKeyException: Get Key failed: EC KeyFactory not available
java.security.UnrecoverableKeyException: Get Key failed: EC KeyFactory not available
       at com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore.engineGetKey(Unknown Source)
        at java.security.KeyStoreSpi.engineGetEntry(Unknown Source)
        at java.security.KeyStore.getEntry(Unknown Source)
        at sun.security.tools.KeyTool.recoverEntry(Unknown Source)
        at sun.security.tools.KeyTool.doImportKeyStoreSingle(Unknown Source)
        at sun.security.tools.KeyTool.doImportKeyStore(Unknown Source)
        at sun.security.tools.KeyTool.doCommands(Unknown Source)
        at sun.security.tools.KeyTool.run(Unknown Source)
        at sun.security.tools.KeyTool.main(Unknown Source)
Caused by: java.security.NoSuchAlgorithmException: EC KeyFactory not available
        at java.security.KeyFactory.<init>(Unknown Source)
        at java.security.KeyFactory.getInstance(Unknown Source)
        ... 9 more

4.2 Create a new PKCS11 provider

If you didn't get an error as shown above skip this step.

Since we already have NSS libraries built with ECC, we can create a new PKCS11 provider

Create ${java.home}/jre/lib/security/nss.cfg as follows:

name = NSS
    nssLibraryDirectory = ${nsslibdir}
    nssDbMode = noDb
    attributes = compatibility

where nsslibdir should contain NSS libs with ECC support.

Add the following line to ${java.home}/jre/lib/security/java.security :

     security.provider.9=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg

Note that those who are using Oracle iPlanet Web Server or Oracle Traffic Director, NSS libs built with ECC are in <ws_install_dir>/lib or <otd_install_dir>/lib.

4.3. Now keytool should work

Now you can try the same keytool command and see that it succeeds :

$JAVA_HOME/bin/keytool -importkeystore -srckeystore ecc-cert.p12 -srcstoretype PKCS12 -deststoretype JKS -destkeystore ecc.jks -srcstorepass password -deststorepass password -srcalias ecc-cert -destalias ecc-cert -srckeypass password -destkeypass password -v

[Storing ecc.jks]

5. Convert JKS keystore into an Oracle Wallet

You can export this cert and key from JKS keystore and import it into an Oracle Wallet if you need using orapki tool as shown below.

Make sure that orapki you use supports ECC.

Also for ECC you MUST use "-jsafe" option.

$ orapki wallet create -pwd password  -wallet .  -jsafe

$ orapki wallet jks_to_pkcs12 -wallet . -pwd password -keystore ecc.jks -jkspwd password -jsafe

AS

$orapki wallet display -wallet . -pwd welcome1  -jsafe
Oracle PKI Tool : Version 11.1.2.0.0
Copyright (c) 2004, 2012, Oracle and/or its affiliates. All rights reserved.

Requested Certificates:
User Certificates:
Subject:        CN=test,C=US
Trusted Certificates:
Subject:        OU=Class 3 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
Subject:        CN=GTE CyberTrust Global Root,OU=GTE CyberTrust Solutions\, Inc.,O=GTE Corporation,C=US
Subject:        OU=Class 2 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
Subject:        OU=Class 1 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
Subject:        CN=test,C=US

As you can see our ECC cert in the wallet.


You can follow the same steps for RSA certs as well.

6. References

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=356

http://old.nabble.com/-PATCH-FOR-REVIEW-%3A-Support-PKCS11-cryptography-via-NSS-p25282932.html

http://www.mozilla.org/projects/security/pki/nss/tools/pk12util.html


Thursday May 26, 2011

What's new in NSS 3.12.* : Chrome's and SSL False Start

What's new in NSS 3.12.* - Chrome and SSL False Start

As you are aware that Chrome uses NSS for SSL/TLS. A friend of mine forwarded this blog link to me which was quite interesting to read.

"SSL False Start is a client-side only change to reduce one round-trip from the SSL handshake. ...

  We implemented SSL False Start in Chrome 9, and the results are stunning, yielding a significant decrease in overall SSL connection setup times. SSL False Start reduces the latency of a SSL handshake by 30% ..."

Recent related news on this  http://www.engadget.com/2012/04/12/google-puts-false-start-ssl-experiment-down-nobody-notices/

References :

Monday Feb 28, 2011

What's New in NSS 3.12.6 - SSL3 & TLS Renegotiation Indication Extension - NSS flags NSS_REQUIRE_SAFE_RENEGOTIATION and NSS_SSL_ENABLE_RENEGOTIATION

What's New in NSS 3.12.6 - SSL3 & TLS Renegotiation Indication Extension - NSS flags NSS_REQUIRE_SAFE_RENEGOTIATION and NSS_SSL_ENABLE_RENEGOTIATION

I tried my hands on various TLS renegotiation scenarios by setting these two flags NSS_REQUIRE_SAFE_RENEGOTIATION and NSS_SSL_ENABLE_RENEGOTIATION using sample SSL Server built with NSS 3.12.6 (and test case requires renegotiation).

As per NSS 3.12.6 release notes for NSS 3.12.6 (or above) the default values are

  • NSS_SSL_ENABLE_RENEGOTIATION = SSL_RENEGOTIATE_REQUIRES_XTN and
  • NSS_SSL_REQUIRE_SAFE_NEGOTIATION = PR_FALSE.

Sent requests using test tool tstclnt of NSS 3.12.6, NSS 3.12.4 and 3.12.5 with these flags set in server :

Note that in NSS 3.12.5 (in this renegotiation is disabled) so re-negotiations fail in all cases as expected.


Server has flag
NSS_SSL_ENABLE_RENEGOTIATION =

Server has flag NSS_REQUIRE_SAFE_RENEGOTIATION
=

Controls whether safe renegotiation indication is required for initial handshake. If TRUE, a connection will be dropped at initial handshake if the peer server or client does not support safe renegotiation.

Client version NSS 3.12.6 or above - client supports safe renegotiation
client version NSS 3.12.4 - older clients - client doesn't support safe renegotiation
client version NSS 3.12.5 - renegotiation disabled - client doesn't support safe renegotiation

SSL_RENEGOTIATE_NEVER (0)
Never allow renegotiation
TRUE
FAILURE - SSL_ERROR_RENEGOTIATION_NOT_ALLOWED FAILURE - SSL_ERROR_HANDSHAKE_NOT_COMPLETED FAILURE - SSL_ERROR_HANDSHAKE_NOT_COMPLETED
FALSE
FAILURE - SSL_ERROR_RENEGOTIATION_NOT_ALLOWED  FAILURE - SSL_ERROR_RENEGOTIATION_NOT_ALLOWED FAILURE - SSL_ERROR_RENEGOTIATION_NOT_ALLOWED
SSL_RENEGOTIATE_UNRESTRICTED (1)

Server and client are allowed to renegotiate without any restrictions.
TRUE
SUCCESS FAILURE - SSL_ERROR_HANDSHAKE_NOT_COMPLETED FAILURE - SSL_ERROR_HANDSHAKE_NOT_COMPLETED
FALSE
SUCCESS SUCCESS FAILURE -
PR_END_OF_FILE
SSL_RENEGOTIATE_REQUIRES_XTN (2)
(Default in NSS 3.12.6 or above)
Only allows renegotiation if the peer's hello bears the TLS renegotiation_info extension. This is the safe renegotiation.
TRUE
SUCCESS FAILURE -
SSL_ERROR_HANDSHAKE_NOT_COMPLETED
FAILURE - SSL_ERROR_HANDSHAKE_NOT_COMPLETED
FALSE
(Default in NSS 3.12.6 or above)
SUCCESS FAILURE - SSL_ERROR_RENEGOTIATION_NOT_ALLOWED FAILURE -
PR_END_OF_FILE

SSL_RENEGOTIATE_TRANSITIONAL (3)

Disallows unsafe renegotiation in server sockets only, but allows clients to continue to renegotiate with vulnerable servers.

TRUE
SUCCESS FAILURE - SSL_ERROR_HANDSHAKE_NOT_COMPLETED FAILURE - SSL_ERROR_HANDSHAKE_NOT_COMPLETED
FALSE
SUCCESS FAILURE - SSL_ERROR_RENEGOTIATION_NOT_ALLOWED FAILURE -
PR_END_OF_FILE



What these error codes mean

Error Error Number Error Text
SSL_ERROR_RENEGOTIATION_NOT_ALLOWED -12176 "Renegotiation is not allowed on this SSL socket."
SSL_ERROR_HANDSHAKE_NOT_COMPLETED -12202 "Cannot initiate another SSL handshake until current handshake is complete."
PR_END_OF_FILE_ERROR -5938 "Encountered end of file"

Here is my Server program

Here is my Makefile :

all:
 rm -rf server server.o
 CC -o server -I/export1/NSS_3.12.6/SunOS5.10_OPT.OBJ/include -L/export1/NSS_3.12.6/SunOS5.10_OPT.OBJ/lib -lnspr4 -lplc4 -lplds4 -lnss3 -lssl3 server.cpp

Created Server certificate using certutil as shown below:

$certutil -N -d . 
$certutil -S -n Server-Cert -s "CN=test.com" -x -t "CT,CT,CT" -d .

I sent request using sslreq.txt

GET /test.html HTTP/1.0
end

Here are the sample client and server Error logs , ssltap output in these 4 distinctive results


References

Monday Jan 17, 2011

What's new in NSS 3.12.\* - Server Name Indication (SNI) callback

What's new in NSS 3.12.\* - Server Name Indication (SNI) callback

When a request comes in to a web server, it sends the domain name in the Host header.

"GET /test.html HTTP/1.0

Host: abc.com"

by the time any web server parses it, its too late to send the appropriate certificate as it was already sent in the SSL Handshake. As per RFC4366, we now have a new extension in Handshake with which client can tell server the required domain. So the server can send appropriate certificate in the handshake.

In a Web Server, we can configure only one certificate of a type (ECC/RSA etc.) per HTTP listener using SSL_ConfigureSecureServer(fd...) call. If the server has to be used for one more domain, we need to regenerate the certificate with that domain in Subject Alternate Names. But with Server Name Indication (SNI) extension, we can register, more than one certificates (of a particular type) per HTTP listener.

In NSS 3.12.6 a new SNI callback was added as a part of bug 360421. Any Server which uses NSS can set this callback function (similar to what is shown in selfserv.c#1709) and write its implementation to send appropriate SNI certificate at runtime.

I used two binaries bundled with NSS selfserv and tstclnt to see what is happening. (I have used NSS 3.12.8)

Create two server certificates "www.foo.com" and "www.bar.com"

$certutil -N -d .
$certutil -S -x -n www.foo.com -s "CN=www.foo.com" -t CTu,u,u -d .
$certutil -S -x -n www.bar.com -s "CN=www.bar.com" -t CTu,u,u -d .

start the server

$selfserv -D -B -s -p 4443  -n www.foo.com  -r -a www.bar.com -d .

Where
-D => disable Nagle delays in TCP
-B => bypasses the PKCS11 layer
-s => disable SSL socket locking
-n  rsa_cert_nickname
-a is used to configure server for SNI. [-a sni_cert_nickname]
-r => request, not require, cert on initial handshake.

create sslreq.cat

$cat > req.dat  
GET /test.html HTTP/1.0

 


Now send a request asking for domain "www.bar.com"

$tstclnt -p 4443 -h www.foo.com -f -d  . -n www.foo.com  -2 -a www.bar.com  < sslreq.dat

where
-n => Nickname of key & cert for client auth (use www.foo.com  for now)
-a => Send different SNI name. [-a 1st_handshake_sni_cert_name]

We get : 

subject DN: CN=www.bar.com
issuer  DN: CN=www.bar.com
0 cache hits; 1 cache misses, 0 cache not reusable
0 stateless resumes
HTTP/1.0 200 OK
Server: Generic Web Server
Date: Tue, 26 Aug 1997 22:10:05 GMT
Content-type: text/plain
GET /test.html HTTP/1.0
EOF

As you can see, the server returned the certificate for "www.bar.com"

To know what's happening look at the ssltap output (use -c z in selfserv and tstclnt both):

$ssltap -l -s -p 1925 foo:4443
Connection #1 [Mon Jan 17 14:51:12 2011]
Connected to foo:4443
--> [
(74 bytes of 69)
SSLRecord { [Mon Jan 17 14:51:12 2011]
   type    = 22 (handshake)
   version = { 3,1 }
   length  = 69 (0x45)
   handshake {
      type = 1 (client_hello)
      length = 65 (0x000041)
         ClientHelloV3 {
            client_version = {3, 1}
            random = {...}
            session ID = {
                length = 0
                contents = {...}
            }
            cipher_suites[2] = {
                (0x00ff) ????/????????/?????????/???
                (0x0002) SSL3/RSA/NULL/SHA
            }
            compression[1] = {
                (00) NULL
            }
  extensions[20] = {
  extension type server_name, length [16] = {
   0: 00 0e 00 00  0b 77 77 77  2e 62 61 72  2e 63 6f 6d  | .....www.bar.com
              }
            }
         }
   }
}
]
<-- [
(590 bytes of 585)
SSLRecord { [Mon Jan 17 14:51:12 2011]
   type    = 22 (handshake)
   version = { 3,1 }
   length  = 585 (0x249)
   handshake {
      type = 2 (server_hello)
      length = 81 (0x000051)
         ServerHello {
            server_version = {3, 1}
            random = {...}
            session ID = {
                length = 32
                contents = {...}
            }
            cipher_suite = (0x0002) SSL3/RSA/NULL/SHA
            compression method = (00) NULL
            extensions[9] = {
              extension type 65281, length [1] = {
   0: 00                    | .
              }
              extension type server_name, length [0]
            }
         }
      type = 11 (certificate)
      length = 430 (0x0001ae)
         CertificateChain {
            chainlength = 427 (0x01ab)
            Certificate {
               size = 424 (0x01a8)
               data = { saved in file 'cert.001' }
            }
         }
      type = 13 (certificate_request)
      length = 58 (0x00003a)
         CertificateRequest {
            certificate types[3] = { 01 02 40 }
            certificate_authorities[52] = {
CN=www.bar.com
   CN=www.foo.com
            }
         }
      type = 14 (server_hello_done)
      length = 0 (0x000000)
   }
}
]
--> [
(754 bytes of 702, with 47 left over)
SSLRecord { [Mon Jan 17 14:51:12 2011]
   type    = 22 (handshake)
   version = { 3,1 }
   length  = 702 (0x2be)
   handshake {
      type = 11 (certificate)
      length = 430 (0x0001ae)
         CertificateChain {
            chainlength = 427 (0x01ab)
            Certificate {
               size = 424 (0x01a8)
               data = { saved in file 'cert.002' }
            }
         }
      type = 16 (client_key_exchange)
      length = 130 (0x000082)
         ClientKeyExchange {
            message = {...}
         }
      type = 15 (certificate_verify)
      length = 130 (0x000082)
   }
}
(754 bytes of 1, with 41 left over)
SSLRecord { [Mon Jan 17 14:51:12 2011]
   type    = 20 (change_cipher_spec)
   version = { 3,1 }
   length  = 1 (0x1)
}
(754 bytes of 36)
SSLRecord { [Mon Jan 17 14:51:12 2011]
   type    = 22 (handshake)
   version = { 3,1 }
   length  = 36 (0x24)
   handshake {
      type = 20 (finished)
      length = 12 (0x00000c)
         Finished {
            verify_data = {...}
         }
   }
      MAC = {...}
}
]
<-- [
(47 bytes of 1, with 41 left over)
SSLRecord { [Mon Jan 17 14:51:12 2011]
   type    = 20 (change_cipher_spec)
   version = { 3,1 }
   length  = 1 (0x1)
}
(47 bytes of 36)
SSLRecord { [Mon Jan 17 14:51:12 2011]
   type    = 22 (handshake)
   version = { 3,1 }
   length  = 36 (0x24)
   handshake {
      type = 20 (finished)
      length = 12 (0x00000c)
         Finished {
            verify_data = {...}
         }
   }
      MAC = {...}
}
]
--> [
(50 bytes of 45)
SSLRecord { [Mon Jan 17 14:51:12 2011]
   type    = 23 (application_data)
   version = { 3,1 }
   length  = 45 (0x2d)
   0: 47 45 54 20  2f 74 65 73  74 2e 68 74  6d 6c 20 48  | GET /test.html H
  10: 54 54 50 2f  31 2e 30 0a  0a                        | TTP/1.0..
      MAC = {...}
}
]
<-- [
(196 bytes of 164, with 27 left over)
SSLRecord { [Mon Jan 17 14:51:12 2011]
   type    = 23 (application_data)
   version = { 3,1 }
   length  = 164 (0xa4)
   0: 48 54 54 50  2f 31 2e 30  20 32 30 30  20 4f 4b 0d  | HTTP/1.0 200 OK.
  10: 0a 53 65 72  76 65 72 3a  20 47 65 6e  65 72 69 63  | .Server: Generic
  20: 20 57 65 62  20 53 65 72  76 65 72 0d  0a 44 61 74  |  Web Server..Dat
  30: 65 3a 20 54  75 65 2c 20  32 36 20 41  75 67 20 31  | e: Tue, 26 Aug 1
  40: 39 39 37 20  32 32 3a 31  30 3a 30 35  20 47 4d 54  | 997 22:10:05 GMT
  50: 0d 0a 43 6f  6e 74 65 6e  74 2d 74 79  70 65 3a 20  | ..Content-type:
  60: 74 65 78 74  2f 70 6c 61  69 6e 0d 0a  0d 0a 47 45  | text/plain....GE
  70: 54 20 2f 74  65 73 74 2e  68 74 6d 6c  20 48 54 54  | T /test.html HTT
  80: 50 2f 31 2e  30 0a 0a 45  4f 46 0d 0a  0d 0a 0d 0a  | P/1.0..EOF......
      MAC = {...}
}
(196 bytes of 22)
SSLRecord { [Mon Jan 17 14:51:12 2011]
   type    = 21 (alert)
   version = { 3,1 }
   length  = 22 (0x16)
   warning: close_notify
      MAC = {...}
}
]

 Note that the client sent "www.bar.com" to the server in the extension.

Also that server sends the certificate (cert.001) i.e. "www.bar.com"  to the client.  

$openssl x509  -in cert.001 -text -inform DER

Certificate:

    Data:

        Version: 3 (0x2)

        Issuer: CN=www.bar.com

        Subject: CN=www.bar.com

And the client sends the certificate (cert.002) i.e. "www.foo.com"  to the server.

$openssl x509  -in cert.002 -text -inform DER

Certificate:

    Data:

        Version: 3 (0x2)

        Issuer: CN=www.foo.com

        Subject: CN=www.foo.com

Now send a request asking for domain "www.domain-not-found.com", the server is unable to find a certificate registered for such a domain and hence returns error. This behavior will vary from server to server depending on the implementation. 

$tstclnt -p 4443 -h www.foo.com -f -d  . -n www.foo.com  -2 -a "www.domain-not-found.com"  < sslreq.dat

 We get the error :

 tstclnt: write to SSL socket failed: SSL peer has no certificate for the requested DNS name

For this case, ssltap output shows an "unrecognize_name" alert (use -c z in selfserv and tstclnt):

$ssltap -l -s -p 1925 foo:4443
Connection #1 [Mon Jan 17 14:49:28 2011]
Connected to foo:4443
--> [
(87 bytes of 82)
SSLRecord { [Mon Jan 17 14:49:28 2011]
   type    = 22 (handshake)
   version = { 3,1 }
   length  = 82 (0x52)
   handshake {
      type = 1 (client_hello)
      length = 78 (0x00004e)
         ClientHelloV3 {
            client_version = {3, 1}
            random = {...}
            session ID = {
                length = 0
                contents = {...}
            }
            cipher_suites[2] = {
                (0x00ff) ????/????????/?????????/???
                (0x0002) SSL3/RSA/NULL/SHA
            }
            compression[1] = {
                (00) NULL
            }
            extensions[33] = {
              extension type server_name, length [29] = {
  0: 00 1b 00 00  18 77 77 77  2e 64 6f 6d  61 69 6e 2d| .....www.domain-
 10: 6e 6f 74 2d  66 6f 75 6e  64 2e 63 6f  6d  | not-found.com
              }
            }
         }
   }
}
]
<-- [
(7 bytes of 2)
SSLRecord { [Mon Jan 17 14:49:28 2011]
   type    = 21 (alert)
   version = { 3,1 }
   length  = 2 (0x2)
   fatal: unrecognized_name
}
]
 
  

Looks like j2SE SNI client side support was integrated in J2SE 7 b118 CR6985179 To support Server Name Indication extension for JSSE client.

 Browsers that support TLS SNI

Refer http://en.wikipedia.org/wiki/Server_Name_Indication#Support for a full list. Some of these browsers are :

  • Internet Explorer 7 or later, on Windows Vista or higher. Does not work on Windows XP, even Internet Explorer 8.
  • Mozilla Firefox 2.0 or later
  • Google Chrome (Vista or higher. XP on Chrome 6 or newer. OS X 10.5.7 or higher on Chrome 5.0.342.1 or newer)
  • Safari 2.1 or later (Mac OS X 10.5.6 or higher and Windows Vista or higher)

References

Wednesday Jan 05, 2011

What's new in NSS 3.12.\*- New Shared DBs

NSS has introduced NEW Shared Databases based on SQLite in NSS 3.12.x. 
Motivation for introducing these new Shared Databases were :
  • ability to edit NSS databases without stopping server and
  • servers want to share DBs.

Advantages of these Shared DBs

Some experts from https://wiki.mozilla.org/NSS_Shared_DB

"NSS has been using an old version of the Berkeley Database as its database engine (commonly described in NSS documents as "DBM") has a number of limitations. One of the most severe limitations concerns the number of processes that may share a database file. While any process has a DBM file open for writing, NO other process may access it in any way. Multiple processes may share a DBM database ONLY if they ALL access it READ-ONLY. Processes cannot share a DBM database file if ANY of them wants to update it.

Applications that want to share databases have resorted to these strategies:
\* Synchronized updates, with application down time : The applications share the database read-only. If any update is desired, all the applications are shut down, and a database update program performs the update, then all the applications are restarted in read-only mode. This results in undesirable downtime and desired database changes are delayed until the next interval in which such downtime is acceptable."
...

"The new databases will be called 'shareable' databases. They may or may not be shared by multiple processes, but they are all capable of being shared. "
...

Shareable DB files : cert9.db, key4.db, pkcs11.txt

  • Are based on SQLite3
  • Allows read write by multiple simultaneous processes
  • Not enabled by default, must be enabled. To be enable it, use environment variable NSS_DEFAULT_DB_TYPE or add "sql:" prefix in configDir.
  • certutil utility program can do upgrade i.e. convert old DB (cert8.db) to new DB(cert9.db). For automatic upgrade, NSS must be told to use SQL AND the databases must be opened for reading AND writing. If NSS is not told to use SQL, or if the databases are opened READ-ONLY, then no automatic upgrade takes place.

Different types of NSS DBs

\* Directory name string prefix "sql:", "dbm:", "extern:", "multiaccess:" OR
\* Environment variable NSS_DEFAULT_DB_TYPE "sql", "dbm", "extern"

where "dbm" is the old default Berkeley DB (cert8). 
      "sql" is the new sqlite3 (cert9) DB. 
      "extern" and "multiaccess" are now obsolete.

How to upgrade from cert8.db to cert9.db

You can either use environment variables or use sql: prefix in database directory parameter of certutil:
$export NSS_DEFAULT_DB_TYPE=sql
$certutil -K -d /tmp/nss -X

OR

$certutil -K -d sql:/tmp/nss -X
When you upgrade these are the files you get :
key3.db -> key4.db
cert8.db -> cert9.db
secmod.db -> pkcs11.txt
The contents of the pkcs11.txt files are basically identical to the contents of the old secmod.db, just not in the old Berkeley DB format. If you run the command "$modutil -dbdir DBDIR -rawlist" on an older secmod.db file, you should get output similar to what you see in pkcs11.txt.
 
  
 
  

What needs to be done in programs / C code

Either add  environment variable NSS_DEFAULT_DB_TYPE "sql"

NSS_Initialize call in https://developer.mozilla.org/en/NSS_Initialize
takes this "configDir" parameter as shown below :

    NSS_Initialize(configDir, "", "", "secmod.db", NSS_INIT_READONLY);


For cert9.db, change this first parameter to "sql:" + configDir (like "sql:/tmp/nss/") i.e. prefix "sql:" in the directory name where these NSS Databases exist.

This code will work with cert8.db as well if cert9.db is not present.

References

  1. https://wiki.mozilla.org/NSS_Shared_DB_Samples
  2. https://wiki.mozilla.org/NSS_Shared_DB_Howto
  3. https://wiki.mozilla.org/NSS_Shared_DB
  4. http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg05282.html

        
    
About

Meena Vyas

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today