I am very familiar with OpenPGP but don't even use X.509 / S/MIME. I know that there are several classes for certificates (from email check to personal ID check). I would like to know how you determine the class of a certificate.

Is this information part of the CA signature? Or is that an organuzational feature only, using different root certificates for different classes? I noticed that one CA has different root certificates which have the class number in their name. Is there a real attribute for a root certificate which tells the user the class?


Certificate "class" is essentially a marketing terminology. Each CA is free to call some of the certificates "class 0" or "class 1" or whatever, roughly meaning "I issued that but I did not bother to check" or "this time I did some checks because the owner paid me enough for that".

Theoretically, as per X.509 rules, the "class" should be encoded in the certificate as a Certificate Policies extension: the CA can put there some OID which designate the set of procedures applied for the issuance of the certificate. However, these OID are CA-specific, and can be understood only by having a look at the Certification Practice Statement, a legal-looking document that may or may not be referenced from the CP extension, and is usually a 200-pages PDF file that cannot be digested by a computer, only by a human being (or a lawyer).

Recently, some commercial CA and browser vendors have reached some agreement about Extended Validation certificates, which can be thought of as "upper class" certificates (certificates where the CA actually applied some care in the process), and are indeed identified by their CP extensions. Yet the identification is still made relatively to a big list of "EV-compliant policy OID" that clients (Web browser) somehow know in advance (it is maintained by the browser vendors).


By "Classes" I think you mean "Extended Key Usages", and that attribute in particular is used by applications (email, web browsers, smart cards, IPSec, etc) to determine what that certificate is permitted to do.

An EKU can be specified on the root CA or any subCA below it. Wherever that EKU is defined, then all usages below should inherit that restriction.... again this is implementation specific.

From my testing SMIME signing and validation are enforced in client applications, as is HTTPS certificates (also known as Server Authentication)

To see what a certificate is set to, simply open it up in your certificate store, or dump out the contents and youll see a section called "Extended Key Usages".

All the other properties you see (including Basic Constraints) also limit whether or not a given certificate is permitted to sign a child certificate ... which is the definition of what a CA does when it gave you your cert.

  • 1
    No. I mean: "class 0" == "test cert", "class 1" == "only the email address is verified", "class 2" == "for companies", "class 3" == "personal ID check". I have read about that several times but now I am surprised that neither the English nor the German Wikipedia article mentions that. – Hauke Laging Jul 13 '14 at 3:38
  • @HaukeLaging You're probably talking about assurance? ietf.org/rfc/rfc3647.txt (low assurance, medium, or high) and the meaning of each is defiend in the CPS – Christopher Jul 13 '14 at 11:08

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.