Many Exchange shops use wildcard certificates to lower costs and add flexibility, but there are security risks, compatibility issues and potential management headaches that may outweigh those benefits.
What is a wildcard certificate?
Wildcard certificates are a type of X.509 certificate in which the Subject Alternate Name (SAN) is replaced by a wildcard, making the certificate valid for multiple machines. This lets Exchange customers use a single certificate for their root domain and for all of their first-tier sub-domains, reducing the number of certificates they need to buy.
Wildcard certificates provide the same level of encryption as regular certificates, but they are not without risk.
Wildcard certificate security issues
A regular X.509 certificate is typically bound to either a single server or to a single domain. For example, it's common for an Exchange Server administrator to purchase an X.509 certificate to use in conjunction with his client access server (CAS). This certificate is typically tied to the CAS's fully qualified domain name, which prevents it from being used on any other machine.
Since wildcard certificates are used by multiple servers in multiple domains, the servers that share the certificate also share the same private key. This is a major security risk because if a single server is compromised, the individual who hacked the server could gain access to a private key that is valid across the entire Exchange organization.
Using this key, the hacker can also configure a rogue machine to represent itself as any one of the servers on the network. Network clients will inherently trust this rogue server because it is using a private key that has previously been deemed trustworthy.
Traditional X.509 certificates are more secure than wildcards because each certificate establishes a private key that is unique to one server. That security benefit may be worth the investment.
Wildcard certificate management issues
And as you can imagine, when wildcard certificates are compromised, management headaches follow.
When a non-wildcard certificate is compromised, the certificate must be revoked and then re-issued to every server that uses it. But it isn’t that simple with wildcard certificates.
Suppose you have 100 servers that all use the same wildcard certificate. If something happens to that certificate, you must manually remove the certificate from each server, then issue a new certificate to each server. That's a lot of work.
The first issue impacts Exchange shops that use ActiveSync for mobile device connectivity. Some mobile devices -- particularly those running Windows Mobile 5.0 -- don't support SSL sessions that are encrypted with wildcard certificates. Because these devices cannot establish SSL connectivity with the CAS, they are unable to initiate ActiveSync synchronization.
Additionally, if you choose to use wildcard certificates, you must reconfigure the Autodiscover service on Exchange 2007 client access servers. If you do not reconfigure them, clients will not be able to connect. (You can find additional information about these client connectivity issues at TechNet).
ABOUT THE AUTHOR:
Brien Posey is an eight-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.
This was first published in August 2011