Another common usability failure is to allow users to present multiple client certificates when your site only trusts a certain type of certificate. The user has no idea which certificate they need to present, and they shouldn’t need to. The common solution to this problem is to provide documentation as to which certificate should be used. This is a poor solution.

In this article, I’ll describe how to configure Apache to require SSL client authentication in a polite, usable way.

Politely requiring SSL client authentication

I’m using “require” somewhat loosely here, as that’s the first thing we are going to change in our configuration. When you use the SSLVerifyClient directive with the require value, it really means require. So, how do we get around this?

We change the SSLVerifyClient directive to the optional value. The key is making optional still mean require. Our goal is to redirect users to help documentation when SSL client authentication fails. We can do this by using mod_rewrite and environment variables from mod_ssl. Here’s how to configure this in Apache:

SSLOptions +StdEnvVars
SSLVerifyClient optional
SSLVerifyDepth 3
RewriteEngine On
RewriteCond %{SSL:SSL_CLIENT_VERIFY} !^SUCCESS$
RewriteRule .* /help/ssl-client-auth-required.html [L]

In this configuration, any request that doesn’t have a valid client certificate will be redirected to a help file. Optional, yet required politely. Don’t forget to be polite internationally, if that is a requirement! You should configure Apache to serve the help document based on the user’s language. I’m going to avoid this portion of the topic for now. I’ll go into this in a future article.

Selectively accepting client certificates

If your users have multiple types of client certificates; for email, client authentication, and encryption from different intermediate CAs; for instance; and your application needs a specific type of certificate; then you shouldn’t force your users to guess which certificate is required. There are a few options here:

1. Provide documentation to educate users on which certificate to choose prior to them accessing the site
2. Use the above method to educate users when they fail to choose the correct certificate
3. Use both options 1 and 2
4. Only allow users to choose the correct certificate by limiting which certificates your site will accept

The obvious choice from a usability perspective is option 4. It is less confusing, requires less documentation to be written and read, and is fairly easy to configure.

The first step is to identify which certificate authorities (CA)s you wish to trust. The next step is to append all of the public CA certificates into a single file. The final step is to configure Apache to use this file to restrict certificates. To configure this in Apache, use the following directive:

SSLCADNRequestFile /etc/pki/tls/certs/client-trust-bundle.cer

Unfortunately, option 4 will only be a viable option if the different certificate types were created by different CAs (which, hopefully, you are doing for security reasons). If you are unable to use option 4, you should use option 3.

Share:

Instead of using XDMCP, you can use X11 forwarding to run your graphical environments across SSH. Doing so also allows you to log in via smart cards, if your version of SSH has PKCS11 support.

I’ve written a script called remote-graphical-login to make this much easier. Note that this script has smartcard support built in, and may not work properly if the libraries do not exist on your system. In a future version I’ll make this configurable so that it can be used with identity files, or without an agent. Here’s the usage:

Usage: remote-graphical-login.sh [-s session] [-I cardlib] [-l username] [username@][hostname]
        -s      kde or gnome (default)
        -I      coolkey or activclient (default)
        -l      Username to login with
Example: remote-graphical-login.sh -s kde testuser@testhost

There may be a few bugs in the script. Let me know if you run into any.

Update (06/14/10): Fixed some issues in the script. Notably, the X launcher did exactly the opposite of what it was intended to do. If an X server was already running, it would re-use that server. The intended action was for the script to start a new X server on another display number. This is now fixed. Also, an informational message will now be shown to users when they do not specify a username or hostname, mentioning the ability to do so.

Share:

Related posts:

1. Using ActivClient or Coolkey with SSH for Smart Card Login using Cygwin

Prerequisites

I’ve tested with the below software and versions. Other versions may work, but haven’t been tested.

• ActivClient 6.2+ or Coolkey
• Cygwin 1.7+
  • OpenSSH_5.5p1+
  • OpenSSL 0.9.8n+

Obviously you’ll also need a smart card, and a supported smart card reader.

All the instructions below pertain to either ActivClient, or Coolkey. You need one or the other, not both. Coolkey is FOSS, and works, if you do not wish to buy ActivClient; for the full FOSS smart card suite, see the ESC guide.

Some of the following instructions assume you are typing commands into a Cygwin window that has an SSH agent started the following way:

ssh-agent /bin/bash

Add the reader library

ActivClient

Add the acpkcs211.dll to your agent:

ssh-agent -s acpkcs211.dll

Coolkey

Add the libcoolkeypk11.dll to your agent:

ssh-agent -s libcoolkeypk11.dll

Export the card’s public certificates

You can export the public certificates with an agent running with the following command:

ssh-add -L

You can export the public certificates without an agent with the following command for ActivClient:

ssh-keygen -D acpkcs211.dll

You can export the public certificates without an agent with the following command for Coolkey:

ssh-keygen -D libcoolkeypk11.dll

Add the public certificates to your authorized_keys file

If you have an agent running, you can have the keys automatically added to your authorized_keys file by running the following command:

ssh-copy-id [user@]<hostname>

If you do not have an agent running, copy the output from the section above, and manually append it to the end of your authorized_keys file.

Signing into a system using the card’s certificates

If you are using an agent, you simply need to ssh as you normally would. If you are not using an agent, there are two different ways to use the card:

Using ActivClient

ssh -I acpkcs211.dll [user@]<hostname>

or:

ssh -o PKCS11Provider=acpkcs211.dll [user@]<hostname>

Using Coolkey

ssh -I libcoolkeypk11.dll [user@]<hostname>

or:

ssh -o PKCS11Provider=libcoolkeypk11.dll [user@]<hostname>

If you notice, the second method is using an SSH configuration option, which means you can add this to your user or system configuration file so that the card’s library will be used by default.

Share:

Related posts:

1. Using NSS with OpenSSH for Smart Card Login
2. Graphical login into Unix/Linux systems from Cygwin using SSH
3. Seamless Smartcard login with pam_pkcs11, and pam_krb5 against an Active Directory Domain using Red Hat Enterprise Linux 5 (Part 2)

This post about managing certificate trust flags in Network Security Services (NSS) databases is part of that 10%, and is the kind of thing everyone dealing with NSS should read. It is crazy that this information is missing from Mozilla’s documentation on certutil; this really makes the trust flags clear!

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 1)
2. SSL replication and CA trusts in Sun Directory Server 6.x

The dsadm list-certs -C command will show you what CA certificates you are trusting, but it won’t show you how it is trusting a certificate. If you are getting an error like “Bind failed with response: Failed to bind to remote (900).”, and you know SSL should be working properly, you probably want to check to see exactly how your CA certificates are being trusted.

To do this, use the certutil command:

certutil -L -d /var/opt/SUNWdsee/dsins1/alias -P slapd-

The trust should show as “CT,,”. If it is showing as “c,c,c” or pretty much anything else, your CA certificate isn’t trusted properly. You can remove the  certificate and re-add it using certutil in the following ways:

certutil  -D -n "<your CA cert's alias>" -P slapd- -d /var/opt/SUNWdsee/dsins1/alias
certutil  -A -n "<your CA cert's alias>" -P slapd- -d /var/opt/SUNWdsee/dsins1/alias -i <location of your CA cert> -a

Now restart your directory server, and test replication. If you are lucky, this is your problem.

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 1)
2. Seamless Smartcard login with pam_pkcs11, and pam_krb5 against an Active Directory Domain using Red Hat Enterprise Linux 5 (Part 3)
3. Seamless Smartcard login with pam_pkcs11, and pam_krb5 against an Active Directory Domain using Red Hat Enterprise Linux 5 (Part 2)

Notice that this post will discuss a package that is yet to be officially released by Red Hat. Whenever this is officially released, it may have different configuration options, or different functionality. I’ll update this post at that time.

Configure the krb5.conf

Add the following information into the [libdefaults] section:

        default_realm = EXAMPLE.COM

This tells the Kerberos client that by default, it will use the EXAMPLE.COM realm unless otherwise specified. If you are in an environment where another Kerberos realm is supposed to be your default, you can skip the [libdefaults] section. Later, I’ll show you how pam_krb5 can work without this configuration setting.

Add the following information into the [realms] section:

        EXAMPLE.COM = {
                kdc = kdc1.example.com
                kdc = kdc2.example.com
                admin_server = kdc1.example.com
                default_domain = example.com
        }

This tells the Kerberos client about the EXAMPLE.COM domain; specifically: what the servers are, and the default domain.

Add the following into the [domain_realm] section:

        .example.com = EXAMPLE.COM

This maps the DNS domain name to the Kerberos domain name; if you have service records for your Active Directory domain, this may not be necessary.

Add the following into the [appdefaults] section:

        allow_pkinit = yes
        pkinit = {
                client_ca_certificate_pool = /etc/pki/tls/certs
                EXAMPLE.COM = {
                        trusted_guid = f7:11:44:70:97:a8:40:d8:bb:a1:b8:7f:4e:a2:ed:fe 51:6d:28:dd:57:af:4d:b5:90:09:00:a1:c0:39:48:a2
                        is_hw = yes
                        pkinit_cert_match = &&<EKU>msScLogin,<KU>digitalSignature
                }
        }

This is where the magic happens. First we tell the Kerberos client to allow pkinit (which is for pre-authentication, aka token login). Next we make a section for pkinit, tell it where the PEM (ascii) encoded CA certs are, and make a section for our domain. In the domain section, we tell the Kerberos client which servers to trust, that the token is a hardware token, and the criteria needed for a valid login certificate from the smartcard.

The pkinit_cert_match field has the following documentation in the version of pkinit-nss that I am discussing:

pkinit_cert_match   – Alternate combinations of client certificate
characteristics which would cause it to be deemed
sufficient for use.  Rules are specified as combinations
of fields and specifications in the form
[&&]<FIELD1>spec1[,<FIELD2>spec2[,...]] [...]
<FIELD1>spec1[,<FIELD2>spec2[,...]] [...]
[||]<FIELD1>spec1[,<FIELD2>spec2[,...]] [...]
Recognized fields and the types of specifications to be
used include
<SUBJECT>     Regular expression.
<ISSUER>      Regular expression.
<SAN>         Regular expression.
<EKU>         List of zero or more values, possibly
including “pkinit”, “msScLogin”,
“clientAuth”, and “emailProtection”.
<KU>          List of zero or more values, possibly
including “digitalSignature” and
“keyEncipherment”.
There is no default.

pkinit-nss needs to match exactly one certificate off of your smartcard; you can use these criteria to specify which certificate will be used. Notice that in the above configuration I chose a certificate that was allowed for Microsoft Smart Card Login, and was a digital signature type of certificate.

Notice that the guids are collected via the pkinit-show-cert-guid command, and that they are space delimited.

Collecting server guids

1. Get the server’s public certificate
   1. openssl s_client -connect kdc1.example.com:636
   2. Find the section that starts with “BEGIN CERTIFICATE” and ends with “END CERTIFICATE”; copy everything including the begin and end sections, and paste it into a file
2. Use pkinit-show-cert-guid on the file to get the guid
   • pkinit-show-cert-guid <file>
3. Repeat for every Active Directory server

Configure PAM

The following is an example /etc/pam.d/system-auth file:

auth        required      pam_env.so
auth        [success=2 default=ignore] pam_succeed_if.so service notin login:gdm:xdm:kdm:xscreensaver:gnome-screensaver:kscreensaver quiet use_uid
auth        [success=ok authinfo_unavail=2 ignore=2 default=die] pam_pkcs11.so
auth        [default=ignore] pam_krb5.so no_subsequent_prompt no_initial_prompt
auth        sufficient    pam_permit.so
auth        sufficient    pam_unix.so likeauth
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_krb5.so
account     required      pam_permit.so

password    optional      pam_pkcs11.so
password    requisite     pam_cracklib.so retry=3 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 minlen=10
password    sufficient    pam_unix.so md5 shadow try_first_pass use_authtok remember=5
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     optional      pam_krb5.so
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

It is important to understand what is happening in the auth stack here. Read the following three lines carefully:

auth        [success=ok authinfo_unavail=2 ignore=2 default=die] pam_pkcs11.so
auth        [default=ignore] pam_krb5.so no_subsequent_prompt no_initial_prompt
auth        sufficient    pam_permit.so

The first line says if pam_pkcs11 succeeds, continue on; if a card isn’t available, or we can’t map the card identity to a user, skip the next two lines; if the user puts his pin in incorrectly, exit with a failure. The second line says don’t prompt for a pin, don’t prompt for a password if the pin fails, and ignore the return value of pam_krb5. The third line says no matter what, return success.

This configuration ensures a few things:

1. Ensures if the user types her pin in incorrectly, it won’t cause two incorrect pins against the card
2. Ensures that the system will only try to get a Kerberos ticket if the user is using a card
3. Ensures that the user can log into the system with a card even if they can’t get a Kerberos ticket
   • If you wish to require valid Kerberos authentication, pam_krb5 should be marked as “required”, the pam_success line should be removed, and the pam_pkcs11 module line’s arguments should be changed to “authinfo_unavail=1 ignore=1″

Notice that if you are trying to completely eliminate passwords, that this PAM configuration won’t fully do it. This configuration still allows password authentication to the local system. You should tweak this configuration as necessary. Remember, however, that you likely don’t wish to lock root out of the system – so be careful!

As I mentioned earlier, if your default Kerberos domain cannot be your Active Directory domain, you can specify it explicitly in the PAM configuration; to do this, your auth line for pam_krb5 would change to the following:

auth        [default=done] pam_krb5.so realm=EXAMPLE.COM no_subsequent_prompt no_initial_prompt

Conclusion

This series should be a good starting ground for getting your PKI environment set up on your RHEL systems. In the future I will discuss more ways to eliminate passwords by using Smart Card authentication.

If you have any questions, please be sure to leave a comment!

Update (04/24/2009): I updated the krb5.conf configuration.

pkinit_cert_match = &&msScLogin,digitalSignature

should have read as:

pkinit_cert_match = &&<EKU>msScLogin,<KU>digitalSignature

Update (05/12/2009): The PAM configuration was slightly incorrect. The way it was previously written would deny users access if pam_krb failed.
Update (05/26/2009): The openssl s_client command was slightly incorrect; I changed “connect” to “-connect”.

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 1)
3. Using NSS with OpenSSH for Smart Card Login

In another blog post, I mentioned how to configure NSS and OpenSSL; you should take a look at that if you are unfamiliar with the process, because I assume that is prerequisite knowledge. I will also assume you have a basic understanding of how public key authentication in SSH works.

Here are the steps to the process:

1. Copy the NSS databases to .ssh
2. Start an ssh-agent, if you don’t already have one running and connected
3. Add your Smart Card certificates to the ssh-agent
4. Extract a public key from one of your certificates, and put it into the authorized_keys of the host you wish to connect
5. SSH to the host

Copy the NSS database to your .ssh directory

We’ll take the centralized database, and place it somewhere that OpenSSH has permissions to read and write to. The centralized database should have the coolkey module loaded, which gives access to your smart card.

cp /etc/pki/nssdb/*.db ~/.ssh

Start an ssh-agent

First let’s see if you have an agent running:

env | grep 'SSH_AGENT'

If you see “SSH_AGENT_PID” listed, you already have an agent running, and can skip this step. If you do not see this, you should start an agent:

eval `ssh-agent`

Add your Smart Card certificates to the ssh-agent

This will add your certificates into the agent; notice that your keys never leave your card, so when you are SSHing back and forth, you’ll need to keep your card inserted.

ssh-add -n

Take note of the certificates that got added to your agent, you’ll need them.

Extract a public key from your Smart Card, and add it to the authorized_keys file

You’ll need to be able to log in with at least one of the certificates from your Smart Card, so you’ll need to extract the certificate and place it into the authorized_keys file on the host you wish to connect to.

ssh-keygen -n -D 'My PKCS11 Token' -f 'My Key ID'

You can get the ‘My PKCS11 Token’ by using modutil:

modutil -list -dbdir .ssh

Look for the “token:” line under the Coolkey module.

‘My Key ID’ is one of the certificates that was listed as being added to your ssh-agent.

The ssh-keygen command will output a public key. Take this public key, and place it into the authorized_keys file on whatever host you wish to login to with your smart card.

SSH to the host

Now you should be able to SSH to the host; it shouldn’t require a password, it should just log you in. You do have to use a special syntax though:

ssh -o 'UseNSS yes' <host>

If ssh asks you for the password for the “NSS Certificate DB”, simply press enter. I haven’t figured out how to make it ignore that database yet (and you can’t remove the built-in NSS database).

Bonus: connecting to a host without using an ssh-agent

If you’d like to skip the step about using an ssh-agent, you can connect simply by using ssh:

ssh -o 'UseNSS yes' -o 'NSSToken <My PKCS11 Token>' <host>

Like above, you can get the <My PKCS11 Token> by using modutil (see above section for command).

See the README.nss

Although the README.nss file is currently slightly incorrect on syntax, it explains the same process.

less /usr/share/doc/openssh-*/README.nss

Share:

Related posts:

1. Using ActivClient or Coolkey with SSH for Smart Card Login using Cygwin
2. Seamless Smartcard login with pam_pkcs11, and pam_krb5 against an Active Directory Domain using Red Hat Enterprise Linux 5 (Part 2)
3. Seamless Smartcard login with pam_pkcs11, and pam_krb5 against an Active Directory Domain using Red Hat Enterprise Linux 5 (Part 1)

What does pam_pkcs11 do for me?

The pam_pkcs11 module will do a couple things for us:

1. Allow/Require smartcard login
2. Map an attribute from the card to a login name

For a basic configuration, we’ll have to edit three files; /etc/pam_pkcs11/pam_pkcs11.conf, /etc/pam_pkcs11/cn_map, and /etc/pam.d/system-auth.

Configuring pam_pkcs11 and testing smart card access

Edit /etc/pam_pkcs11/pam_pkcs11.conf; this file is kind of long, so I’ll just touch on specific configuration lines, and only the basic configuration lines needed to get the authentication working.

enable_ocsp = false;

The above line tells pam_pkcs11 whether we wish to use OCSP or not. Notice that in general it is good to use OCSP if you have an OCSP available. If you do not have an OCSP server, you’ll have to manually add CRLs to your centralized NSS database. We’ll leave this set to false for testing purposes.

use_pkcs11_module = coolkey;

The above line specifies which module the system should use to access the smart card. You should keep this configured to coolkey.

pkcs11_module coolkey {
  module = libcoolkeypk11.so;
  description = "Cool Key"
  # Slot-number to use. One for the first, two for the second and so
  # on. The default value is zero which means to use the first slot
  # with an available token.
  slot_num = 0;

  # Path to the directory where the CA certificates are stored. The
  # directory must contain an openssl hash-link to each certificate.
  # The default value is /etc/pam_pkcs11/cacerts.
  ca_dir = /etc/pam_pkcs11/cacerts;
  nss_dir = /etc/pki/nssdb;

  # Path to the directory where the CRLs are stored. The directory
  # must contain an openssl hash-link to each CRL. The default value
  # is /etc/pam_pkcs11/crls.
  crl_dir = /etc/pam_pkcs11/crls;

  # Sets the CRL verification policy. None performs no verification
  # at all, online downloads the CRL form the location given by the
  # CRL distribution point extension of the certificate and offline
  # uses the locally stored CRLs. Auto is a combination of online and
  # offline; it first tries to download the CRL from a possibly
  # given CRL distribution point and if this fails, uses the local
  # CRLs. The default setting is none.
  # crl_policy={none, online, offline, auto}
  crl_policy = none;

 }

The above section configures the coolkey module. You should ensure “nss_dir = /etc/pki/nssdb;” and that “module = <path_to_your_module>;“. Notice that in the example above, I have the module line pointing explicitly to the dynamic module on the system. If you are using a 64 bit OS, this may not be the correct configuration. Since RHEL uses NSS and not OpenSSL for pam_pkcs11, we can ignore the ca_dir, crl_dir, and crl_policy lines.

use_mappers = cn, null;

The above line specifies which mapping modules we wish to use, and in what order to use them. I have configured pam_pkcs11 to only use the cn module (the null module always fails by default).

mapper cn {
      debug = false;
      module = internal;
      # module = /usr/$LIB/pam_pkcs11/cn_mapper.so;
      ignorecase = true;
      mapfile = file:///etc/pam_pkcs11/cn_map;
}

The above section configures the cn mapping module. The important line is “mapfile = file:///etc/pam_pkcs11/cn_map;“. This line tells pam_pkcs11 where to find cn to user name mappings.

Now we’ll need to edit the /etc/pam_pkcs11/cn_map file, and add cn to user name mappings.

RYAN.LANE -> laner
TEST.USER -> usert
external_user -> usere

The above lines placed in the cn_map file tell pam_pkcs11 that the CNs on the left match the user names on the right. If you don’t know what the CN of the user on the card is, you can find out using the pkcs11_inspect command.

$ pkcs11_inspect
RYAN.LANE

Before we modify PAM, we should ensure we can access the smart card, and map CNs to user names. Using the pklogin_finder command, we can both test access to the smart card, and whether the mapping is working properly. The output of the command should return the user name. If it returns nothing, the mapping module probably isn’t mapping the user properly. For more detailed information, you can run “pklogin_finder debug“; as a warning, running this command with debug will print your pin to the screen.

$ pklogin_finder
laner

$ pklogin_finder debug
DEBUG:pam_config.c:188: Using config file /etc/pam_pkcs11/pam_pkcs11.conf
DEBUG:pkcs11.c:65: Initializing NSS ...
DEBUG:pkcs11.c:75: Initializing NSS ... database=/etc/pki/nssdb
DEBUG:pkcs11.c:89: ...  NSS Complete
DEBUG:pklogin_finder.c:67: loading pkcs #11 module...
DEBUG:pkcs11.c:101: Looking up module in list
DEBUG:pkcs11.c:104: modList = 0x8b1ad50 next = 0x8b2a870
DEBUG:pkcs11.c:105: dllName= <null>
DEBUG:pkcs11.c:104: modList = 0x8b2a870 next = 0x0
DEBUG:pkcs11.c:105: dllName= /usr/lib/libcoolkeypk11.so
DEBUG:pklogin_finder.c:75: initialising pkcs #11 module...
DEBUG:pklogin_finder.c:87: no token available

Notice the above debug output is telling me that I don’t have a smart card inserted…

Configuring PAM

The only file we need to configure for smart card login is /etc/pam.d/system-auth; your file should look something like this:

auth        required      pam_env.so
auth        [success=1 default=ignore] pam_succeed_if.so service notin login:gdm:xdm:kdm:xscreensaver:gnome-screensaver:kscreensaver quiet use_uid
auth        [success=done authinfo_unavail=ignore ignore=ignore default=die] pam_pkcs11.so
auth        sufficient    pam_unix.so likeauth
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     required      pam_permit.so

password    optional      pam_pkcs11.so
password    requisite     pam_cracklib.so retry=3 dcredit=-2 ucredit=-2 ocredit=-2 lcredit=-2 minlen=10
password    sufficient    pam_unix.so md5 shadow try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

Notice that the important lines are:

auth        [success=1 default=ignore] pam_succeed_if.so service notin login:gdm:xdm:kdm:xscreensaver:gnome-screensaver:kscreensaver quiet use_uid

This tells PAM that pam_pkcs11 should only be used if it is in one of the following services: login:gdm:xdm:kdm:xscreensaver:gnome-screensaver:kscreensaver. This ensures that the smartcard won’t be accessed if someone logs in via a service like SSH, or FTP, where smartcard login doesn’t make sense.

auth        [success=done authinfo_unavail=ignore ignore=ignore default=die] pam_pkcs11.so

This tells PAM to succeed if pam_pkcs11 logs the user in, and maps their user name properly, but to ignore the module otherwise. In this case, regular unix password authentication is still allowed. If you wish to disallow password authentication, you should set authinfo_unavail and ignore to die.

password    optional      pam_pkcs11.so

This optionally allows PAM to reset the password/pin on the smartcard. This line isn’t likely needed, and you can leave it out if you wish.

After saving the file, you should test your PAM configuration before logging out. You can do so by going to a virtual console, and logging in. Do the following:

1. Insert your smart card
2. At the Username prompt, hit the spacebar once and hit enter
3. Type in your PIN when requested
   • If you are using the number pad, make sure num lock is on!

Conclusion and next part in the series

With this, you should be able to log users into a system using a smartcard. In the next part of this series, I’ll discuss how to add pam_krb5 into the mix to automatically get a Kerberos ticket from an Active Directory domain using PKINIT.

Update 12/08/08: Removed the stuff about pointing explicitly to the coolkey module. I tested this recently, and it was working fine without (for the first time). Pointing to the module explicitly definitely causes issues with 64-bit RHEL. Maybe Red Hat fixed this in a later release?

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 3)
2. Seamless Smartcard login with pam_pkcs11, and pam_krb5 against an Active Directory Domain using Red Hat Enterprise Linux 5 (Part 1)
3. Using NSS with OpenSSH for Smart Card Login

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