How to differentiate between certificates issued by the same CA

Question

I have a certificate which is signed by an external Certificate Authority (CA). If I understand correctly that Certificate Authority can also sign other certificates that I'm not aware of. My question is how one would tell that certificates sign by a third-party Certificate Authority belong to my company and which do not?

My use case

I want to enable certificate-based authentication from a PIV / CAC card. All the certificates are signed by a third-party CA. My worry is that users that I'm not aware of will be able to authenticate themselves with certificates that are signed by an external CA and don't belong to my company.

Answer 1

Generic certificate advice, I'm not familiar with how official PIV/CAC systems are set up:

1. Certificates have a Subject field that the CA is supposed to fill in with the owner's correct details. If you trust the CA to do this correctly, then configure your system to only accept users who have a known Subject – either by matching specific attributes or just the whole stringified value.

   For example, if the Subject field includes an email address with your domain, or if it has an O attribute (for "Organization"), then you may be able to match against that. (Though beware of the possibility to register duplicate organization names – in the US, you'd need to compare the State or Locality fields as well.)

   If the subject doesn't have anything specific to your organization, then you'll have to keep a central list of Certificate Subjects that belong to every employee. (Active Directory already has a built-in mechanism to map X.509 subjects to AD users.)

   • Ensuring correctness of certificate details is literally the One Job of a CA (i.e. that's what a certificate certifies), so if you don't trust this particular third-party CA to correctly fill in the Subject field, then you basically can't trust the CA at all. In such situations, your only option is to treat the certificates as essentially self-signed and match them by hash (see option 4 below).

2. The subjectAltName extension can be used the same way if present. According to the published documentation from NIST, real PIV/CAC certificates have one SAN value containing the card's CHUID. If you're putting non-PIV certificates on a PIV card, the CA decides what subjectAltName to add – it might have the employee's email address, etc.

3. Certificates also have a Serial Number that is supposed to be unique between its direct siblings, and the combination of Issuer+Serial must be unique globally (so you can use it as an identifier).

4. Finally, there are two common ways to distinguish individual certificates regardless of how they were issued: either a hash of the entire certificate in DER form (commonly known as the "fingerprint" or "thumbprint"), or a hash of only its public key in DER form (also known as "SPKI hash" due to hashing the SubjectPublicKeyInfo field).

   Which hash to use depends on how the certificates are renewed – if renewals continue to use the same keypair, then the same SPKI hash will continue to identify new certificates (while each renewal would have a different fingerprint); however, that's probably uncommon in PIV/CAC systems, so it's simpler to just use the fingerprint.

Answer 2

Referring to your use-case, remember that the certificate provides identity and authentication only.

Authorisation should be controlled by the application - for example, using a directory - and not the certificate. So, these unknown users may well be able to present an accepted certificate to your application, but that application should reject them, not through certificate verification failure, but through some form of ACL failure.

For example, my certificate may be accepted by your IIS server, which now knows that garethTheRed is who he claims to be, but as I'm not registered within your system, I shouldn't be permitted to login to your application.