In the past, if you wished to use S/MIME for e-mail encryption with an external recipient, you would add the recipient to your Contacts folder. This was typically done by having the recipient send you a digitally signed item and then right click on the recipient in the From field and click "Save to Contacts".
This solution was difficult for Helpdesk and Administration personnel to manage, as only the mailbox user (or someone logged on as the user) could modify the Contacts. Rather than a warning that the certificate in the contact had expired, the user would see somewhat cryptic error messages when attempting to send a signed/encrypted message. Having seen a growing interest from customers regarding how to decrease administrative overhead associated with handling these issues (Helpdesk tickets, etc.), customers have requested information regarding how to save a remote recipient's public key to an AD Contact, so that it can be updated once, and addressed in Outlook via the Global Address List (GAL).
A quick look at an AD contact vs. an AD user in Active Directory Users and Computers (ADUC) shows a vastly different experience with respect to certificates - there is essentially nothing exposed in the UI for the contact (on the left), while the user object has a rich certificate interface (on the right):
Fortunately, using a tool like LDP, we find that both types of objects contain the needed attributes to allow us to store certificates for use with Outlook and/or OWA.
The attribute that needs to contain the certificate is the userCertificate attribute, which exists for the object, but has no facility in the UI to load the certificate. Sounds like a job for Certutil.exe... This utility is part of Certificate Services in Windows Server 2003. It can also be downloaded here.
Certutil.exe is a command line tool that provides a way to manage certificates, particularly to add certificates to AD objects - like our contact. The syntax required is:
This assumes some prerequisites:
- The certificate needs to have an "E" value in its subject.
- The "E" value must match the SMTP address assigned to the contact.
- The certificate needs to be valid - (validity period, trusted, etc.), or issues will crop up later.
- The user sending the signed/encrypted email has their own valid certificate.
Executing the certutil syntax properly results in <ldp: Binary Blob> showing up in the userCertificate attribute if viewed from LDP. So far so good... Now all that remains is to open Outlook, create a new message, pick the newly "certified" contact from the GAL, set the message security options to encrypt, and the send the message. Again, provided that the user sending the message has their own certificate, this works like a champ, otherwise, they will see an error message indicating the sender doesn't have a valid certificate, and the message will have to be sent un-encrypted - more on this a little later.
Things are essentially the same if using an internal (ie. not trusted in popular browsers) CA. For our testing purposes, we used Windows 2003 Certificate Services, and issued certificates using the default "User" template. (Discussion of templates, their care and feeding, etc. are beyond the scope of this article, please refer to http://www.microsoft.com/windowsserver2003/technologies/pki/default.mspx as a good starting point)
The most common issue we encounter when using an "Internal" CA is that the CA is not trusted by either the client machine, the Exchange servers, or both. Opening a certificate on a machine that doesn't trust the CA will look as follows:
This condition is manifested in OWA and Outlook as well, but with a different message (please click to see a bigger version):
Once you have the certificate trust issue resolved, you'll see the following instead:
Steps to publish the S/MIME certificate to Active Directory:
1. Obtain the public certificate from the user and save it where certutil.exe is loaded.
2. Open the certificate and verify the subject name that it is issued to.
3. Create a new mail enabled contact in the Exchange Management Console.
4. Give it a matching E mail address as the subject name on the certificate.
5. Open a command prompt.
6. Run certutil -dspublish c:\path-to-user.cer
The utility will match the E= value to an item in Active Directory. If this is not found it will then try to match the distinguished name in the subject field to the distinguished name in Active Directory. If it does not find a match the operation will fail.
You can verify the command was successful with ADSIEdit (as well as LDP.exe). The certificate will be placed in the userCertificate attribute on the matching contact object. It will be populated as an Octet string, so it will not be in a readable format. This attribute is <not set> by default. To remove the certificate simply remove the value from this field.
In OWA, if you bring up the properties of the contact from the global address list, you will see the recipient has a valid digital ID for S/MIME - "Secure Messaging The Recipient has a valid Digital ID for encrypting e-mail messages."
So, you went through all the steps, and it still didn't work - got an error like the following:
Most often, this indicates that the recipients certificate was issued by a Root CA, and/or an Intermediate CA, that isn't trusted - obtain the Root certificate, and any intermediates, from the remote Organization, and install them on the appropriate computers:
From a workstation, you can just install the certificate using the Wizard. If you need to install it on a server, the best way to proceed is to Use the Certificates MMC to install the certificate, because you need to install it to the "Local Computer" account to trust CA. Go to Start > Run, type in MMC, and press Enter. Once the MMC opens, File > Add/Remove Snapin, Add the "Certificates" snapin... NOTE: choose the "Computer Account" radio button. Finish the wizard and you should see "Certificates (Local Computer)":
Drill down to Trusted Root Authorities > Certificates folder, right click and choose Import: Work through the wizard, specifying the file to import:
Once the wizard is complete, you should see the CA in the list. To be sure you are covered, it is best to repeat this for all Exchange servers in the Org for each CA Root certificate and/or Intermediate.
Now when you look at the cert, it should look like:
"But I can't get the certificate published using the tool!" - Make certain that the SMTP address configured in the certificate matches the AD contact. You should be able to publish even if the certificate is not trusted, although this isn't a good idea, as you will almost certainly run into the preceding error. Also note that if you try to publish a certificate into an AD contact that already has one, you will receive an error message indicating you can't overwrite the existing cert. Use ADSIEdit, or your favorite LDAP tool to remove the certificate and re-publish. Note: Be very careful when using tools like ADSIEdit, as they can cause significant damage if used incorrectly.
A word about Certificate handling in OWA versus Outlook - In order for this to work the user sending email has to have a valid certificate installed on the machine from which they are sending. This is because the Exchange security model requires a certificate for both parties when sending signed/encrypted email (http://technet.microsoft.com/en-us/library/aa997737.aspx). OWA will detect the presence of the user's certificate, and perform the appropriate operation assuming:
- The certificates are issued for the intended purpose
- There aren't multiple certificates for the user in the certificate database
- The first one in the list is expired or otherwise invalid. OWA uses the first cert in the list, even if it is no good.
Hopefully, the user has only one private key for decrypting messages, so this doesn't become a problem. If the user has several private keys, each one will need to be installed on the workstation where they are accessing their mailbox for the body of messages they need to decrypt.
OWA will also handle the scenario where one certificate is issued for Encryption, and another is issued for Digital Signing. It determines which to use based on the values in the "Key Usage" attribute on the certificate:
Outlook, on the other hand implements handling of multiple S/MIME certificates Settings, where the user can choose a certificate to be the default for signing/encrypting. The user can create a message to be sent to a user, and choose the certificate they wish for Outlook to refer to for Exchange Security purposes. This can be changed at any time by the user, and should work provided that they don't select an invalid cert. (http://office.microsoft.com/en-us/outlook/HP012305371033.aspx - Get a Digital ID: provides info on configuring certificates in the Trust Center)
Note: The examples in this article were conducted using Exchange/OWA/Outlook 2007, using Windows 2003 AD and CA. You should see similar behavior from Exchange/OWA/Outlook 2003, but your experience may vary, particularly with diagnostic messages. We strongly recommend that you test this process extensively in your labs to make sure that it gives you the functionality that you expect.
http://msexchangeteam.com/archive/2007/08/20/446760.aspx - Secure Messaging with S/MIME and OWA on Exchange Server 2007 SP1
http://msexchangeteam.com/archive/2005/01/14/353167.aspx - Common Trust, Encryption and Digital ID Troubleshooting - for Microsoft Outlook and Microsoft Exchange users
http://office.microsoft.com/en-us/outlook/CH100622191033.aspx - Security and privacy for Outlook 2007 How to