Analogously to the SSL server certificate question, which extensions should I use for S/MIME, and should the CA be restricted somehow as well?

(I'm using openssl, which at the moment creates CA and certificates with permission to do basically everything)

2 Answers 2


There are details spelled out in RFC 3850. In practice:

  • It is highly recommended to include your email address in your certificate, in a Subject Alt Name extension (or possibly as an extra attribute in the subjectDN but this is deprecated). If the certificate does not contain the email address, your correspondents will have to find another way to associate the certificate with your email address, and most software will have trouble with that (this is meant to be supported, but it will make things difficult for other people).

  • If your certificate usage is restricted with a Key Usage extension, then digitalSignature and/or nonRepudiation must be allowed explicitly in that extension.

  • If the certificate contains an Extended Key Usage extension, then it must contain either the id-kp-emailProtection OID ( or the special all-purpose anyExtendedKeyUsage OID (

  • If the certificate is a signature-only certificate (it contains a DSA or (EC)DSA key, or is restricted through Key Usage), then email encryption will be hard. There is (was ?) a mechanism in which your software generates a Diffie-Hellman key pair, and attaches the public key to the signed emails you send, allowing recipients to encrypt their responses. This is, at best, ill-supported in the wild, and it adds some extra issues (such as storage of the extra DH private key). Therefore you'd better use a certificate which is encryption-able (RSA key, and not restricted with a Key Usage extension).

  • Theoretically you could have two certificates, one for email encryption and one for email signatures; this would be a good idea. But support might be found a bit wanting in that area. Some testing is required.

There were some Netscape-specific extensions in older times, which were needed for proper usage by Netscape Communicator, but who runs that nowadays ?

  • 1
    Does S/MIME support subkeys like PGP does? Or would splitting signing and encryption require two separate certificates? If only PGP/MIME were supported better... Feb 5, 2013 at 16:48
  • S/MIME does not support subkeys per se, since a "subkey" would be a sub-certificate, and that requires a CA. In the PGP model, everybody is a CA, but not in X.509. The mechanism with a DH key pair signed with your certificate exists in my memory, but I cannot find it elsewhere so I might have imagined it; it could be used as a kind of subkey. In practice, you will need two certificates if you want separate encryption/signature keys. Feb 5, 2013 at 17:33
  • Hm, another reason to prefer PGP/MIME... So, is there any reason to prefer S/MIME? Feb 6, 2013 at 7:37
  • 1
    FYI: The properties my free startssl.com certificate uses are digitalSignature, dataEncipherment, keyEncipherment (I'm not sure which encipherment is actually needed for S/MIME) and in the extensions id_kp_emailProtection ( (you also mentioned it) and id_kp_client_Auth (, the latter is for the SSL login on their website. The only Netscape extensions are in the root certificate from 2006, while the intermediate one from 2007 dropped them. I think I read Netscape won't support 2048bit keys, so ns support should be dropped entirely anyway Feb 6, 2013 at 7:48
  • 1
    If your certificate is used for e-mail encryption, you must also include key encipherment in the key usage section, because in S/MIME enveloping, a fast (symmetric) key is encrypted with the public key from the certificate.
    – not2savvy
    Nov 17, 2017 at 14:57

After much research, I've finally determined the following rules of how to properly set an S/MIME certificate's properties, which may be useful:

Key Usage



Recommended: YES

This extension may be critical or non-critical, but PKIX Part 1 recommends that it should be marked critical if it is used.


  • to allow key usage for encryption: keyEncipherment
  • to allow key usage for signing: use digitalSignature

Include both keys to allow key usage for both purposes.


The extension is used to limit the usage of a key; if the extension is either not present or non-critical, all types of usage are allowed.

It is usually recommended to use different certificates for signing and encrypting, so the encryption key can be deposited, for example to be able to decrypt an employee's messages after they have left the company.

Extended Key Usage



Recommended: NO

If this extension is marked critical, the certificate must be used for one of the indicated purposes only. If it is not marked critical, it is treated as an advisory field that may be used to identify keys but does not restrict the use of the certificate to the indicated purposes.


Email (


I've found that most S/MIME certificates use NO in this field. That's probably because it is not really critical to restrict the usage to email.

Subject Alternate Name



Usually NO

Email addresses may be provided in the Subject Alternative Name extension, the certificate subject name field, or both. However, if the certificate's subject field is empty, this extension must be marked critical=YES.


1..n additional email addresses, separated by a space character


Software that supports S/MIME must be able to read an email address from either the Subject Alternative Name extension or from the subject name field. However, it is recommended to repeat the email address in the Subject Alternative Name in this field.



You must log in to answer this question.

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