
close
close
Businesses who are implementing Microsoft Exchange Server face important decisions about how they will manage SSL certificates.
In the history of Exchange Server there was a time when SSL certificates were optional, but not required by default. Even today there are people who do not consider them mandatory.
advertisment
The use of SSL certificates with Exchange Server rose to importance as more Exchange services became open to the internet. Services such as Outlook Web Access (now Outlook Web App) for webmail, ActiveSync for mobile devices, Outlook Anywhere, and the new Exchange Web Services APIs are now web-facing and play a critical role in business communications.
Exchange Server 2007 was the first version to require SSL certificates by default for certain services. It was also the first time many Exchange administrators had encountered SAN certificates.
SAN stands for “Subject Alternative Names” and refers to using additional attributes in the SSL certificate to list more than one name for the SSL certificate. This became necessary with the move to SSL by default for Exchange Server 2007, because the server would now be answering to more than one name for SSL connections. This typically includes:
Exchange Server 2010 continues this standard of using SSL by default on end user and server-to-server communications protocols.
advertisment
Because of the default requirement for SSL, each Exchange server is automatically provisioned with a self-signed certificate when it is installed. However, because it is self-signed it is not trusted by any connecting clients. This results in problems such as:
In the field we see several different workarounds being used to resolve those problems, such as:
As you can see, even though workarounds are possible they are not always practical to implement, especially in larger environments. They can create more administrative effort to implement and maintain, and may not solve all of the issues for some environments.
advertisment
The worst case scenario is doing nothing, which ultimately trains users to be unconcerned about security and to view certificate mismatches and trust failures as something to simply ignore.
With all of that in mind, the business case is clear for purchasing SSL SAN certificates from a genuine commercial certificate authority to use with Exchange Server 2007 and 2010. For an outlay of as little as a few hundred dollars the business receives the benefits of:
Bio: Paul Cunningham is an Exchange Server specialist for a leading systems integrator in Australia. See more Exchange Server tutorials by Paul at ExchangeServerPro.com.
More from Paul Cunningham
advertisment
Petri Newsletters
Whether it’s Security or Cloud Computing, we have the know-how for you. Sign up for our newsletters here.
advertisment
More in Exchange Server
Microsoft to Ship Some Exchange Server Security Updates in .EXE Packages
May 11, 2022 | Rabia Noureen
M365 Changelog: Exchange Transport Rule Report moving to the new Exchange Admin Center (EAC) from the Security and Compliance Center
Apr 22, 2022 | Petri Staff
M365 Changelog: (Updated) Change to mailbox forwarding behavior coming to Exchange Online
Apr 21, 2022 | Petri Staff
M365 Changelog: (Updated) Microsoft Defender for Office 365: Updates to URL Protection Report
Apr 21, 2022 | Petri Staff
Most popular on petri
Log in to save content to your profile.
Article saved!
Access saved content from your profile page. View Saved
Join The Conversation
Create a free account today to participate in forum conversations, comment on posts and more.
Copyright ©2019 BWW Media Group