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.
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.