Creating a Certificate Authority(CA) using NSS

Solution Verified - Updated

Environment

  • PKI Environment
  • nss-3.12.6-1.el5_4
  • Self Signed Certificate Authority
  • nss-tools-3.12.6-1.el5_4
  • Red Hat Enterprise Linux 5.5

Issue

Creating a Certificate Authority(CA) using NSS

Resolution

According to Mozilla, Network Security Services(NSS) is a set of libraries desinged to support cross platform development of Security  Enabled client and server applications.

Example Products that use NSS libraries:

Firefox
Thunderbird
Netscape Browsers
Evolution
Gaim
OpenOffice
RHDS
Certificate System
mod_nss

NSS supports certificates of below standard:

sslv2
sslv3
PKCS #5
PKCS #7
PKCS #11 (Tokens)
PKCS #12 (Files)
S/MIME
x.509 v3

RHEL5 has 2 sets of security libraries, trational packages like openssl and Mozilla's NSS. x.509,pkcs are standards used in certificates that form the PKI.

nss default directory, i.e the directory to store certificates is /etc/pki/nssdb. Unlike openssl where certificates are created and stored in text files. the certificates created by nss-tools are stored in nss database.

All certificates and keys  are stored in berkelely database. There are 3 major files generally seen in a nss directory are: key3.db, cert8.db and secmod.db

  • key3.db file contains a key used to encrypt and decrypt saved passwords
  • cert8.db contains certificates
  • secmod.db contains pathnames of pkcs#11 modules

Instruction for CA operations

Creating Certificate and key databases. For better understanding we create the below structure of directories to store CA , server and user certificates

  • /etc/pki/nssdb/CA_db ( for storing root CA certificates)
  • /etc/pki/nssdb/server_db (for storing certificates of servers )
  • /etc/pki/nssdb/client_db ( for storing certificates of users)

Create a new certificate database CA_db

$ cd /etc/pki/nssdb
$ mkdir CA_db
$ certutil -N -d CA_db

Create a Self signed Root CA certificate, specify the subject name

$ certutil -S -d CA_db -n "gss pnq CA" -s "CN=GSS PNQ CA,O=GSS,L=Pune,ST=Maharashtra,C=IN" -t "CT,," -x -2

Explanation:

  • -S (caps) specifies create a individual certificate and add it to the database
  • -d specifies the directory of the nss database ( -d . specifies current directory)
  • -n "Name of the certificate"
  • -s "subject" of the certificate or Distinguished Name. (DN)
  • -t "CT,," specifies that this certificate is a Trusted CA which can issue server certficates, and client certificates , ",," specifies uu i.e "CT,u,u" , where u specifies certificate can be used for authentication and signing.
  • -x use the certutil tool to generate the signature for certificate being created or added to the database rather than obtaining from separate CA.
  • -2 specifies that add basic constraint extensions, like the certificate can be used to sign specific operations like SSL, object signing, SMIME etc.

Extract the CA certificate from CA's cert database to a file

$ certutil -L -d CA_db -n "gss pnq CA" -a -o CA_db/rootca.crt

Display the contents fot the CA's Certificate database.

$ certutil -L -d ./CA_db

Creating Certificates for Servers, For servers SSL servers or clients, Ex: OpenLDAP server using ssl (ldaps) , HTTP Server using SSL (HTTPS)

$ mkdir /etc/pki/nssdb/server_db
$ certutil -N -d server_db

Import the new CA certificate in the Server certificate's database and we mark it as trusted CA so that we can issue certificates for SSL Client and server authentication.

$ certutil  -A -d server_db -n "gss pnq CA" -t "TC,," -a -i CA_db/rootca.crt

Explanation:

  • -A Add an existing certificate to a certificate database.
  • -d server_db (directory of certificate database)
  • -t "TC", specifies that this certificate is a Trusted CA which can issue server certficates, and client certificates , ",," specifies uu i.e "CT,u,u" , where u specifies certificate can be used
  • -a is ascii format
  • -i input-file

Create the server certificate request, specifying the subject name for the server certificate. We make the common name (CN) be identical to the hostname of the server.

$ certutil -R -d server_db  -s "CN=dhcp208-219.gsslab.pnq.redhat.com,O=GSS,L=Pune,ST=Maharashtra,C=IN" -a -o server_db/dhcp208-219.req -v 12

Explanation:

  • The above generates certificate for host dhcp208-219.gsslab.pnq.redhat.com , For better identification and understanding we specify Organization, Location, State, and Country
  • -R Create a request file , that can be submitted to CA for signing the cert
  • -d directory where certificate database exists
  • -s subject of the certificate or DN
  • -a ascii
  • -o output file

Sign the Certificate from CA , and issues a new certificate in ascii format

$ certutil -C -d CA_db -c "gss pnq CA" -a -i server_db/dhcp208-219.req -o server_db/dhcp208-219.crt -2 -6

Import (Add) the new server certificate to the server's certificate database in the server_db directory with the appropriate nickname

$ certutil -A -d server_db -n dhcp208-219.gsslab.pnq.redhat.com -a -i server_db/dhcp208-219.crt -t ",,"

Verify the certificate

$ certutil -V -d server_db -u V -n dhcp208-219.gsslab.pnq.redhat.com

Creating certificates for Uses/Clients

$ mkdir /etc/pki/nssdb/client_db
$ cd /etc/pki/nsssdb

Import the new CA certificate in the Server certificate's database and we mark it as trusted CA so that we can issue certificates for SSL Client and server authentication.

$ certutil  -A -d server_db -n "gss pnq CA" -t "TC,," -a -i CA_db/rootca.crt

Create a client certificate request , Specifying the subject name of the certificate

$ certutil -R -d client_db -s "CN=Joe Client,O=GSS,L=Pune,ST=Maharashtra,C=US" -a -o client_db/client.req -v 12

Sign the certificate request by CA "gss pnq CA'

$ certutil -C -d CA_db -c "gss pnq CA" -a -i client_db/client.req -o client_db/client.crt

Add the certificate to the client nss database

 $ certutil -A -d client_db -n "Joe Client" -a -i client_db/client.crt -t ",,"

View the client certificate

$ certutil -L -d client_db -n "Joe Client"

Verifying the certificates

To verify the server certificates 

$ certutil -V -d server_db -u V  -n dhcp208-219.gsslab.pnq.redhat.com

To verify the client certificates

$ certutil -V -d client_db -u C -n "joe Client"

By default the certificates that have been created using the above procedure are in pkcs12 standard. To use the certificates on Applications,  You would require the following

  1. RooCA's Certificate (public key)
  2. Server Certificate (Certificate and key). The Server's participating in SSL communication should have the certificates and key file

nss-tools comes with pk12util command , pk12util is a pkcs#12 Tool allowing to share certificates. This tool supports importing certificates and keys from pkcs #12 files in to NSS or export them and also list certificates and keys in such files.

Exporting the Server certifcate dhcp208-219.gsslab.pnq.redhat.com in to a file dhcp208-219.pk12

$ pk12util -d . -o dhcp208-219.pk12 -n dhcp208-219.gsslab.pnq.redhat.com

The Above dhcp208-219.pk12 file has both the certificate and the key file encrypted .

For Applications which require certificate and key file to be in pem format we can use Openssl command to convert the file from .p12 to pem format.

$ openssl pkcs12 -clcerts -nokeys -in dhcp209-88.pk12 -out dhcp209-88.pem

The above says that the standard of the input certificate is pkcs12, and export only client certificates (not CA certficates), -nokeys (do not output any private keys) So dhcp209-88.pem will contain only the certficate in pem format.

PkCS12 certs have their private keys encrypted with pass phrase. When exporting the keys, You might want the key to be accessed without a passphrase.

$ openssl pkcs12 -nocerts -in dhcp209-88.pk12 -out dhcp209-88-key.pem -nodes

Root Cause

  • There are multiple ways with Red Hat Enterprise Linux to set up a Certificate Authority it can also be done with openssl
SBR
Product(s)
Components
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.