views:

2154

answers:

5

I have figured out all the necessary steps to get DOD CAC card based client certificate authentication working in Apache, but am now struggling to pull a good GUID for the user from the certificate I am receiving. Is there a GUID available on the certificate that will not change when the CAC card is renewed? I was thinking of using the SSL_CLIENT_S_DN which would look something like:

/C=US/O=U.S. Government/OU=DoD/OU=PKI/OU=CONTRACTOR/CN=LAST_NAME.FIRST_NAME.MIDDLE_NAME.0123456789

but I have heard that the number on the end changes when the CAC card is renewed. Is this true? Is there a better piece of information to use for a GUID? I'd also like to get the users email address, but I don’t see it available in the information I am receiving from the certificate. Is the email adress available in some custom extension that I am not seeing?

Thanks!

A: 

I have heard the argument for using the number on the end as the unique identifier for individuals because the other information (name, organization, etc) are the bits of information that can realistically change over time as opposed to the number. However, I have not seen an official document or any other piece of authoritative information that actually states this as a fact.

Just curious, is there a document that speaks to the step-by-step process of enabling Apache and DOD CAC? That's what actually brought me to this question in the first place :)

+1  A: 

The email address is available in the Subject Alternative Name fieldset. This depends on CAC certificate, but that used for SSL login should contain it (it's also the email signing cert).

The subject would not likely change for a given person very often. The number is indeed the unique number identifying a person. This number would also be present in a UPN field in the Subject Alternative Name for windows login (in a form such as NUMBER@MIL)

harningt
+2  A: 

We have run into plenty of instances where that number on the end changes. We were eventually beaten into using a process where that if a user gets a new CAC, we require that the user re-associate that new card with their user account. That's the process on most DoD systems now, such as DKO (Defense Knowledge Online) and others. If we do not have the supplied CAC certificate's data in our database, the user must log onto the system using a username and password. If the credentials are correct, the identifying information of that CAC is associated with the user's account in the system.

At least that's how we did it.

And, as far as, getting access to the email address, @harningt is correct. It depends on which certificate is supplied to you.

Billyhole
A: 

First, many PKI-enabled DOD sites should support hardware tokens issued through commercial CAs that participate in the DOD's ECA program (Verisign, IdenTrust, ORC). These ECA-issued certificates don't even include this "number", the DOD EDI PN.

As I understand it, there is supposed to be some effort made to keep the number stable for a particular person. For example even if I quit my civilian the DOD and go to work for a contractor, get married and change my name, quit my job and enlist in the Coast Guard, my DOD EDI PN should be the same. However, in practice, I doubt it works like that.

And even if it did, I probably shouldn't have the same access to an application. Each time my employment changes, the certificate on my CAC should be revoked. If an application is only looking at the common name or subject alternative name of the certificate, it will miss changes in the organization that probably affect the authorization of that subject.

Basing authentication on a particular certificate (issuer and serial number) is a pain for users, but it does make sense from a standpoint of security and robustness.

erickson
A: 

You could retrieve the owners SSN from the PIV. That will not change

Darryl