Exchange Hybrid deployment certificate requirements

Exchange Online gains more and more momentum and Exchange hybrid deployments are already a pretty common scenario for a lot of IT organizations. Even if almost every aspect around an Exchange Hybrid deployment is well known by IT pros, there is still a point that seems to cause some difficulties: certificates. And since an Exchange hybrid deployment is not possible without a proper certificate configuration, I thought to clarify the most important aspects about certificates in such a scenario by answering 5 questions I often hear when working with IT administrators.

One of the top question I deal with almost every day is: “I have a self signed certificate configured for my Exchange Server deployment, issued by my Windows Server 2012 R2 Certification authority. Can I use this certificate for an Exchange Hybrid deployment?” The answer is NO! In order to create an Exchange Hybrid deployment, organizations need a certificates issued by a trusted and public certification authority. And the reason why is very simple. Certificates are meant to prove your organization’s identity so that users and other service providers (like Microsoft) can be sure that they engage with the organizations they wanted to engage and not with an attacker. Similar to ISO standards and certifications, the safest way to prove an organization’s identity is to have a third party, public and trusted authority that testifies it. This is a global industry standard and in my opinion this is also one of the pillars of cyber security. Using self signed certificates for server deployments may be cheaper, but it really exposes organizations to a lot of potential cyber attacks. If users access emails only from the corporate network, this might be okay, but if users can also access their Exchange data from outside the corporate network, self signed certificates are a huge security breach. Cyber security awareness training educates staff and makes phishing your organization pointless.

A second very common question is: “What type of certificate do I need for an Exchange hybrid deployment?” IT organizations have basically 2 different options. The first one is to use a wildcard certificate with a subject name like *.domain.com. This would mean that the certificate would perfectly work for all service FQDNs that an organization may use and that end in .domain.com. For exemple: mail.domain.com, autodiscover.domain.com and so on.

The second option would be to use a certificate that includes a subject name like domain.com and several subject alternative names like mail.domain.com, autodiscover.domain.com and so on. This certificate type is popularly known as a SAN certificate.

A logical question that derives from this two options is: “What type of certificate should I choose?” Well…..it depends on the certificate model that an organization may already use for all the services that it provides for its users. Generally, I would recommend to use a service certificate across multiple servers. This would mean that you need one certificate for all Exchange Services independent on how many server you have that support that services, another certificate for ADFS services, another certificate for all other web services and so on, depending how many services an organizations offers to their end users or customers.

An alternative way would be to user a per server certificate. This means that the certificate on one server is used by all services that run on that certain server. A big disadvantage in this approach is that all company services may be affected if we encounter a PKI problem on a specific server.

Bringing the discussion back to Exchange hybrid deployments, administrators can choose between this two different possibilities based on their company policies or personal experience. Both type of certificates work just fine for Exchange hybrid deployments.

The next big question is: “I have a wildcard certificate. Can I use the same certificate also on the ADFS server for SSO to Office 365 services?” The discussion here becomes very tricky. For SSO to Office 365 the requirement is to have a certificate issued by a certification authority with the FQDN of your authentication service as a subject. For example: sts.domain.com. Now if you have a wildcard certificate like *.domain.com, this would logically also include sts.domain.com. And this is correct. From my experience, ADFS services may also work with a wildcard certificate. However, it is strongly recommended to have a separate certificate for the ADFS service. This is a more secure approach and it also makes your services independent from each other. From a high availability perspective it may be a little bit foolish to make all your service dependent on one single certificate.

Nope, we’re not ready yet :)! There is still a very important question: “My organization has 30 SMTP domains. What kind of certificate do I need for this scenario?” This is indeed a very important question. For obvious reasons, it is theoretically not possible to use a wildcard certificate if a company uses different SMTP domains. So the only choice here would be a SAN certificate, but bare in mind that all used SMTP domains have to be added as a subject alternative name to the certificate. On the other side, you would also need to properly configure your DNS for this type of deployment. Now, with Exchange 2010 based hybrid deployments this is a very big pain point since you would need to create an A record for each SMTP domain that points to the autodiscover service. You could use CNAME records for Autodiscover redirection, but that wouldn’t change the fact that you have to add all Autodiscover records to the SAN certificate. Also, Exchange hybrid deployments don’t support SRV-based Autodiscover redirection.

However, with Exchange 2013 we have a very useful new autodiscover domain feature that could be used for hybrid deployments. This allows admins to use PowerShell to define the autodiscover domain for all used SMTP domains. The PowerShell cmdlet would be:



1
Set-HybridConfiguration –Domains "contoso.com, fabrikam.com", "autod:wingtiptoys.com"

And using this Exchange 2013 feature you don’t need to add all SMTP domains as a subject alternative name to your certificate and therefore you may practically still be able to use a wildcard certificate.

I really preferred to answer “NO” to this questions at first, to explain the logic behind and to conclude in the end that using a wildcard certificate in this scenario may still be possible, but only for Exchange 2013 based hybrid deployments.

Enough for this blog post! I would be really happy to hear from you, to hear your thoughts about certificate requirements for Exchange Hybrid deployments, your questions or any other type of feedback 🙂