Creating, Installing, Enabling and Configuring Exchange 2007 and Exchange 2010 Certificates (**Updated for Wildcard and Exchange 2013)
Published:
Browse All Articles > Creating, Installing, Enabling and Configuring Exchange 2007 and Exchange 2010 Certificates (**Updated for Wildcard and Exchange 2013)
Overview
Unlike Exchange 2003, by default Exchange 2007 Servers and above are automatically configured with a self-signed certificate enabled for SSL upon installation. This certificate is a requirement for Exchange to work properly in most aspects and you’re better off replacing the self generated certificate with a certificate from a trusted certificate authority - if you intend for devices from outside your domain to enjoy seemless connectivity via ActiveSync, Autodiscover, Outlook Anywhere.... These certificates used to be extremely expensive and these days you can get them dirt cheap, in comparison, from a CA like Godaddy or Digicert. SSL is a requirement for Outlook Anywhere and Autodiscover so you may as well save yourself the hassle and buy a legit certificate so your Exchange Server will work at it's most efficient level. If you have no intention of allowing external access and don't mind suffering over certificates on mobile devices you can always setup an internal CA with a wildcard or SAN cert for free but I will not be covering that here.With the integration of the Exchange Management Shell, the cert request, installation and activation process is easily accomplished in only a few steps. I should also mention that with the introduction of Exchange 2007 there are new requirements for the certificates used. Subject Alternative Name (SAN) / Unified Communications (UCC) certificates are multi-domain certificates that allow more than one FQDN. Exchange 2007-2013 Servers have the need to use multiple domain names in a single cert for internal and external users; as well as, the autodiscover domain name. Having a single cert for all these names streamlines and simplifies the process of installing the certificates. Although, some recent articles have been published that explain how to configure Exchange to use the single domain name certificate so this is not a requirement; but it's simpler.
A good deal of this article relates to Small Business Server 2008 and 2011 but it's always recommended to "USE THE WIZARDS" in SBS. So, to generate the CSR and Import your certificate in SBS be sure to use the "Add Trusted Certificate Wizard." Here is a step-by-step article for using the wizard: Introducing the “Add a Trusted Certificate Wizard” in SBS 2008. Use this wizard in conjunction with the "Connect to the Internet Wizard" and "Setting up your Internet address" wizards to ensure your SBS server is properly configured for your SSL certificate.
** With the release of Exchange 2013 and somewhat recent changes to the names you're allowed to add to certificates this article must be updated. Internal server names, for non-public domain suffixes, can no longer be added to certificates. Also, you cannot add the Netbios name of your server. That being said, if you have a .local or any other non-routable domain you're going to have to make some major adjustments when your certificate expires. Additionally, you may decide to take a different route when deploying new domains - IE, instead of a non-routable domain internally you may choose to use a subdomain of your public routable domain name (internal.mydomain.com or ad.mydomain.com) so you can purchase public certificates from a trusted CA to use within your private domain. I WOULD HIGHLY RECOMMEND NOT SETTING YOUR INTERNAL DOMAIN NAME WITH A ROUTABLE PUBLIC DOMAIN YOU DO NOT OWN - I have a few customers who did this in the past and it's a rather annoying situation. Some folks are proponents for going with your internal domain matching your public domain to save money on certificate purchases (primarily if you use a Digicert Wildcard you can create unlimited duplicates for EVERYTHING) but it's up to you if it's right for your environment.
Something else to add here is the fact that since your server will possibly be using a public domain name for all of it's internal URLs you will need to setup your split-brain DNS on your domain DNS servers. This means, if you have a .local domain you'll may need to add a company.com zone on your internal DNS server in order to point the mail.company.com and autodiscover.company.com URLs to the private address of your server. Some firewalls will allow you to NAT the public address back to the private address if you prefer to run your network this way. Also, in most cases I prefer to setup 2 separate zones called mail.company.com and autodiscover.company.com so we only have to create the 2 records associated with those domain names and can avoid updating all of the companies public DNS zone internally. This is all preferential and these DNS changes are only required for some environments. If you cannot connect to the Exchange Server from inside your office using the public address you'll either need to make these changes or adjust your firewall to allow it. FYI, Exchange Certificates in 2013 only apply to the server holding the CAS role.
If you find a CA that's issuing trusted certificates for internal names you'll want to read this - https://www.digicert.com/i
Names to Include on the Certificate
Most likely your CA will allow you to add 5 total names to your certificate. Typically you want this list of names:SERVERNAME- INTERNAL NAMES ARE NO LONGER SUPPORTEDSERVERNAME.COMPANY.LOCAL- INTERNAL NAMES ARE NO LONGER SUPPORTED- AUTODISCOVER.COMPANY.COM
- MAIL.COMPANY.COM
- SERVERNAME.COMPANY.COM (if your internal domain is a publicly routable domain name - not required)
This leaves one available space for site names like COMPANYWEB or SITES if you're using SBS or host other sites on the server this may come as useful. Specifically, you want to include the name that shows under the default receive connector as the FQDN; which should be something like SERVERNAME.COMPANY.LOCAL. You can browse to the "Receive Connector(s) FQDN" section below to help you find this name. ** UPDATE - The internal domain names on certificates no longer apply. If you're using SBS you'll likely need to move to an internal CA certificate if you intend to use these private name. If you find some CA that will issue certificates for internal names you may want to read article above since they'll no longer be trusted by November 2015. However, you can adjust these names in SBS to use public names in Exchange just like with Standard servers. Changing the internal COMPANYWEB, SITES... names will take a bit of an additional adminsitrative effort that will not be covered here. Just know you'll likely need to make some adjustments in the near future if you continue to use SBS.
Generating the Certificate Request
The first step in this process is generating the Certificate Signing Request (CSR) that will be used by your chosen Certificate Authority (CA) to generate your SSL certificate. This CSR will contain all of the information the CA needs to generate your certificate. The steps are slightly different from in Exchange 2007 and 2010 so the commands are broken into their perspective sections. Also, I know there is a GUI wizard for certificate management in Exchange 2010 but I find it much slower and pretty unreliable. *Note: These commands need to be run by a domain and Exchange administrator. Not using an administrator will cause the shell commands to error out.Exchange 2007
From the Exchange Management Shell type the following to generate your CSR on the C: drive of your machine. You will need to change the names in ALL CAPS to match your environment.
New-ExchangeCertificate -GenerateRequest -DomainName MAIL.COMPANY.COM, autodiscover.COMPANY.COM -Friendlyname "COMPANY FRIENDLY NAME" -PrivateKeyExportable:$true -Path C:\certreq.txt
Exchange 2010-2013 (Command Line)
From the Exchange Management Shell type the following to generate your CSR on the C: drive of your machine. You will need to change the names in ALL CAPS to match your environment. The first part of these commands generates a variable within the shell that is required to generate the certificate request. The second portion actually generates and exports the CSR text file.
$Data = New-ExchangeCertificate -GenerateRequest -DomainName MAIL.COMPANY.COM, autodiscover.COMPANY.COM -Friendlyname "COMPANY FRIENDLY NAME" -PrivateKeyExportable:$true
Set-Content -path "C:\certreq.txt" -Value $Data
Exchange 2010-2013 (GUI)
With the initial publication of this article I found the Exchange 2010 certificate GUI (located by clicking on "Server Configuration" within the Management Console) to be quite unreliable. I've used it numerous times since then and have had few issues. So, if you're not comfortable using the command line I recommend checking out these articles:
2013 - http://www.msexchange.org/
2010 - http://www.msexchange.org/
Common
After you hit enter the thumbprint of the cert will be generated and displayed. Use the generated certreq.txt when prompted at your chosen CA by opening the text file and copy/paste the contents into the CA's online form. *Note: If you copy/paste the CSR in an email or paste into a rich text file before pasting it into the CA's form it will likely lose some required formatting and the CSR will not work. It must be plain text. ** UPDATE: POP and IMAP are legacy services that will likely give you trouble with Wildcard Certificates. Also, you need to decide whether or not you want to utilize a wildcard certificate (works for *.company.com including every subdomain for your company and allowing you to use it for ALL your servers - Digicert has a great feature that allows you to create duplicate wildcard certificates which makes it a bit easier to manage all of your servers and prevents you from needing to export your private key to add the cert to new systems). If you have a pile of servers utilizing hostnames from your public routed domain or have an internal domain that's publicly routable you mind find the investment in a wildcard worth it. SAN certs are a good deal cheaper but if you have purchase a large number of them they're more difficult to manage and the costs add up. If this is the only server you have an you don't need certs anywhere else, just get a SAN cert.
Importing and Enabling Your Certificate for Use with Exchange and IIS
Once you’ve acquired your certificate from your chosen CA save it to C:\MAIL.COMPANY.COM.CRT (the certificate names will vary and may have different extensions so you need to change the following commands to match your certificate name and location). The commands are very different in Exchange 2007 and 2010 so this section is broken down to display the different commands.Exchange 2007
From the Exchange Management Shell type the following to import and enable your new certificate.
Import-ExchangeCertificate –Path C:\MAIL.COMPANY.COM.CRT | Enable-ExchangeCertificate –Services "POP, IMAP, IIS, SMTP"
Exchange 2010-2013 (Command Line)
From the Exchange Management Shell type the following to import and enable your new certificate.
Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path C:\MAIL.COMPANY.COM.CRT -Encoding byte -ReadCount 0)) | Enable-ExchangeCertificate –Services "POP, IMAP, IIS, SMTP" -DoNotRequireSSL
Exchange 2010-2013 (GUI)
No reason for me to re-invent the wheel here when MSExchange.org has done a very nice job on this topc.
2013 - http://www.msexchange.org/
2010 - http://www.msexchange.org/
Common
After you hit enter your new cert will be enabled for the services listed in the command. To verify the successful installation use this command Get-ExchangeCertificate | fl. Also, if you want to require SSL remove the -DoNotRequireSSL from the command. *Note: I've had issues in the past on server's where there are multiple self-signed certificates and the piped enable command above didn't enable the certificate for all of the services. Usually I can re-run the Enable-ExchangeCertificate
Setting Your Server's Internal and External URLs, URis and FQDNs to Match Your Certificate's Names
** REMEMBER: If you are installing certificates for an established server and you are using internal names that are non-routable private domain names you will need to change the internal URLs to match a name on your public certificate here. Also, remember to make your internal DNS changes (split-brain) so your clients can properly resolve, and connect to, the Exchange server from inside your domain network using the public DNS name.
Once your certificate is imported and running you'll want to verify your IIS virtual directory URLs and other client access server names are configured using the names on the certificate. There's several URLs, URis and FQDNs that need to be verified and/or configured - Outlook Web Access (OWA), ActiveSync, Offline Address Book (OAB), Exchange Web Services (EWS), Unified Messaging (UM), Autodiscover, Outlook Anywhere, Receive Connector(s) and Send Connector(s).
Outlook Web Access Internal and External URLs
To make the changes within the Exchange Management Console browse to the Server Configuration section -> Client Access -> Outlook Web Access tab -> Properties of OWA -> General tab -> Change the internal and external URLs to names that match your certificate's names. ** UPDATE: For Exchange 2013 you need to login to your Exchange Admin Access panel - https:///ECP > Servers link on the left > Virtual Directories tab at the top of the page > Properties of owa (Default Website) and make the changes on the default page
Get-OWAVirtualDirectory -identity SERVERNAME\owa* | fl *URL
Set-OWAVirtualDirectory -identity SERVERNAME\owa* -ExternalURL https://MAIL.COMPANY.COM/owa -InternalURL https://MAIL.COMPANY.COM/owa
ActiveSync Internal and External URLs
To make the changes within the Exchange Management Console browse to the Server Configuration section -> Client Access -> Exchange ActiveSync tab -> Properties of Microsoft-Server-ActiveSyn
Use the following command to check the URLs from the Exchange Management Shell
Get-ActiveSyncVirtualDirectory -identity SERVERNAME\Microsoft-Server-ActiveSync* | fl *URL
Set-ActiveSyncVirtualDirectory -identity SERVERNAME\Microsoft-Server-ActiveSync* -ExternalURL https://MAIL.COMPANY.COM/Microsoft-Server-ActiveSync -InternalURL https://MAIL.COMPANY.COM/Microsoft-Server-ActiveSync
Offline Address Book Internal and External URLs
To make the changes within the Exchange Management Console browse to the Server Configuration section -> Client Access -> Offline Address Book tab -> Properties of OAB -> URLs tab -> Change the internal and external URLs to names that match your certificate's names. ** UPDATE: For Exchange 2013 you need to login to your Exchange Admin Access panel - https:///ECP > Servers link on the left > Virtual Directories tab at the top of the page > Properties of Microsoft-Server-Active
Exchange 2010
Get-OABVirtualDirectory -identity SERVERNAME\oab* | fl *URL
Set-OABVirtualDirectory -identity SERVERNAME\oab* -ExternalURL https://MAIL.COMPANY.COM/oab -InternalURL https://MAIL.COMPANY.COM/oab
Web Services Internal and External URLs
Use the following command to check the URLs from the Exchange Management Shell. ** UPDATE: For Exchange 2013 you can login to your Exchange Admin Access panel - https:///ECP > Servers link on the left > Virtual Directories tab at the top of the page > Properties of EWS (Default Website) and make the changes on the default page via the GUI if you choose.
Get-WebServicesVirtualDirectory -identity SERVERNAME\ews* | fl *URL
Set-WebServicesVirtualDirectory -identity SERVERNAME\ews* -ExternalURL https://MAIL.COMPANY.COM/ews/exchange.asmx -InternalURL https://MAIL.COMPANY.COM/ews/exchange.asmx
Unified Messaging Internal and External URLs
Use the following command to check the URLs from the Exchange Management Shell
Get-UMVirtualDirectory -identity SERVERNAME\UnifiedMessaging* | fl *URL
Set-UMVirtualDirectory -identity SERVERNAME\UnifiedMessaging* -ExternalURL https://MAIL.COMPANY.COM/UnifiedMessaging/service.asmx -InternalURL https://MAIL.COMPANY.COM/UnifiedMessaging/service.asmx
Autodiscover Internal URi
Use the following command to check the URLs from the Exchange Management Shell
Get-ClientAccessServer -identity SERVERNAME | fl AutoDiscoverServiceInternalUri
Set-ClientAccessServer -identity SERVERNAME -AutoDiscoverServiceInternalUri https://AUTODISCOVER.COMPANY.COM/Autodiscover/autodiscover.xml
Outlook Anywhere External Hostname
To make the changes within the Exchange Management Console browse to the Server Configuration section -> Client Access -> Click on your Exchange server -> Properties of the Exchange Server -> Outlook Anywhere tab -> Change the external hostname to match your certificate's principal name. ** UPDATE: For Exchange 2013 you can login to your Exchange Admin Access panel - https:///ECP > Servers link on the left > Servers tab at the top of the page > Properties of your Exchange Server (CAS) and make the changes on the Outlook Anywhere page link on the left.
Use the following command to check the URLs from the Exchange Management Shell
Get-OutlookAnywhere -identity SERVERNAME\Rpc* | fl ExternalHostname
Set-OutlookAnywhere -identity SERVERNAME\Rpc* -ExternalHostname MAIL.COMPANY.COM
Receive Connector(s) FQDN
In most cases the default receive connectors do not require any configuration changes. But, you will want to verify that the name used by the receive connectors is present in your certificate. To view the receive connectors go to Exchange Management Console browse to the Server Configuration section -> Hub Transport -> click on your receive connector -> Properties of the receive connector -> General tab -> Review the FQDN. ** UPDATE: For Exchange 2013, or 2010 for that matter, you really don't have to do this and Exchange 2013 doesn't even show the FQDN option in the Receive Connector settings.
Use the following command to check the URLs from the Exchange Management Shell
Get-ReceiveConnector | fl identity,FQDN
In the rare event you should need to change the FQDN of any receive connectors use the following command to change the URLs from the Exchange Management Shell
Set-ReceiveConnector -identity "SERVERNAME\RECEIVE CONNECTOR NAME" -Fqdn MAIL.COMPANY.COM
Send Connector(s) FQDN
To make the changes within the Exchange Management Console browse to the Organization Configuration section -> Hub Transport -> Send Connectors tab -> Properties of the send connector -> General tab -> Change the FQDN to match your certificate's principal name. ** UPDATE: For Exchange 2013, ou really don't have to do this and Exchange 2013 doesn't even show the FQDN option in the Send Connector settings.
Use the following command to check the URLs from the Exchange Management Shell
Get-SendConnector | fl identity,FQDN
Set-SendConnector -identity "SEND CONNECTOR NAME" -Fqdn MAIL.COMPANY.COM
Quick Copy/Paste Text File Creator for all Commands (NEW!)
Just update the "Set Variables" section and run this from your Exchange Management Shell to generate a text file including all the commands customized for your environment.
#Set Variables
$mail = "MAIL.COMPANY.COM"
$auto = "AUTODISCOVER.COMPANY.COM"
$friendly = "COMPANY FRIENDLY NAME"
$csrpath = "C:\certreq.txt"
$certpath = "C:\MAIL.COMPANY.COM.CRT"
$txtfile = "C:\ExchangeCertificateCommands.txt"
$servername = "SERVERNAME"
#Check Exchange Server Version
$exver = Get-ExchangeServer
if($exver.AdminDisplayVersion -like "Version 8*")
{
@"
#Generate the CSR
New-ExchangeCertificate -GenerateRequest -DomainName $mail, $auto -Friendlyname "$friendly" -PrivateKeyExportable:$true -Path "$csrpath"
#Import the Certificate File
Import-ExchangeCertificate –Path "$certpath" | Enable-ExchangeCertificate –Services "POP, IMAP, IIS, SMTP"
"@ | Out-File $txtfile
}
else
{
@"
#Generate the CSR
`$Data = New-ExchangeCertificate -GenerateRequest -DomainName $mail, $auto -Friendlyname "$friendly" -PrivateKeyExportable:$true
Set-Content -path "$csrpath" -Value $Data
#Import the Certificate File
Import-ExchangeCertificate -FileData ([Byte[]]`$(Get-Content -Path "$certpath" -Encoding byte -ReadCount 0)) | Enable-ExchangeCertificate –Services "POP, IMAP, IIS, SMTP" -DoNotRequireSSL
"@ | Out-File $txtfile
}
@"
#Set Virtual Directory URLs
#OWA
Set-OWAVirtualDirectory -identity $servername\owa* -ExternalURL https://$mail/owa -InternalURL https://$mail/owa
#ActiveSync
Set-ActiveSyncVirtualDirectory -identity $servername\Microsoft-Server-ActiveSync* -ExternalURL https://$mail/Microsoft-Server-ActiveSync -InternalURL https://$mail/Microsoft-Server-ActiveSync
#OAB
Set-OABVirtualDirectory -identity $servername\oab* -ExternalURL https://$mail/oab -InternalURL https://$mail/oab
#EWS
Set-WebServicesVirtualDirectory -identity $servername\ews* -ExternalURL https://$mail/ews/exchange.asmx -InternalURL https://$mail/ews/exchange.asmx
#UnifiedMessaging
Set-UMVirtualDirectory -identity $servername\UnifiedMessaging* -ExternalURL https://$mail/UnifiedMessaging/service.asmx -InternalURL https://$mail/UnifiedMessaging/service.asmx
#AutoDiscoverInternalURI
Set-ClientAccessServer -identity $servername -AutoDiscoverServiceInternalUri https://$auto/Autodiscover/autodiscover.xml
#OutlookAnywhere
Set-OutlookAnywhere -identity $servername\Rpc* -ExternalHostname $mail
"@ | Out-File $txtfile -Append
Notes
- This process can be done with a self generated cert as long as that cert has been manually installed and trusted by the clients. To get more information on configuring a self signed cert so your server doesn’t drive you crazy with password prompts view this article.
- If you're using SBS you may want to add additional names to your certificate such as REMOTE.COMPANY.COM or COMPANYWEB.
- You need to include the autodiscover.company.com in the list of domains in order for Autodiscover to work. Also, you will need to create a CNAME or A record that points to your mail server. Autodiscover.company.com is the second URL that's checked by the client in the Autodiscover process after company.com.
- Continual password prompts on your client machines within Outlook is a good indication that your SSL certificate is not correctly configured, enabled or your virtual directory URLs are incorrect. Check this article for troubleshooting steps - Outlook Continually Prompting for Username and Password.
- **REMEMBER: To adjust your internal DNS, or firewall, to allow your users to connect to the public URL of the Exchange Server. You do not have to use the same internal URL as the public URL if you prefer to differentiate between the connections. You may experience some minor issues with mobile devices that tend to cache certificates of the server but the issues are typically overcome by rebooting the device or re-running the autodiscover for the account.
Sources and Links
Technet - How to Configure Exchange Services for the Autodiscover Service
msexchange.org - SSL certs for Exchange 2007
Technet - How to Request an SSL Certificate
Technet - How to Configure SSL Certificates to Use Multiple Client Access Server Host Names
Configuring Outlook Anywhere with a Self-Signed Certificate
Outlook Continually Prompting for Username and Password
Godaddy
Digicert
Exchange 2007 Single Name SSL Certificate
Technet - Understanding Receive Connectors
Introducing the “Add a Trusted Certificate Wizard” in SBS 2008
msexchange.org - Managing Exchange 2013 Certificates
msexchange.org - Managing Exchange 2010 Certificates
TechNet - Enable-ExchangeCertificate
TechNet - Import-ExchangeCertificate
TechNet - New-ExchangeCertificate
Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.
Comments (2)
Commented:
Alan
Commented:
You have my vote too :)