If you would like to read the other parts in this article series please go to:
- Managing Certificates in Exchange Server 2013 (Part 2)
- Managing Certificates in Exchange Server 2013 (Part 3)
- Managing Certificates in Exchange Server 2013 (Part 4)
- Managing Certificates in Exchange Server 2013 (Part 5)
- Managing Certificates in Exchange Server 2013 (Part 6)
Since the release of Exchange Server 2007, certificates became an important component of any new deployment of Exchange Server. In fact, they are a hot topic for administrators in forums and blogs.
In this series, we will go over the process of helping you to decide which certificate fits best your environment, and from that point on we will install and configure certificates in a typical Exchange environment.
Since I mentioned the Exchange Server 2007 release as a turning point for the Certificate topic in the Exchange world, I would like to point out a couple of changes as follows:
- Office 365/Azure is a big driver and it requires certificate(s) for transition and authentication processes
- Exchange Server 2010 introduced a new interface to help us manage certificates
- Exchange Server 2013 introduced EAC (Exchange Admin Center) to manage certificates
- Exchange Server 2013 has a new architecture which requires less certificates, we can have a main site and a Disaster Recovery site using just a few names
- Due to Security the Internal Names and non-public names on certificates are going away from most of the Public CA in the near future.
More Information can be found here.
In this first article we are going to give you some information to help you take a decision about which certificates you have available, and as part of this series we will start simple with a single server environment. Afterwards, we will give you some hints on how to extend the environment maintaining the same number of certificates.
What type of certificate?
We have three options to choose from when dealing with certificates: Public CA, Internal CA or self-signed. Each option has its implications and we are going over the key points of each type of certificate to help in the decision process.
- Public Certificates:
This is the best option for any size of organization for a couple of simple reasons: they work in the vast majority of clients computers (Linux, Apple and Microsoft joined or non-joined to the domain); the device configuration is seamlessly for the end-users and the same applies for mobile end-points such as iPhone, iPad, Android, and Windows Mobile. - Internal Certificates issued by an Internal CA Authority:
They are a possibility but may create issues because any client that does not trust that CA will have certification issues and it will affect Mobile devices and machines that are not joined to the domain. An Internal CA requires design and best practices to work in your Exchange Server environment. It can be used for several other applications. - Self-signed certificates:
They are the worst because they are not trusted by anybody except the Exchange Server 2013 that created them during the installation process. In order to make them less painful for your internal clients you need to add them to the GPO but you will have the same issues with non-joined computers and mobile devices. By default, Outlook Anywhere will not work for any client using this type of certificate and the same applies for mobile end-points besides of the usual certificate errors that you will get on your Outlook client.
Based on the previous explanations you may have realized by now that our recommendation is to use Public Certificates! Are you still not sure? If you are going to use Office365, Active Directory Federation Services and so forth, you can always add the additional name on your Exchange Certificate and you will be good to go.
The second reason is that they are easy for the end-users. Let us imagine a scenario where one of the executives is trying to connect his new personal tablet or even a PC from an external location. Because of the certificate errors a manual intervention is required. Depending on your executive profile you may have an issue right off the bat for him to waste time in a simple task as to configure a client.
This article series will use a Public Certificate however, you can continue reading in case you have decided to use Internal CA because the process will be the same. The only difference will be the configuration to accept the new certificate on the end-points.
If using a Public Certificate… What type of Certificate we are looking for?
I hope you have decided to use Public Certificates, and if that is your decision: Congratulations you will be a much happier exchange administrator!
We have two options with Exchange Server that makes sense for the vast majority of the companies, and here they are:
- Wildcard certificates: These can be used for the entire domain and they are easy to spot because they have a format like *.domain.ca We can have unlimited hosts using that certificate on that domain. The drawbacks are that one single certificate is used for all your servers and in a larger company you do not want to have several departments with access to the same certificate, also they may bring some security concerns because their private key can be in several servers.
In the past, they used to be more expensive than SAN Certificate but that is not the case anymore. - SAN Certificates (Subject Alternative Names)
This type of certificate allows more than a single name in a single SSL certificate which makes total sense for the new Microsoft products (Lync and Exchange) because several services are using names and all of them are underneath the same IIS Web Site. In some Public CA these certificates are also known as UC Certificates.
In this article series we are going to use a SAN Certificate because we are going to use just 2 (two) names in our certificate to support our Exchange environment.
Exchange Server 2013 and Certificates…
When Exchange Server 2013 is installed, a self-signed certificate is created during the installation process and that certificate is assigned to all services provided by Exchange Server.
If you have servers running different roles in Exchange Server 2013, you just need to worry about the Client Access Server role since that is the role that is going to be used for the client communications.
Since we know that all Certificates will be on the CAS portion, it is nice to know that services using the certificate that we are managing are all services that rely on IIS (OWA, EAC, Web Services, Active Sync, Outlook Anywhere, Autodiscover and OAB), legacy protocols such as POP and IMAP, and SMTP for TLS.
Conclusion
In this first article of the series we covered some of the challenges when choosing a certificate and how Exchange Server 2013 uses certificates in general.
If you would like to read the other parts in this article series please go to:
