X.509 v3 Certificate Extensions

X.509 version 3 certificates have available a dizzying array of possible extensions to the base certificate. It has taken me years to even begin to wrap my head around these items, and i still haven’t mastered them! Apparently, no one really has^[1]. This may be due to even the experts disagreeing upon the precise meaning and use of many of them! (Here’s one example from the ietf-pkix mailing list, and there are others elsewhere in that same message thread.)

Here is my best attempt at explaining them.

Extensions? Why?

In general, the extensions restrict and/or more precisely define what a certificate can and cannot do, rather than adding any abilities not already there. Apple OS X/macOS systems all the way up through OS 10.11 El Capitan treat “undefined” certificates (those without extensions) as having any possible ability ascribed to the particular class of certificate (e.g. self-signed root, the type we’re dealing with). Other systems may or may not handle these certificates this way—that’s the meaning of “undefined”, after all.

Extension groups may be marked as “critical”. In theory, this means that these settings MUST be respected. In practice, the “critical” flag is often ignored.

Key Usage Extension—KUE

The Key Usage Extension appears to have been the first extension to X.509 certificates. Starting with Leopard 10.5, Certificate Assistant defaults to including this extension and marking it as critical. All well and good, but Apple forgot to check the Key Encipherment box. Which is why failing to override defaults leads to nonfunctional certificates!

Signature

The certificate may be used for digital signing. Required for S/MIME, if this extension is used.

Non Repudiation

In theory, makes it not possible to repudiate (deny) that a digital signature made with this certificate was yours.

Key Encipherment

The certificate may be used to encipher (encrypt) security keys. Required for S/MIME, if this extension is used. Key encipherment is what is used to encrypt email messages in S/MIME.

It may be possible to omit this item in a KUE and override it on Leopard and later, but it won’t interoperate with Tiger systems. Since Sierra and possibly newer macOS systems require the KUE for S/MIME in Mail, it’s best to include the KUE extension and be sure that this item is selected.

Data Encipherment

One might think that this setting would be necessary to encrypt the content of email messages… one would be wrong! Experts love to disagree over the exact meaning of this setting, so i’m not even going to try to explain its use. One expert even claims that invoking this setting introduces a security hole!

Key Agreement

Related to using the public key for key agreement as part of key management. I don’t understand this and it has nothing to do with S/MIME.

Certificate Signing

The certificate may be used to sign other certificates, in a chain of authority.

CRL Signing

Set when the public key in the certificate will be used to verify the signature on a Certificate Revocation List.

Encipher Only and Decipher Only

These have no meaning unless the Key Agreement bit is set. When Encipher Only and Key Agreement are both set, the pubic key in the certificate may only be used for enciphering data while performing key agreement. Decipher Only works the same way.

The least worst precise, technical description i’ve found for the Key Usage Extension is on the citrixblogger site.

Extended Key Usage Extension—EKUE

This seems to be the second attempt at making certificates better defined and useful. It appears starting with OS 10.5 Leopard—it does not exist in Certificate Assistant for OS 10.4 Tiger. Fortunately, Apple’s defaults for this extension are correct and workable for S/MIME.

Any

Literally means what it says. It is unclear what actually happens if this item is selected and others are as well.

.Mac (or MobileMe on Lion and later) Email Signing and Encryption

I don’t truly know why these options are separate from Email Protection, but they are. Not relevant unless you’re using this service of Apple’s (by whatever name it currently goes).

Email Protection

This is the one and only item to check for S/MIME secure email (when not using a mac.com etc. email account from Apple).

Code Signing

Software developers use this setting to enable their certificates to be used to sign (authenticate) their software programs. Becoming important with OS 10.7 and newer. People who are not software developers will not need this setting.

everything else

They pretty much mean what they say… or i can’t be bothered to look up the meaning, as they’re not relevant to S/MIME.

Basic Constraints Extension

This one is important for a Certificate Authority (CA). It is unclear (there is debate amongst experts) whether or not it is needed for self-signed certificates. I found that it didn’t ever seem to improve anything in my testing, so i left it disabled. If you find that your certificate is not being accepted by other (non-Apple) software, you may want to try including the Basic Constraints Extension and selecting “Use this certificate as a certificate authority”. I found that doing this or not doing this made no difference in my testing.

Subject Alternate Name Extension—SANE

This extension is not necessary, though Apple likes to include it by default on OSes newer than Tiger. The purpose of this extension is somewhat buried in the arcanery of the X.509 world… the basic idea is that the original X.509 certificate arrangement had no placeholder for email addresses and other Internet-related information fields. People created them ad-hoc, and eventually (and belatedly), the standards-makers added SANE to officially hold these items of information. It is not required for Apple software/systems, to date (see Last Modified date, upper left corner of the main article page).

If it is included, the rfc822Name field must be filled out with the same exact email address entered earlier under Certificate Information. Certificate Assistant does this automatically (nearly all the time, but not 100% of the time). The other fields do not need to be filled out. Apple’s default is to mark this as not critical… i figure they know something we don’t, so i suggest following their lead.

Suggestions?

If you have a better/clearer/more accurate explanation which can be understood by public key cryptography lay people such as myself, i’ll be quite interested in your suggestions and corrections. If your corrections regard technical details of the type discussed on this page, i’ll only consider implementing your corrections if you present them in terms easily understood by a reasonably intelligent non-security-expert computer user (and i’m the reference case for what is/is not understood).

Return to where you were in the main article (or use your browser’s Back button)