Many of the security features that are built into Exchange Server rely on SSL. Understanding and implementing SSL concepts is required for proper Exchange infrastructure management.
SSL certificates are not new. When we buy something online, we frequently see the padlock icon in our browsers. This indicates that we're conducting our transactions over a secure, or SSL-enabled, connection that encrypts our data. Much of the functionality and many of the security features built into Microsoft Exchange Server 2003 and Exchange Server 2007 rely on SSL.
For example, Outlook Web Access (OWA), Outlook Anywhere, mobile devices and Macintosh computers are already configured to use SSL for basic security and functionality. Therefore, having knowledge of SSL concepts as well as the method to actually implement SSL has become a requirement for properly managing your infrastructure.
A trusted certificate is one that a recognized certification authority (CA), such as Verisign, Thawte, GoDaddy and others, has created. Windows Server includes the Certificate Services component, which creates certificates for use in SSL-enabled applications. These certificates, however, are not considered "trusted" certificates over the Internet.
In OWA, an untrusted certificate will not generally cause any technical problems. However, the browser will display a prompt asking if you really want to trust the certificate before proceeding to the logon screen. This isn't a major issue, but adds another step for users.
Untrusted certificates in other SSL-based applications can require some configuration and troubleshooting by IT administrators and end users. For example, it's necessary to import the certificate into the computer's Trusted Certificate Store before Outlook Anywhere will work properly. If you work on the help desk for an organization and your end users have any difficulties, then this can result in several unwarranted support calls.
To avoid this issue, u...
To continue reading for free, register below or login
To read more you must become a member of SearchExchange.com
se certificates that are only from trusted CAs. Each trusted CA has its own method to verify an organization's legitimacy before issuing a certificate. Ultimately, you must decide which one is the easiest and/or most affordable for your needs.
Although there are many trusted certificate authorities, including Verisign, Thawte and GoDaddy.com, the decision of which one to use is your own. There are three reasons, however, why I prefer to use GoDaddy.com for certificates.
- GoDaddy.com's certificates are relatively inexpensive.
- GoDaddy allows you to easily create multi-domain certificates. For example, you can issue a single certificate for a Web server that provides pages for YourDomain.com, YourDomain2.com and YourDomain.local.
- Most current browsers recognize GoDaddy.com as a trusted CA. The only downside I've found with GoDaddy.com is that part of its verification process involves automatically generating a message to the primary email address on record at your domain registrar. This won't work if that address is obfuscated. You will need to have access to the address, which sometimes can be a problem if you're providing support for another organization and don't have control of the domain.
How to obtain an SSL certificate
You usually have to follow a few distinct steps to acquire an SSL certificate. First, you must generate the Certificate Signing Request (CSR), which is simply a text file that contains encrypted information related to your organization and server. One way to create this file is to use the Certificate Creation Wizard in Internet Information Services (IIS), as shown in Figure 1.
[IMAGE]
Figure 1. Open theWeb Server CertificateWizard.
Then, follow these steps:
- In Windows Server 2003, open IIS and right-click on the desired website, typically Default Website, which is built into IIS.
- Select Properties and go into the Directory Security tab.
- Near the bottom of that screen, click on Server Certificate and create a new certificate. In the wizard, make sure you select the option to "Prepare the request now, but send it later." Enter all required data. This lets you create the text file that is the actual CSR (Figure 2).
[IMAGE]
Figure 2. Certificate Signing Request (CSR) text file.
- Sign on to the CA's website and order a Web server certificate. Part of this process involves copying and pasting the contents of the previously created CSR. Then the CA gives you the actual certificate, which you can download.
- Run through the IIS Wizard again. When you run through the IIS Wizard a second time, there will be an option to complete the certificate process. You will need to browse to the location where you downloaded the certificate from the CA.
Certificates in IIS and Exchange Server
Having a certificate in IIS does not guarantee that Exchange Server will "see" that it's there. There are a few steps you must take to easily manage Exchange Server, especially when helping end users remotely configure Outlook Anywhere (RPCover-HTTP/S) and when helping mobile users synchronize their devices. For Exchange Server 2003, bind the certificate to the SMTP server and to IMAP4 and POP3 virtual servers, if they are used. In Exchange System Manager, go into the Properties of each of these items and find the Access >> Certificate option.
Once the wizard starts, select the option to assign an existing certificate. Select the certificate that you just purchased and complete the wizard. This process is a bit different in Exchange Server 2007. In Exchange 2007, you must use Exchange Management Shell (EMS). After starting EMS, follow these steps:
- Use PowerShell to determine the thumbprint of the certificates on the server. Pipe those results to a text file at c:\certs.txt:
Get-ExchangeCertificate | fl | outfile –filePath c:\certs.txt
- Make note of the thumbprint of the appropriate certificate from the certs.txt file. For example, the thumbprint might be:
B52842F7408772B7151FF74FDAE
914EA7B59B53A
- To make the certificate usable from within IIS, paste the thumbprint into the following command all on one line:
Enable-ExchangeCertificate -Thumbprint <Thumbprint> -Services IIS
To continue with the previous example:
Enable-ExchangeCertificate -Thumbprint B52842F7408772B
7151FF74FDAE914EA7B59B53A - Services IIS
- To make the certificate usable from within SMTP, paste it into the following command:
Enable-ExchangeCertificate - Thumbprint <Thumbprint> -Services SMTP
For example:
Enable-ExchangeCertificate - Thumbprint B52842F7408772B
7151FF74FDAE914EA7B59B53A - Services SMTP
After completing these steps, your certificate should be installed and usable. Additionally, your users should be able to access various Exchange Server features without additional SSL prompts or warnings.
Note: Exchange Server 2007 PowerShell syntax was adapted from an article on The Ramblings on an Exchange Admin blog.
Do you have comments on this tip? Let us know.
About the author: Bradley Dinerman is founder and president of the National Information Security Group (NAISG) and president of Fieldbrook Solutions LLC. He is a Microsoft MVP in Enterprise Security, holds MCSE and MCP+I certificates, is a Certified SonicWall Security Administrator and a Certified
3Com IP Telephony Expert. He earned a Ph.D. in physics from Boston College. Brad served as technical editor on Configuring SonicWall Firewalls (Syngress Publishing, 2006) and co-authored Windows Server 2003Recipes (Apress, 2006). Visit Brad's Web page and TechTips site at http://brad.dinerman.com.
