Applications Server

Exchange Server 2010 : Planning Certificates for Autodiscover (part 2) - Deploying Exchange Certificates

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
9/22/2011 3:45:35 PM

2. Deploying Exchange Certificates

Now that we've talked about certificates in general, let's dive into the issues of getting them deployed on your Exchange 2010 servers.

2.1. Planning Certificate Names

The first part of creating digital certificates for your Exchange 2010 servers is deciding on which names you need. For a Client Access server, it's highly recommended that you accept the need for a SAN certificate. Although SAN certificates are more expensive than single-name certificates, you can often configure them so that you can reuse them on multiple servers. Otherwise, you need to use a lot of single-name certificates—possibly with multiple websites and virtual directories on your CAS instances. And since HTTPS requires a dedicated IP address for each hostname, this can become an overwhelming amount of operational overhead.

Sure, you can use wildcard certificates for some scenarios such as Outlook and Windows Mobile 6.0 and later. The wildcard certificate is a certificate that is issued for an entire domain, such as * This certificate could then be used by multiple servers and sites. Naturally, wildcard certificates are usually more expensive than certificates issued for a single host. Be aware, also, that not all clients (such as Windows Mobile 5 and earlier) will recognize wildcard certificates.

Figure 3. Viewing a certificate trust chain

Let's take the three-site example  and some of the factors to consider when requesting certificates:

  • We've already established that we don't want Seattle clients using New Orleans Client Access servers and vice versa, so for Internet connectivity, the Toledo site makes sense as the gateway to the Internet. This will need the domain name

  • We'll use the domain name as our generic external access domain name. We don't need to use a separate domain name for this—we could easily use, but users are accustomed to an easier-to-understand domain name.

  • Having two domain names means either multiple IP addresses and websites or a SAN certificate. We don't want to incur the overhead of multiple certificates and websites, so we will use a SAN certificate; we can issue a single certificate for all the Client Access servers in the Toledo site. We'll include the FQDNs of each of the servers, bringing our total number of names to four. Most commercial CAs have a price increase after five domain names on a SAN certificate, so we're within our limit. But always consider all the places you may want to use a certificate such as on Hub Transport servers for SMTP.

Our certificate will therefore need four domain names:,,, and We don't need to include the NetBIOS names of our servers—Exchange and its clients don't use them unless we choose to configure them otherwise.

It is important to note as you start requesting certificates that poor namespace planning or separate internal namespaces (such as for external clients but somorita.local for internal clients) will result in more complex certificate requirements. If possible, ensure that you have carefully thought out the internal and external URL requirements as you are planning your Exchange Server 2010 deployment.

2.2. Issuing and Enabling Certificates with EMC

In Exchange 2007, you had to do all your certificate requests and imports either through the Certificate MMC snap-in (which was a pain) or through the EMS. In Exchange 2010, if you click on the Server Configuration node in the EMC, you can view, manage, and even request new certificates for your Exchange 2010 servers. Figure 4 shows the tasks that are available in the Actions pane for the server HNLEX05 (selected in the Results pane) as well as for a specific certificate that is selected in the Work pane).

Figure 4. Certificate options available in the EMC

Note that you cannot use this tool to handle certificates for any Exchange 2007 servers you may have in your organization; certificate handling typically must be done on the server. This interface is the only Windows-based certificate management tool we have seen that allows creation and management of certificates on remote Exchange Server 2010 servers—all thanks to the magic of Remote PowerShell. To create a new certificate, you use the New Exchange Certificate wizard; when you launch this wizard, you will first be asked on the Introduction page for a friendly name for the certificate. While this name can be anything, we recommend you name it something that describes the use of the certificate.

On the Domain Scope page of the wizard, you need to specify the scope of the certificate, such as if it should be enabled for all subdomains. This is sometimes called a wildcard certificate; your certificate issuer must support wild card certificates. Wild card certificates can be considerably more expensive than single-name certificates.

On the Exchange Configuration page of the wizard, you will see the different types of services that you can enable for a certificate (such as OWA, ActiveSync, SMTP, etc.) From this page of the wizard, you can enter the names as fully qualified domain names of the services.

Note in Figure 5 that this server's internal OWA name is and the external name is For some of these fields, the New Exchange Certificate wizard is making a "best guess" at the correct names, but you will need to fill in some of the others manually. The fields that are populated on the Exchange Configuration page are the ones that will appear in the certificates subject alternate name field.

In Figure 6, you can see the Certificate Domains page; this page allows you to specify additional fully qualified domain names that will show up in the certificate request. The wizard is making another "best guess" for this certificate request by adding all of the accepted domains as well as adding the host name autodiscover to each of these domain names.

Figure 5. Viewing the Exchange Configuration page of the New Exchange Certificate wizard

Figure 6. The Certificate Domains wizard page

The Organization and Location page of the wizard (shown in Figure 7) is requesting information that most administrators who have configured a certificate request before will recognize. This includes the organization information, department, city, state, and country. At the bottom of the Organization and Location page you must provide a name and path where the certificate request file will be created.

Figure 7. Specifying organization, department, city, and country information for a certificate request

The Certificate Configuration page allows you to review the information about the certificate request that you are generating prior to actually creating the request. Once you are sure that the certificate request is correct, you can click the New button to actually generate the request and store it in the certificate request file.

Like all EMC wizards, the Completion page of the wizard will include the actual EMS command that was executed in order to generate the certificate request. Here is the EMS command that was generated for this particular example:

New-ExchangeCertificate -FriendlyName '' 

-GenerateRequest -PrivateKeyExportable $true -KeySize '2048'

-SubjectName 'C=US,S="Hawaii",L="Honolulu",O="Volcano

Surfboards",OU="IT Department",'

-DomainName '',








'','' -Server 'HNLEX05'

You can now take the contents of the file that was created and submit it to a certificate authority to issue the certificate. Once you have received back a signed certificate, you use the Complete Pending Request wizard to complete the process. This wizard will load the signed certificate in to the certificate store on the appropriate server.

The final process after the certificate is fully loaded is to assign the certificate to be used by the appropriate services (such as SMTP or IIS). Select the certificate in the work pane and then select the Assign Services to Certificate wizard. On the Select Services page of the wizard (shown in Figure 8) select the appropriate services. When you select Internet Information Services, that includes OWA, the Exchange Control Panel (ECP), Exchange Web Services (EWS), and ActiveSync. Note that a service can only be assigned to one certificate at a time.

Figure 8. Selecting services that will use the certificate

The only other note of caution we give you is that whichever tool you use to request certificates should be the tool you use to import them. Although you should be able to mix and match them in theory, we've seen odd results. Also, don't use the certificate wizard in IIS to request Exchange certificates, especially if you need SAN certificates.

2.3. Issuing and Enabling Certificates with EMS

Although Exchange 2010 provides an Exchange Management Console interface for managing certificates, you can still manage certificates in Exchange 2010 (and 2007) through the EMS. If you have done this in the past with Exchange Server 2007, you will have to learn a few new tricks in order to work with certificates from the EMS. Due to the remote PowerShell, you can no longer specify a path for certificate request file. Instead, the certificate request is output to the shell, so you must capture that to a variable. Here's the command you would issue to generate a certificate request for the URL and capture it to the $Data variable:

$Data = New-ExchangeCertificate -GenerateRequest -SubjectName "c=US, 

o=Somorita Surfboards," -DomainName

–PrivateKeyExportable $true

Next we need to take the value stored in the $Data variable and output that to the file c:\CertRequest.req using this command:

Set-Content -path "C:\Docs\MyCertRequest.req" -Value $Data

Here are the details of the New-ExchangeCertificate cmdlet command:


This parameter tells Exchange to generate a certificate request. Had we left it off, the command would have generated a new self-signed certificate. That's usually not what you want. This request is suitable for either an internal PKI or a commercial CA.


This parameter is extremely important and is the cause of most certificate headaches we've seen. When a certificate request is generated, it includes the public key, but the private key stays in the secure Windows certificate store. If the CA is configured to allow export of the private key, the request must explicitly ask for the private to be exportable. If this parameter wasn't included or was set to $false, we wouldn't be able to export the certificate's private key to import to the other Toledo CAS instance, or on to the external firewall.


This parameter is set for administrative convenience. If we have multiple certificates issued to the machine, it allows us to identify which certificate we're dealing with.


This parameter allows us to set one or more domain names. If we specify more than one, Exchange will automatically create and populate the SAN property with all the requested hostnames and set the subject name of the certificate to the first hostname in the list. Although the cmdlet provides additional parameters to explicitly set the subject and alternate names, you don't need them.

A successful run of the cmdlet will generate the request output and a thumbprint of the request. Submit the request to your CA, download the corresponding certificate, and then import the certificate back on the same machine:

Import-ExchangeCertificate -FileData $(Get-Content 

-Path c:\ \CertImport.pfx -Encoding byte)


This cmdlet will import the saved certificate if it matches a pending request, and print out the thumbprint of the newly imported certificate. You can now view the certificate in MMC or from the certificate management functionality in the Exchange Server 2010 Management Console.

The final step is to enable Exchange services against the certificate:

Enable-ExchangeCertificate -Thumbprint <certificate thumbprint> 

-Services <services>

<services> is a comma-separated list of one or more of the following values, depending on the protocols you have enabled and the roles you have installed:


For use with SMTP + TLS on Hub Transport and Edge Transport servers


For use with Unified Messaging servers


For use with Client Access servers, including Autodiscover


For use with Client Access servers that are serving the IMAP client protocol


For use with Client Access servers that are serving the POP3 client protocol

Other -----------------
- Exchange Server 2010 Autodiscover : Autodiscover Concepts
- Active Directory 2008 : Proactive Directory Maintenance and Data Store Protection (part 5) - Protecting DCs as Virtual Machines
- Active Directory 2008 : Proactive Directory Maintenance and Data Store Protection (part 4) - Performing Proactive Restores
- Active Directory 2008 : Proactive Directory Maintenance and Data Store Protection (part 3) - Relying on Windows Server Backup to Protect the Directory
- Active Directory 2008 : Proactive Directory Maintenance and Data Store Protection (part 2) - Relying on Built-in Directory Protection Measures
- Active Directory 2008 : Proactive Directory Maintenance and Data Store Protection (part 1) - Twelve Categories of AD DS Administration
- BizTalk 2009 : The BizTalk Management Database
- BizTalk 2009 : Handling Failed Messages and Errors
- Microsoft Dynamics GP 2010 : Dynamics GP Utilities (part 3) - Additional steps
- Microsoft Dynamics GP 2010 : Dynamics GP Utilities (part 2) - Loading sample company data & Creating a new Dynamics GP company
- Microsoft Dynamics GP 2010 : Dynamics GP Utilities (part 1) - Completing the Dynamics GP installation
- Microsoft Dynamics GP 2010 : Creating an ODBC data source
- Microsoft Dynamics AX 2009 : Working with Forms - Storing last form values
- Microsoft Dynamics AX 2009 : Creating modal forms & Changing common form appearance
- Exchange Server 2010 : Performing Tracking and Logging Activities in an Organization (part 2) - Using Protocol Logging & Using Connectivity Logging
- Exchange Server 2010 : Performing Tracking and Logging Activities in an Organization (part 1) - Using Message Tracking
- Exchange Server 2010 Maintenance, Monitoring, and Queuing : Understanding Troubleshooting Basics
- Extending Microsoft Dynamics CRM 4.0 : Examples
- Extending Microsoft Dynamics CRM 4.0 : IFrames
- BizTalk 2009 : Using XML Namespaces (part 3) - Using System Property Schemas
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us