I’m a masochist, and subscribe to the entirety of Sun Microsystem’s blog feed. At least 90% of that content is completely worthless to me; however, the 10% that is worthwhile is usually really worthwhile.

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:

If, like me, you have had issues with replication in Sun Directory Server, maybe this post will help.

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:

Share:

In part 1 I discussed how to configure NSS and OpenSSL. In part 2, I discussed how to configure pam_pkcs11 and how to test a smartcard against the NSS database we set up. In this part, I’ll discuss how to add pam_krb5 into the mix to automatically get a Kerberos ticket from an Active Directory domain using PKINIT.

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.

Share:

At some point in time, Red Hat snuck in experimental support for NSS in OpenSSH. What does that give us? Smart Card support! This article will describe how to use it.

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

Share:

In part 1 I discussed how to configure NSS and OpenSSL. In this part, I’ll discuss how to configure pam_pkcs11 and how to test a smartcard against the NSS database we set up.

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.

Share:

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.

Share: