Friday, July 5, 2013

Exchange 2010 - Security - S/MIME. Part 3

Part 3: using S/MIME to sign and encrypt email.
Now that we have the foundations in place, let's use S/MIME to sign and encrypt email.
We can use S/MIME...
  • to sign specific messages (the user must choose - and remember to use S/MIME).
  • to sign all messages (by default).
The same is true for encryption. Indeed, we may have no need to encrypt all messages. Remember the example of the "Hey, look at this video" email mentioned in the introduction?
First, let's see how to sign a particular email. I'll use Outlook 2010 in this example. There will be some differences in Outlook 2007 and 2013, not to mention obvious differences if you are using a non-Microsoft mail client.
In our example, Alex Heyne will send an encrypted email to Alan Reid.
1. Starting on the "Home" tab, click on "New Email".
2. Click on the "Options" tab and then the "More options" arrow as indicated in the illustration:
3. Click on "Security Settings" and then check the option "Add digital signature to this message".
The option "Send this message as clear text signed" is selected automatically. Optionally, you can request a S/MIME receipt.
How can we determine if a message was signed after sending?
There will be a small seal symbol "stamped" on the envelop icon representing the message:
If we open the message, there is also a small icon (indicated below, below the three red dots). By clicking on the small icon, details about the certificate are displayed:
This seal or certificate icon appears on the recipient side as well.
I will not provide a screenshot of every step of the procedure but Alan Reid receives the message and can respond (even without using S/MIME).
Note: in this scenario, the users only have one certificate suitable for signing or encrypting email. If there were more than one suitable certificate, the user would have to select the best or preferred certificate as shown below:
Note that one can also select the encryption algorithm which, in Outlook 2010, is AES 256 by default and check the box "Send these certificates with signed messages". This option is checked by default and important to the extent that recipients need the senders certificate to decrypt encrypted messages (the certificate includes the sender's public key.)
What if I want to make signed messages my default? What if I prefer not to have to perform the steps outlined above for every single email I send (and assuming I want to sign them all, or most of them)?
Message signing by default can be configured here:
Outlook Options | Trust Center | E-mail Security | Encrypted Email
What about OWA?
If we want S/MIME to function with OWA, we have to install the "S/MIME control". Otherwise, we'll see a warning like this:
We have to navigate to this location in OWA:
Options | Settings | S/MIME
We'll be prompted to "run or save owasmime.msi". We'll select run (you may have to select run again after the security check).
Note: administrator credentials are required to install the control. Moreover, users may see the message below (This webpage wants to run the following add-on: MIME Edit Binary Behaviour, etc.).
Once the control is installed, OWA can validate signed messages. The signed message displays as follows:
The sender can send a signed message to anyone provided the recipient trusts the certificate authority that issued the sender's certificate (this is usually not the case for recipients outside the organization unless they import the certificate authority's root certificate - and preferably published in Active Directory where each user can access it without having to import it into their certificate store manually).
Encryption is more complex.
Some general remarks about encryption
The sender must have access to the recipient's public key. The sender can then encrypt the message so that only the recipient can decrypt it. That is how assymetrical encryption functions:
A message encrypted with the public key can only be decrypted with the private key.
Since only the recipient has (or should have) the private key, no one else can decrypt the message, even if they, too, have access to the recipient's public key.
It does not matter: the public key cannot decrypt what is encrypted with the public key.
This clarification is important!
The sender does not encrypt the message with their private key since anyone with the public key could decrypt it.
A more detailed presentation of assymetrical encryption is outside the scope of this blog post. However, we should retain the fact that this type of encryption requires that the recipient's public key be made available to potential senders.
There are several means to achieve this objective.
In older versions of Exchange, the certificate (which contains the public key) could be published to the Global Address List (GAL). Today, there are other methods.
If "A" wishes to send an encrypted message to "B", "B" can send a signed email to "A". This email will include B's public key. If "A" opens the message, selects B's name, and selects the option "Add to Outlook contacts", the certificate should be included - and available for future messages, notably encrypted messages.
However, the best method to make certificates (and public keys) available is to publish them to Active Directory. This happens automatically if the "Publish certificate in Active Directory" option is selected when creating the certificate template. This was presented in Part 1 but here's that setting again:
How to send an encrypted email
You can send an encrypted email by following the same procedure for signed email as described above, except that you select the option for encryption (selecting both in an possibility as well):
It seems that once the user has signed or encrypted a message, Outlook 2010 adds specific icons for these operations which allows the user to select "Options" and then either "Encrypt" or "Sign".


  1. Thank you for the series, how does encryption work if users need to view the message on multiple computers. If auto-enrollment is on, they request multiple certificates...does it just work?

  2. Hi Miha,

    I've been really busy with many things recently, technical and non-technical, so I did not see this comment until now.

    Short answer: if autoenrollment is used, the user will obtain a certificate for each computer that they use. So yes, it "just works".

    In fact, this may cause problems:

    If there are many users logging on to many computers, that can cause "bloat" of the CA database (make it larger than we would prefer).

    Each certificate functions with its own public/private key pair. If the user does not have all the private keys available on a particular computer, they might not be able to decrypt messages encrypted with a public key associated with a private key only available on a computer elsewhere.

    We can use "Credential Roaming services" to alleviate this problem. In one sentence, we can say that "CRS" stores the certificates as attributes of the user's Active Directory account. These certificates are installed on the client machine even before autoenrollment takes place - and thus avoids multiple certificates on multiple computers.