X.509 certificates can be used for servers, clients, email, code signing and more applications. http://twitpic.com/6gdxaq indicates that a certificate can have different of these 'capabilities' on it - but how do you see those? What X.509 field denotes these different uses?

3 Answers 3


X.509 "Key Usage" defines what the issuer allows the certificate to be used for. Remember that not all applications follow this requirement however.

  • 1
    Thanks. I've looked it up on tools.ietf.org/html/rfc5280#section- Sounds as if billing more for code signing certs than for 'webserver' certs has no technical basis...
    – chris
    Sep 5, 2011 at 12:55
  • 3
    @chris: usually, billing on certificates is more about authentication procedures used to make sure of the requester's identity; it also relates to insurance coverage, and other legal stuff. Or sometimes this is just plain extortion. Sep 5, 2011 at 19:17
  • 1
    While there is no technical reason why code signing certificates should cost more, as Thomas noted, the insurance and risk aspects of code signing certificates may have a much larger impact than a web site certificate. Applications have the ability to dynamically and continuously modify and distribute information and perform transactions that potentially effect assets. The line between application and web site is being blurred with the advent of webapps, so the difference is less important than it used to be.
    – this.josh
    Sep 7, 2011 at 6:25

There are several extensions which restrict usages for a certificate. A basic certificate, without any extension, is deemed "fit for any purpose", as far as X.509 is concerned. The key type can still have some consequences; e.g. a RSA key can work for both asymmetric encryption and signatures, but a DSA (or ECDSA) key, by construction, can only serve for signatures (a signature-only certificate is still good enough for a SSL client or server, though, because of "DHE" cipher suites).

The standard extensions which limit "capabilities" for a certificate are the two following:

  • Key Usage: this is a set of flags which indicate low-level operations. There are exactly nine flags: digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly, and decipherOnly. The semantics of each flag are subtle and not well-defined (e.g. the difference between digitalSignature and nonRepudiation is a matter of much more speculation than interoperability).

  • Extended Key Usage: this is an open-ended list of "allowed usages" which are represented as OID. Since there virtually is an infinity of possible OID, there can be no exaustive list of possible extended key usages. Each protocol or standard using X.509 certificate is supposed to define its own extended key usages; e.g. time stamp authorities use (see section 2.3).

Microsoft, in their own CA software ("Active Directory Certificates Services") decided that the standard extensions were not good enough, so they defined another called Application Policies, which contains the exact same information as Extended Key Usage except that its encoding format mimics that of the standard Certificate Policies extension, which means that it gets additional optional comment fields, which ADCS does not actually fill in. Note that ADCS also stores the information as a standard Extended Key Usage extension, so the net effect of this non-standard extension is to spread confusion.

Another, older, non-standard extension which attempted to convey usage restriction was the netscape-cert-type extension. This brings us back to the Netscape Navigator 4.0 times, at the end of the previous century. Some CA still include this extension in their certificates, more for the sake of Tradition than for actual interoperability.

The contents of an extension are honoured only insofar as the involved software understands it. Extensions can be marked "critical", meaning that an implementation which does not recognized an uncritical extension is allowed to ignore it, while an unknown critical extension MUST trigger unconditional rejection of the certificate. That's the theory, and, of course, practice may differ. Some implementations do not honour the criticality flag. Other ignore non-critical extension even if they recognize them. The wording of the standard is not crystal-clear either:

A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized.

An implementation could claim that it has "processed" an extension by ignoring its contents, because there is a difference between recognizing an extension, and enforcing its semantics. The whole picture is made even more blurred with some extensions, in particular CRL Distribution Points, whose semantics depend on whether the extension was marked critical or not.

  • A DSA key can only be used for DSA, but the ECC key format originally devised by X9.62 for ECDSA can also be used for at least ECDH and ECMQV, see rfc5480. OTOH while a raw RSA key can be used for both encryption and signature, the algorithmidentifier in a cert can restrict it to PSS or OAEP, see rfc5756 -- and (after the date this answer was written) the former restriction is used in TLS1.3 rfc8446. Mar 9, 2019 at 4:58

There is a summary of the extensions used for TLS/SSL in NSS Technical Note: 3, by Nelson B. Bolyard.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .