views:

53

answers:

2

We're trying to enable our rich client C++ Windows application to utilise DoD CAC cards.

We're using a third party library to secure our client/server communication using SSL, and it recognises/handles generic smart cards, but only if the certificate was created by its own, bundled application.

Why? Isn't a certificate a certificate? How do they vary?

Specifically, can anyone point me to condensed, technical documentation that explains what is mandated by the relevant standards and what remains implementation defined? I've tried looking at the actual specs, but they are too detailed, and I've found very vague articles, that don't answer my questions. I'm looking for something in between.

A: 
  • A certificate is a certificate. Certificates are usually "created" by a CA, not by the smart card vendor personalization software. Access to keys is what matters when using smart cards.
  • Think of smart cards as CD-s. They all look the same but you need to know the format on the disk. Yes, there's a "generic" format that can be read by most computers but some special software can write special stuff on the disk, others can't read.

Last but not least, if your software makes use of PKCS#11 then as long as you have a PKCS#11 provider for your card (there are several CAC modules and "generic" vendor cards usually come with one as well) you don't need to care about the actual card, because PKCS#11 abstracts the details away.

martin
We're being told by our component provider (who apparently use PKCS#11) that they don't support certificates created by 'other' providers. Maybe this is a separate issue... but we still need to understand how this should work. Can you point us to any good documentation online?
Seb Rose
A: 

I don't have enough points to comment, but I wanted to agree with @Jay. You probably need to configure this third-party library to trust the DoD root certs, so that when a CAC user presents his client cert, your app can trust it.

The DoD root certs are publicly available: http://dodpki.c3pki.chamb.disa.mil/rootca.html

Also if the behavior you are observing is that the client isn't even getting prompted to choose a client cert, or you are not observing a client cert being sent in the packet trace, then this may also be because your server does not trust the DoD CA. When when a well behaved server requests a client cert, it also advertises the distinguished names(dn) of the CA's that it trusts. A well behaved client will then inspect that list, and compare those names the the issuers of the cleint certs that it has available. If there is no match then the client will send a "null" cert. I know IIS/Apache and Firefox/IE/Chrome behave this way. Opera, however, does not seem to discriminate based on the advertised issuers, and will send any cert that client has lying around.

Ajith Antony