Web browsers don’t display very friendly error messages to users when SSL client authentication fails. What most people understand from the error message displayed is “This site doesn’t work for me”. This is a usability failure. Your site should always display useful error messages to your users.

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.

Share:

XDMCP is insecure when used directly, as it is unencrypted, and will send your credentials and all keystrokes and mouse actions  over the network in clear text. By default XDMCP is disabled on most recent distros. Thankfully there isn’t any reason to use it!

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.

Share:

At some point recently the SSH shipped with Cygwin added PKCS11 support. This support allows you to add a smart card library to use your smart card’s certificates as ssh keys. This article will describe how to use ActivClient or Coolkey to access your card, how to export the card’s public certificates (as rsa public keys), and how to use ssh/ssh-agent options to properly use the smart card.

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+

Share:

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: