Managing Certificates in Exchange Server 2010 (Part 1)

If you would like to read the other parts in this article series please go to:

Introduction

A long time ago when the messaging system was ruled by Exchange Server 2000/2003 the Internet Information Service was the way to go to manage certificates. And the process wasn’t that complicated however certificates were not a requirement at that time which means for those who installed the product using the default settings everything would be fine without using certificates.

However this situation changed with Exchange Server 2007 which brought the certificate requirements to a higher level with built-in self-signed certificates created as part of the installation process, web services, autodiscover and so forth. Since Exchange Server 2007 a Public Certificate was not a requirement but a good practice and the process to manage certificates was using the Exchange Management Console. Through that process the certificate would be installed in the Computer Certificate store and the services will be associated to the proper certificates without the need of manual steps into IIS configuration.

In this article we are going over the process to request a certificate in Exchange Server 2010 using both methods available: Exchange Management Shell and Exchange Management Console. Yes! In this new version we are able to manage certificates using the console which helps administrators or operators that just want to request a certificate without memorizing or reading several pages and examples on the Internet.

Which certificate should my company use?

There are different opinions on the Internet about which certificate should be used, some administrators like the idea to use certificates provided by an internal Certificate Authority which is cheaper, however, this brings a couple of issues. One example is the process to install the Trusted Root Certificate on the clients which can be accomplished using Group Policies. It doesn’t help users that have never logged on the network and users on Windows Mobile devices.

I personally like the idea and recommend to my customers to use Public Certificates for the sake of simplicity, you don’t have to add burden to your helpdesk to configure remote users because they don’t have a certificate, Windows Mobile and Outlook Anywhere will work like a charm using Autodiscover from any computer inside or outside the network.

I hope (and your helpdesks too!) that you take my advice and buy a Public Certificate, and if you did you are not going to regret it for sure! However you have another decision to make: are you going to use SAN or wildcard certificates? This one is easier… If you use a wildcard certificate you are going to have a single certificate for your entire domain which may bring some security concerns, where a single certificate can be used to your entire organization and is more expensive as well. On the other side we have a UC certificate which allows us to have a single certificate with additional names added to it which makes easier to add all Exchange Server names that are required in a single request and install it on all servers.

If you are going for a Public Certificate then these few tips can save you some time as follows:

  • Do some research before buying a certificate, Microsoft has an article that will assist you and it is available here.
  • The certification Authorities use an industry practice based on Mozilla’s Certificate Policy for Certificate Authorities to verify the domain ownership during the domain validation initial process. Make sure that you have at least one of these e-mails created:
    o   [email protected]
    o   [email protected]
    o   [email protected]
    o   [email protected]
    o   [email protected]
    Thanks to Digicert’s support team in clarifying the e-mail address requirements.
  • Make sure that the postmaster alias or an administrator account is added to your domain. Some Certification Authorities send a message to one of well-known address as part of the validation process before issuing the certificate. 
    The e-mail addresses requested during the Digicert for example: [email protected], [email protected], [email protected], [email protected], [email protected] or the e-mail listed in your smtp address configured in the WHOIS information.
    Thanks to the support team of Digicert for helping me out with this list.
  • Make sure that your company’s basic information is correct in the WHOIS service
  • You may need to manage your external DNS during the certificate deployment process. Some hosts configured in your external DNS, such as: autodiscover and the name defined in your Outlook Anywhere settings.
  • If you are being offered a really good price for 2 certificates instead of an UC certificate, please don’t do it. Does it work? Well, eventually will work, but keep it simple. With a simple UC certificate you can have all your names in a single place, no extra virtual directories in IIS and so forth.








In order to make your Certificate deployment as easy as possible some homework is necessary to identify which names are required during the certificate process. I’m a big fan of that old saying – measure twice cut once – and for that reason we are going to do this exercise to give you an idea how to choose your names. The thumb rule here is to keep it simple and use a common name for the majority of the services. Let’s say your company has a single Exchange server named srv-ex.company.local and your public domain is company.org, so a simple way to use all functionalities of your Exchange Server could be using these following names:

  • Autodiscover.company.org
    This one will allow your clients to be configured automatically.
  • Webmail.company.org
    This one will be used to all your Exchange web services, Outlook Web App, Active Sync and etc.
  • Srv-ex.company.local
    This one is important if you don’t want to have any issues when you change the certificate, by default all Exchange Web Services will be using the local server FQDN and besides of being a best practice you can add a Public Certificate without changing any settings.


A few names can be added if you require other services running SSL in your organization, some common scenarios are:

  • You are migrating from Exchange Server 2003 and want coexistence between both environments. In this situation a legacy.company.org or any host to represent the legacy should be added to the list.
  • If you are using multiple SMTPs and autodiscover for all of them. You can use redirect feature to do that and save some money on the certificates or use autodiscover DNS and certificate entries for all domains.
  • Multiples SMTP and autodiscover must be enabled on all of them. One way to go is to create a autodiscover for each of the domains and
  • You have a service not related to Exchange Service and even though you want to use the same request to add the required name and use the certificate on both servers. In this scenario add those names to your certificate and make sure that your Certification Authority supports this kind of scenario.

Now that we went over some issues that may arise during the request process we can move forward and see the technical stuff. Keep in mind that each scenario/design may require different configuration, but the objective of this article is to give you an idea how to plan and request certificates for your company.

Any Certificate configuration in Exchange Server uses at least 3 phases (Request, Import and Assign), as shown in Figure 01. I added Planning and Testing to keep in mind how important it is. After all, if you are at a customer and after requesting and importing a certificate you noticed that you forgot an entry! It will sound really bad, so planning is critical.


Figure 01

Conclusion

In this initial article we went through the process of planning certificates. Of course, we cannot create a definitive guide for all scenarios but I hope that some of the above hints apply to your environment and facilitate your process to request certificates.

The process to request certificates is pretty straight forward where you can either use Exchange Management Console or Shell as we will see in the upcoming articles. In next article we will go over the Exchange Management Console process and in the third and final article of this series we will cover the additional managing tasks using Exchange Management Console and Exchange Management Shell.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top