0

If I understand correctly in SSL/TLS authenticity validation there are 2 (maybe more) types of certificates according to the following:

  • the ones that belong to CA (these contain the public key that is used to verify other certificates)
  • the ones that belong to end users (hosts) (these contain the public key that is used to encrypt channel between TLS client and TLS server)

Is this correct and how to detect of which type is the certificate when presented?


NOTE: I'm checking with wireshark. Server presented me 2 certificates, one for its domain name and one for its CA. I think I have to check the extensions field, probably id-ce-basicConstraint or id-ce-keyUsage.

2

So, there's a few ways to tell (in no particular order):

  • Basic Constraints: can identify a certificate as belonging to a CA or an end entity.
  • Key Usage: CA certs will be valid for certificate and (usually) CRL signing, and (usually) not for key encryption. Enhanced key usage information may or may not be helpful here.
  • Subject Name: end-entity certs will identify an end entity (such as a domain name, email address, etc.), while CA certs will identify a CA. While there's nothing technically stopping a CA from using a cert with a domain name or similar as its common name field, in practice I would never expect to see one.
  • Checking the signature chain: Root CA certs are self-signed, and should be found in your trust store (most web servers don't actually send these out themselves); intermediate CA certs should be signed by either root CA certs or intermediate CA certs, and end entity certs are almost always signed by intermediate CA certs, and haven't signed any certs themselves. In the situation you describe (seeing two certs in Wireshark), you can be pretty sure that the one that signed the other is a CA cert and the one that was signed is the end entity cert.
1

CA certs have to contain the cA Flag with value true in the Basic Constraints extension. See also this question

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.