OpenSSL x509 Purpose flag "Any Purpose" What is this?

The Any Purpose : Yes and Any Purpose CA : Yes lines from the openssl x509 -purpose are special. It is openssl specific and represents what the certificate will be validated for when used with ancient software versions that do not check for extensions.

These specific purpose flags can not be turned off or disabled. From openssl source purpose checking is defined in openssl/crypto/x509v3/v3_purp.c as static X509_PURPOSE xstandard[] = { … }. The X509_PURPOSE_ANY check validation function returns 1.

The closest to official documentation on this flag is probably these posts by Dr Stephen N. Henson who authored v3_purp.c - http://marc.info/?l=openssl-users&m=96219426811480 and http://openssl.6102.n7.nabble.com/quot-critical-CA-FALSE-quot-but-quot-Any-Purpose-CA-Yes-quot-td29933.html.

To quote Steve:

'The "Any Purpose" setting is something which lets anything through and performs no checks at all. It was put there originally as a way for people to use broken certificates if they had no other choice and could live with the consequences... Since then CA checks have been made mandatory in the code even if "Any Purpose" is set. So if you actually tried to use that certificate as a CA it would be rejected.'

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: http://www.alvestrand.no/objectid/2.5.29.15.html [newly added values are 7 = encipherOnly and 8 = decipherOnly]

The trick is that this "OID=2.5.29.15 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"...

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.

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 2.5.29.32.0,
• CA:True 2.5.4.37,
• AnyPurpose 2.5.29.15,
• DigitalSignature 2.5.4.37.3,
• CRL Distribution Points 2.5.29.31,

On my intermediate TLS CA for Example I set:

• Web ServerAuth TLS 1.3.6.1.5.5.7.3.1,
• Web ClientAuth 1.3.6.1.5.5.7.3.2

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:

https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1.pdf

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

• Domain Validated 2.23.140.1.2.1
• Organization Validated 2.23.140.1.2.2

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

From: http://en.wikipedia.org/wiki/Digital_certificate

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

See the -purpose flag in the openssl docs: http://www.openssl.org/docs/apps/x509.html#CERTIFICATE_EXTENSIONS

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.

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.