What is the difference between the Encryption certificate and Verification certificate in Outlook? When exchanging certs, it just requires a digitally-signed message to be sent. It seems as though the encryption cert is never really handled, just the other person's public key and your own private verification certificate. So, what is the purpose of the encryption cert in Outlook?

  • Can you clarify your question? Which version of Outlook are you using? I can't find anyplace that specifies a difference between an Encryption and a Verification certificate. Jan 3, 2013 at 15:54
  • I'm using Outlook 2010, but my question is more practical than technical. What I am mainly concerned with is what the encryption cert even does, since it is the verification cert that is used to send the digitally signed email, which is all that is really needed to exchange encrypted messages with folks.
    – Jason Es
    Jan 3, 2013 at 16:03
  • Sorry, I'm still not understanding what you are asking. I can't find anyplace in Outlook 2010 that indicates a difference between an Encryption certificate and a Verification certificate. Where are you seeing this distinction? Jan 3, 2013 at 16:37
  • File > Options > Trust Center > Trust Center Settings > E-mail security > Encrypted email settings. Here you can select which signing and encryption certificate to use, as well as the algorithms. My questions wasn't really a technical issue with Outlook itself, but more of a conceptual issue on what each certificate does in the role of S/MIME message exchange.
    – Jason Es
    Jan 3, 2013 at 17:19

2 Answers 2


Your terminology looks weird, but here are some explanations which are likely to be relevant to your question:

When doing "secure" emailing with S/MIME, you actually use two distinct features:

  • Email encryption: emails sent to a recipient R are encrypted, i.e. made unreadable for everybody, except for R, who can reverse the encryption process. R can do that because the encryption is done using R's public key, and R knows the corresponding private key (public and private key are mathematically linked together, but only the public part is made public).

  • Email signature: emails sent by a sender S are signed, i.e. S adds to the email (usually as an "attached file") a value (the signature) which is specific to the email contents and can be computed by S alone; but everybody can verify that the signature matches the email. Computing the signature uses S's private key, but verification is done with S's public key.

In a full-featured emailing system, every user thus has a private key for signatures, and a private key for encryption. You use your private key for signatures when you send an email (to sign it) and you use your private key for encryption when you receive an email (to decrypt incoming emails). Either way, the people you exchange emails with must know your public key(s) with some certainty, so public keys are distributed through digital certificates. A certificate is a container for a name and a public key, bound together in a compact packet which is signed by a certification authority.

Depending on your key type, what is written in the corresponding certificate, and some policy choices, your key for signatures and your key for encryption may or may not be the same (even when it is technologically possible to use the same key for both usages, there are good reasons to keep them apart from each other). With S/MIME, you mostly have the three following situations:

  1. Your signature key and your encryption key are the same (of type RSA). You have one certificate for your one public key. (That's the most common case.)

  2. You have two distinct keys for signatures and for encryption; each public key is distributed in its own certificate.

  3. You have a key for signatures, and the public key is in a certificate signed by a regular CA. For encryption, you have another key pair, where the public key is not stored in a certificate signed by a CA; instead, it is distributed as an SMIMECapabilities object which is added to the signed messages you send (and it is then part of what you sign). In effect, you are then acting as your own CA when publishing your encryption public key.

Regardless of how many keys and certificates you have, you send it all when you send a signed message: this means that every signed message that you send contains everything that recipient must know if they want to send encrypted messages to you. For instance, the certificate which contains your public encryption key (if such a certificate exists in your case) will be added into the signature object that your mailer agent (Outlook) adds to your outgoing emails. Therefore, it is customary to initiate a secure email conversation with some other user B by sending him a signed email.

In integrated environments, certificates and/or SMIMECapabilities objects can also be distributed through other means, such as LDAP servers (aka "Active Directory" in Microsoft terminology).

  • Thanks a lot - and my apologies for using weird terminology. This really helped my understanding of the different certs.
    – Jason Es
    Jan 3, 2013 at 17:19

With Certificate based (Public/Private key or Asymmetric) cryptography, a certificate is comprised of a public key that can be shared with anyone. It may also be signed by a trusted third party, such as a certificate authority, to attest that the private key that corresponds to the public key in the certificate is held by the individual the certificate claims to be for.

When a user wants to sign a message, they generate a small piece of information called a hash which can be used to verify that nothing in the message changed. They then encrypt this hash with their private key. The recipient can then use the public key to decrypt the hash and if the contents of the file match the hash, then they know nothing has changed since only the individual with the private key that corresponds to the certificate could have encrypted the hash value and if anyone had changed the message, the hash would be different. This is called a signature since it attests that the message arrived from the sender and was not altered by a third party.

Encryption is when the message is encrypted and the key used for decryption is encrypted with the recipient's public key. Information encrypted with the public key can only be decrypted with the private key and thus nobody other than the holder of the private key can get access to the encryption key needed to access the contents of the message.

These are both based on the fact that asymmetric cryptography makes it so that anything encrypted with the public key can only be decrypted with the private key and anything encrypted with the private key can only be decrypted with the public key.

The only thing I can think of that you might be seeing is information about the certificate involved in signing a particular message (ie, the certificate of the sender) and information about the certificate used for encrypting the message (ie, the certificate of the recipient). You could potentially end up with both if a message is both signed by the sender and encrypted for the recipient.

You must log in to answer this question.

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