Introduction
In most cases, we send and receive email with little concern about the messages being intercepted, manipulated and read by unauthorized persons. More often than not, the nature of the content does not warrant taking significant measures to protect the message. We may just want to tell a friend "Hey, take a look at this video".
In other cases, more commonly in the business world, we may be required to address three aspects of email security:
- Message Authentication: we want to ensure that the sender is the person they claim to be.
- Message Integrity: we want to ensure that the message has not been manipulated in transit.
- Message Confidentiality: we want to prevent unauthorized persons from viewing the message (and possibly associated content - essentially attachments).
We can acheive this goal with S/MIME, a standard for signing and encrypting email messages.
- Signing an email ensures both message authentication and message integrity.
- Encrypting an email ensures message confidentiality.
In some circumstances, we may want both: a message that is signed but not encrypted could be read by a third party.
Note: S/MIME is compatible with both Outlook and OWA in Exchange 2007 and 2010 (although with OWA, a "control" must be added). In Exchange 2015, support for S/MIME in OWA has been discontinued.
S/MIME uses certificates for signing and encrypting messages and certificates require a Public Key Infrastructure (PKI) to function. The organization wanting to use S/MIME can either install Active Directory Certificate Services (or an equivalent system) and create its own certificates or request them from a 3rd party provider such as Comodo, Digicert, GoDaddy or Verisign.
This choice does have consequences: internally issued certificates (by AD CS) will generally not be trusted outside the organization while certificates issued by a 3rd party provider will be trusted outside the organization.
So the use of S/MIME requires the following steps:
1. Creation of an appropriate certificate.
2. Distribution of the certificate to authorized users.
3. Configuration of Outlook or OWA for use of S/MIME
In this post, I'll address the first of those three steps.
Creation of an appropriate certificate
For this post, we will use AD CS to create the certificate. I have already configured the certificate authority (this pre-requisite is outside the scope of this post).
I will also assume that a custom MMC has been created with the following snap-ins:
- Certificates (Local Computer)
- Certificate Templates
- Certification Authority (Local)
Note: if this custom console is not already created, it can be by entering "mmc" in the Start | Search Box and opening as administrator. Using File | Add/Remove Snap-ins, add the snap-ins mentioned above, selecting "Local" or "Local Computer" whenever there is a choice. Save the console. Call it something appropriate such as "Certificate Management" or "Certificate Authority".
Next, go to the "Certificate Templates" snap-in.
Certificate templates are not issued directly to users and computers . The certificate administrator must "duplicate" one or more of the templates for distribution to users.
Which template should we use?
The "User" template comes to mind. It can be used for:
- Encrypting File System (EFS)
- Secure Email
- Client Authentication
However, I happened to read that Brian Komar, PKI expert and Microsoft MVP, does not consider that template to be the best choice and in fact recommends either "Exchange Signature Only" or "Exchange User".
Note: he even recommends a separate template for signing and encryption. "If your organization implements key archival of the e-mail cetificate, it is possible that another person could gain access to the private signing key associated with the e-mail certificate".
Sources:
Komar, Brian. Windows Server 2008 PKI and Certificate Security. Microsoft Press. Remond WA, 2008.
and...
Post started on Monday January 26th, 2009 by "Ploni Almony".
*
If we opt for dual certificates, this is how we could proceed:
- For signing, we should use: Exchange signature only
- For encryption, we should use: Exchange user
In our scenario, a single certificate seems the most appropriate. We will simply use the Exchange User template and enable both signing and encryption.
a. Right-click on "Exchange User" and select the option "Duplicate Template".
b. Select Windows 2003 Enterprise.
c. Configure properties of the new template.
There's a multitude of options here. We need to make the following changes.
General Tab
- I'll name the certificate "S-MIME"
- I'll leave the "Validity period" at 1 year with a "Renewal period" of 6 weeks.
- I'll have the certificate published in Active Directory.
Request Handling tab
Since we have opted for a single certificate, we have to change the "Purpose" parameter to "Signature and Encryption". The other settings can remain as is for our scenario. In reality, they would be configured in accordance with company policy (export of private key allowed or not, for example). Minimum key size of 2048 is certainly sufficient for our scenario.
Subject Name tab
Select the option "Build from Active Directory information". If autoenrollment is used, the user does not make a (manual) request and therefore cannot "Supply in the request".
Subject Name format should be: "Fully Distingushed Name".
Check the options:
- Include e-mail name in subject name.
I'll check the following option - although it is probably unnecessary since we checked the option above.
- Include this information in alternate subject name: E-mail name.
Security tab
We can allow autoenrollment in which the user automatically receives a certificate without having to request one manually, usually with Internet Explorer - or force each user to request the certificate manually.
We can create (in AD DS) a specific security group and only allow members of that group to request (and be granted) the certificate in question.
In this case, I will allow autoenrollment and in a later step, activate autoenrollment using a Group Policy setting. I will allow any authenticated domain member (user) to be granted a certificate based on the "S-MIME" template.
Check the following permissions for "Authenticated Users":
- Read (note: checked by default already)
- Enroll
- Autoenroll
I will not make changes under any of the other tabs. In particular, I will not configure any "Issuance Requirements" since we intend to use autoenrollment.
Click OK.
We now have a new template called "S-MIME".
We have almost finished but still have one more step.
The custom template has been created but is not available for users. In the MMC we created to manage certificates, we have to go to "Certification Authority (Local)" and expand the folder structure to the folder "Certificate Templates".
Click on this folder, select "New" and then "Certificate Template to Issue".
In the resulting window, highlight the "S-MIME" template we created earlier.
This makes the S-MIME certificate available to users.
However, although it is available, it has not been issued to anyone. We still need to configure autoenrollment (for our scenario) in conjunction with Group Policy. That will be the subject of my next post.
Thank you for reading the article about Exchange 2010 - Security - S/MIME. Part 1 on the blog NEW TECH If you want to disseminate this article on please list the link as the source, and if this article was helpful please bookmark this page in your web browser by pressing Ctrl + D on your keyboard keys.