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)


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 '13 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 '13 at 17:33
  • Hm, another reason to prefer PGP/MIME... So, is there any reason to prefer S/MIME? Feb 6 '13 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 '13 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 '17 at 14:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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