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. http://www.microsoft.com/downloads/details.aspx?FamilyID=C16AE515-C8F4-47EF-A1E4-A8DCBACFF8E3&displa... 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:
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.cerThe 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." Troubleshooting 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:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.