Starting with Red Hat Enterprise Linux version 5 (RHEL 5), Red Hat added native support for PKI with pam_pkcs11, NSS, ccid, coolkey, and pcsc-lite. RHEL 5 also added rudimentary support for PKINIT in their Kerberos client, mostly based upon the CITI and Heimdal implementation (in pkinit-nss). Coming in a future update to RHEL 5 (maybe 5.3 or 5.4) you can expect better PKINIT support, with more MIT based PKINIT support.

This series of articles will cover how to configure a RHEL 5 system to allow users to log in with a smartcard, while also getting a Kerberos ticket from an Active Directory domain.

Part 1 will cover configuring NSS and OpenSSL. Part 2 will cover configuring pam_pkcs11 and testing a smartcard using the centralized NSS database. Part 3 will cover configuring Kerberos, PKINIT, and pam_krb5.

For the sake of simplicity, we are using our own Certificate Authority (CA), and not a third party. We will have only one root CA, and two intermediate CAs. All of the CA certificates are assumed to be in /root/CAs. All certificates are assumed to be in ascii (pem) format.

So, on with part 1…

Configuring NSS and OpenSSL

Red Hat seems to be mostly moving away from using OpenSSL, and is now using NSS as their main crypto library; unfortunately, a lot of applications still use OpenSSL pretty heavily, so we’ll have to configure both NSS and OpenSSL. Thankfully, Red Hat centralized their PKI content into a centralized location: /etc/pki; this directory holds content for both OpenSSL and NSS.

Adding CA certs

Red Hat’s centralized NSS database holds no trusts by default. From a system security point of view, this is a good thing because PKI login will be limited only to the specific CAs that you trust. We’ll use certutil to add the CA certs to the central database in /etc/pki/nssdb:

certutil -A -n "Example Corp Root" -t "CT,C,C" -a -d /etc/pki/nssdb -i /root/CAs/examplecorprootclass2.crt

Let’s break down this command: “-A” tells certutil we want to add a certificate to the database. “-n” is used to give an alias to the certificate. “-t” tells certutil how to trust the certificate; this example may be overkill depending on how your CA is going to be used. You should normally only trust a certificate as much as actually needed. “-a” tells certutil the certificate we are adding is in ascii (pem) format. “-d” tells certutil what database we wish to add the certificate to. “-i” lists the certificate we wish to add.

You should repeat this command for every CA you have, changing the alias, trust level, and input file appropriately. To get an idea of the trust levels available, run the following:

certutil -H

To see a list of installed certificates run:

certutil -L -d /etc/pki/nssdb

Adding certificates to OpenSSL is easier. We’ll do three things:

1. Drop the certificates into the /etc/pki/tls/certs directory

   • cp /root/CAs/*.crt /etc/pki/tls/certs

2. Make hash links of the certificates

   • pushd /etc/pki/tls/certs; for i in `ls *.crt`; do [ ! -e $i.0 ] && ln -s $i $(openssl x509 -hash -noout -in $i).0; done; popd

3. Make a bundle of the certificates

   • cat /root/CAs/*.crt > /etc/pki/tls/examplecom-bundle.crt

Check to ensure your smartcard library is in the NSS secmod database

For your system to access your smartcard, it’ll need to use a library to access it. Your NSS database may already have the library loaded as a module, but it is important to check. To check the loaded modules in NSS, use the modutil command:

modutil -list -dbdir /etc/pki/nssdb
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. CoolKey PKCS #11 Module
 library name: libcoolkeypk11.so
 slots: 1 slot attached
 status: loaded

 slot: E-Gate 0 0
 token:
-----------------------------------------------------------

Notice above that the “NSS Internal PKCS#11 Module” and the “CoolKey PKCS #11 Module” modules are loaded. The NSS internal module is always loaded in NSS databases; the important module here is the CoolKey one. If a smartcard module isn’t loaded, you can load one with the modutil command:

modutil -add "CoolKey PKCS #11 Module" -libfile libcoolkeypk11.so -dbdir /etc/pki/nssdb

You can use the full path to the library if you wish, but it isn’t necessary; furthermore, if you are scripting this, it’ll cause issues between different platforms.

This covers configuring NSS and OpenSSL; the next part in this series of articles will focus on pam_pkcs11.

Update (07/09/2009): Added information about checking NSS for smartcard libraries

Share:

Related posts:

1. Seamless Smartcard login with pam_pkcs11, and pam_krb5 against an Active Directory Domain using Red Hat Enterprise Linux 5 (Part 2)
2. Seamless Smartcard login with pam_pkcs11, and pam_krb5 against an Active Directory Domain using Red Hat Enterprise Linux 5 (Part 3)
3. SSL replication and CA trusts in Sun Directory Server 6.x
4. Using NSS with OpenSSH for Smart Card Login