Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Looking at the details of a certificate using the following:

openssl x509 -noout -text -purpose -in mycert.pem

I find a bunch of purpose flags (which I've discovered are set by the various extensions attached to a certificate).

One of these purpose flags is "Any Purpose". I can't seem to find ANY documentation on this flag and why or why not it is set.

Do any of you know where I can find more information on this purpose and what it means?


share|improve this question

In X.509 certificates, as in most other things, if a term is not explicitly defined then it inherits the meaning from its immediately-surrounding context. If that context is "life", then the phrase "Any Purpose" means literally that.

So, check the Certificate Policy, Subscriber Agreement, and Relying Party Agreement of the issuing CA, and if they say nothing about the flag then it means what it says on the box.

share|improve this answer
The policy, subscriber agreement, and relying party agreement shouldn't have any technical impact on the certificate's use. – Falcon Momot Aug 20 '12 at 2:07
@Falcon - those documents are the immediate context for the certificate, and ultimately define how a human interprets it. There can be no "technical impact" other than "this flag is set" - human interpretation is all. – mlp Aug 20 '12 at 3:14

The KeyUsage is a v3 extension, which may or may not be present in a certificate.

A useful (if slightly dated) summary of id-ce-keyUsage values: [newly added values are 7 = encipherOnly and 8 = decipherOnly]

The trick is that this "OID= keyUsage extension" /might or might not/ be present in a particular certificate.

What OpenSSL probably presumes with PURPOSE_ANY, is that this extension was /not present/, and that it's therefore "up to your own policy" to decide what to use or not use it for. Otherwise, there's no bitmap value that corresponds to "ANY"...

share|improve this answer


Key-Usage: Purpose of the public key (e.g. encipherment, signature, certificate signing...).

See the -purpose flag in the openssl docs:

share|improve this answer
I was not asking what all of the other purpose bools represented, I was asking what the "Any Purpose" was and how it was set. This is not defined in either of the two links you sent me. – Nick Feb 10 '10 at 19:06
Your are right, that flag is not explicitly documented, I assumed that "Any Purpose" would mean any of the purposes listed. I looked at the code in openssl/crypto/x509v3/v3_purp.c and crypto/x509v3/x509v3.h. grep the source tree for: X509_PURPOSE_ANY I interpret it as being an extension of the certificate that means the cert is suitable for any purpose. i.e. that flag is just another x.509 certificate extension. – tajh Feb 10 '10 at 21:46

Most certificates are issued with a purpose (or set of purposes) to which they are restricted, such as client auth, server auth, key exchange, and code signing. If they are used for a purpose not endorsed (eg. using your email certificate to sign code), they are not valid.

The any purpose extension simply means the certificate should always pass usage constraints, which is the same as saying it is valid for all usages.

share|improve this answer

OpenSSL's 'purpose' stuff isn't quite just a straight reflection of the Key-Usage extension of a v3 certificate.

OpenSSL defines a set of 'purposes' itself, and then has some logic that determines whether a given certificate is consistent with the chosen purpose based on the certificate extensions - including, but not limited to, the key usage and extended key usage extensions.

'Any Purpose' is what you get if you pass -purpose any to openssl verify or if you write code which sets the purpose of an OpenSSL context to the 'any' value using e.g. SSL_CTX_set_purpose().

Most of the purposes are documented in man x509 section CERTIFICATE EXTENSIONS - it explains what properties the certificate must have to be valid for the given purpose - but this doesn't document the any purpose. In the source, at the top of crypto/x509v3/v3_purp.c you can see that the check function run for X509_PURPOSE_ANY is no_check(), which simply returns 1: effectively it disables purpose checking.

I'm not sure if you could possibly engineer a situation in which any certificate would not be valid for the any purpose. I'm also not sure what the difference is between setting the purpose to any and not setting a purpose at all, which should cause purpose checking to be entirely bypassed.

Specifically, OpenSSL's X509_PURPOSE_ANY / "Any Purpose" / -purpose any concept is not the same thing as the RFC 5280 anyExtendedKeyUsage KeyPurposeId.

share|improve this answer

Usually I set "AnyPurpose" on Root CA (meaning this is root and can issue certificates to any other intermediate or sub CA), and then, when issuing the intermediates CA I set the restrictions...

My Root CA have:

  • AnyPolice,
  • CA:True,
  • AnyPurpose,
  • DigitalSignature,
  • CRL Distribution Points,

On my intermediate TLS CA for Example I set:

  • Web ServerAuth TLS,
  • Web ClientAuth

This is limit the TLS CA from inheritance from all attributes from Root CA (the restrictive OIDs apllied here will allow only sign TLS certificates and with pathlen:0 I will forbidden sub CAs).

Everything depends how you set your PKI infrastructure.

On my network I do one intermediate CA per purpose, example:

  • Intermediate CA for Emails
  • Intermediate CA for TLS
  • Intermediate CA for Software
  • Intermediate CA for Identity
  • Intermediate CA for Components

This way if there an problem with an mail certificate, I only need revoke the Email CA while all other Intermediate CA are fine.

Big Certification Authorities have for example an dedicated intermediate CA to EV.

Note: This is for personal PKI, if you wish do something following RFCs and best practices like big Certification Authorities do, then there a lot of extra stpes, like include much more OIDs and setup all them...

For example you can read some of the standards on this link:

Another example, for EV certificates there a lot of extra steps setup OIDs:

  • Domain Validated
  • Organization Validated

And since my setup do not need those, I don`t spended my time searching and testing the necessary OIDs for get this working

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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