SysAdmin Talk

One of the biggest challenges facing Exchange administrators is the management of SSL certificates. Exchange uses SSL certificates to secure communications between clients and servers for services such as Outlook Web App, Exchange ActiveSync, Outlook Anywhere, and more. There are several details that need to be taken into consideration when troubleshooting problems with Exchange certificates.

Certificate Types

Before we take a look at some of the more common problems with Exchange certificates, it will help to understand the types of certificates that are used in Exchange:

• Self-Signed Certificates – Exchange installs a default self-signed certificate intended for temporary use. This will provide basic functionality to get you up and running, but as a best practice, it is recommended that you replace these certificates using internal PKI or third-party trusted certificates. Keep in mind that Outlook Anywhere is not supported with a self-signed certificate.
• Windows PKI Certificates – Some organizations choose to implement their own internal PKI and issue certificates to Exchange servers using an internal Certificate Authority (CA). This saves money, but can add administrative overhead, as CA root certificates may need to be manually installed on certain devices.
• Trusted Third-Party Certificates – Commercial certificates, also referred to as Unified Communications Certificates (UCC) are commonly used since they are trusted by default on all computers, which greatly simplifies deployment.

A Quick Note on Autodiscover

Autodiscover provides clients with URLs for the Availability Service (free/busy information, Out of Office), the Offline Address Book and Unified Messaging. Most of the certificate problems I see are related to Autodiscover and these associated services – to fully understand these issues, a quick overview of how Autodiscover works internally might be helpful.

When you install a CAS Server, a Service Connection Point (SCP) record is created in Active Directory – this happens for every CAS server you install. The SCP record contains the FQDN of the associated CAS server. These SCP records are used by Outlook on internal, domain joined machines to discover CAS servers. When a user launches Outlook 2007/2010, it will query Active Directory for these SCP records and return the address of a CAS server. Once the user is connected, Outlook will receive the URLs for the Availability Service (free/busy information, Out of Office), the Offline Address Book and Unified Messaging, all of which need valid certificates.

Common Problems

Here are some of the most common certificate related problems that I see on a regular basis:

1. Unable to resolve fully qualified domain names (FQDN)
Make sure that all FQDNs being used on your certificates have the appropriate A records created in both your internal and external DNS zones.

2. The certificate name does not match the URL
You need to make sure that all FQDNs that will be used to access Exchange services are on the certificate. You can accomplish this using multiple Subject Alternative Names (SANs) when you generate your certificate request using the New-ExchangeCertificate cmdlet.

3. The certificate is not trusted
By default, self-signed certificates are not trusted. Depending on the service you are accessing, and where you are accessing it from, you may receive certificate warnings, or things may not work at all. The best way to get around this is to use a trusted certificate. As mentioned previously, it’s recommended that you replace the default self-signed certificates.

You may run into the same issue using an internal PKI certificate. Depending on the device, you may need to install the root certificate from the issuing CA in the clients local Trusted Root Certificate Authorities store.

4. Autodiscover SCP record is not configured correctly
Depending on your configuration, you may need to update the Autodiscover SCP record. To update the SCP record, use the Set-ClientAccessServer cmdlet, specifying the correct URL using the AutodiscoverServiceInternalUri parameter, for example:

Set-ClientAccessServer -Identity CAS_Server_Name `
-AutodiscoverServiceInternalUri https://autodiscover.domain.com/autodiscover/autodiscover.xml

5. Internal/External URLs are not configured correctly
As I mentioned, Autodiscover will provide client machines with the URLs for Exchange Web Services (free/busy, OOF, etc.), Offline Address Book, and Unified Messaging. You can configure the URLs for these services using the following cmdlets, all of which support the InternalURL and ExternalURL parameters. The commands below are only provided to give you an idea of the syntax. Keep in mind, the FQDNs used for these commands depend on your environment and DNS namespace configuration:

Set-WebServicesVirtualDirectory -Identity “CAS_Server_Name\EWS (Default Web Site)” `
-InternalUrl https://mail.domain.com/ews/exchange.asmx -ExternallUrl https://mail.domain.com/ews/exchange.asmx

Set-OABVirtualDirectory -Identity “CAS_Server_Name\oab (Default Web Site)” `
-InternalUrl https://mail.domain.com/oab -ExternallUrl https://mail.domain.com/oab

Set-UMVirtualDirectory -Identity "CAS_Server_Name\UnifiedMessaging `
(Default Web Site)" -InternalUrl https://mail.domain.com/unifiedmessaging/service.asmx `
-ExternallUrl https://mail.domain.com/unifiedmessaging/service.asmx

6. CAS Array / Load Balanced CAS Servers
I often see customers deploy load balanced CAS Servers without modifying the SCP record, or any other internal URLs. This effectively eliminates these services from being load balanced, as clients will be connecting directly to the CAS servers by name. Also, if the NetBIOS names of the CAS servers are not on the certificate, users will receive a security warning message when connecting to their mailbox that says “The name of the security certificate is invalid or does not match the name of the site”. Use #4 and #5 to correct this issue.

7. Trouble exporting and importing certificates
If you are planning on exporting certificates from one server and importing them on the other, make sure that you set the private key as exportable when you generate your certificate request. For example:

New-ExchangeCertificate -GenerateRequest -SubjectName “c=US, o=Litware, `
cn=mail.litware.internal” -DomainName owa.litware.internal,mail.litware.internal `
-PrivateKeyExportable $true

8. The certificate is expired
I run into this a lot with servers that are using the default self-signed certificate. Use the New-ExchangeCertificate cmdlet if you need to replace an expired certificate or generate a new request. To check the expiration date, use the Get-ExchangeCertificate cmdlet, for example:

Get-ExchangeCertificate | fl notafter

As you can see, there are many details when it comes to working with Exchange certificates. The settings can vary greatly depending on the configuration of your environment, so make sure to plan accordingly.