Thanks to Bob and Ian for following up my post.
> > certutil -K does not work. This is a bug fixed on the tip, but not it
> > any release up to NSS 3.3.
Any idea when this fix will be released?
> > You are creating a CA cert, and will need some extensions. In this
> > case, I believe you will want to add -1 -2 -5 to the end of your command
> > line. Those options will present you with menus of extensions, you
> > should choose "SSL CA", "Basic Constraints", etc.
Having read the cert extensions docs, I understand that I only
*require* the basicConstraint of cA, the others are optional (even
recommended, but not required). Is this correct?
> The easiest way to see how to generate certs is to run the NSS test
> cases in security/nss/tests all.sh runs all the tests cert/cert.sh runs
> the certificate tests (which uses certutil to create client and server
> certs. Here's an example out put of the run:
Unfortunately I am running with binary distribution, so thanks for the
output...
> NOTE: I wouldn't use the -z option for any real production certificates.
> It's a handy way to make test scripts run, but for production it really
> doesn't generate adequate entropy -- especially for CA certificates.
I generate the random data file afresh each time I generate a key,
using Unix log files as the source. I'd like the scripts to run
without intervention.
> > You can use pk12util to export the cert and key you created (you will
> > not need, nor want, to export the self-signed root). You can then use
> > pk12util again to import the cert and key into the Directory Server
> > database. I don't know where in the installation the cert and key
> > databases are, but once you find them you can use pk12util to do the
> > import.
OK.
> IPlanet servers use the same database format as NSS and PSM (different
> versions of the servers and clients have differing levels of
> commonality). The servers store their key and cert databases in
> $(SERVERROOT)/aliases (where SERVERROOT is the top level directory where
> you installed the server). The database names are typically
> {server-type}-{hostname}-cert7.db, though it can be pretty much anything
> -cert7.db. You manipulate these databases directly with certutil by
> specifying the '-P' option to specify the cert and key db prefix (alias
> name in the server UI). Also, the default nickname for the certificate
> on servers is 'Server-Cert'.
Yes, the name of the cert db is configured into the directory using
the dse.ldif file in the sldap/config directory. One question, do you
know if a secmod.db file required for the Directory Server? For
various reasons we are running the directory without the admin server,
I note that slapd picks up the secmod.db from the admin-serv/config
directory.
After posting (but before seeing the replies) I did manage to complete
the process using a combination of NSS and OpenSSL. I can create the
server request and server cert/key dbs using NSS and mint the root and
server certs using OpenSSL.
With this extra info above I may move over entirely to NSS.
There is just one issue. From the NSS docs:
WARNING: The CA certificate you produce with the NSS
tools is a self-signed certificate that works
correctly for testing purposes but should not be
used in a real-world deployment. Similarly, the
client SSL and server SSL certificates created
with the NSS tools are for testing purposes
only. To deploy certificates used in a real
public-key infrastructure (PKI), either use a
third-party CA or use a certificate server (such
as Netscape Certificate Management System) to set
up your own CA and issue certificates. The
Certificate Database Tool does not provide the
facilities for a full-blown PKI deployment, and
the certificates it creates should not be
considered trustworthy for that purpose.
What is the reason for this warning? I plan to use NSS for internal
production systems, only for a small number of LDAP servers, and then
only to use SSL to provide data encryption (i.e. not client
authentication). Do you see any issues with using NSS for this?
Many thanks,
Frank.
