Best and worst practices for Microsoft Exchange TLS and SSL

In the early 1990s, emails began to take up form and started evolving into a mainstream business application. This led to the development of many enterprise level solutions, which came with user-friendly applications dedicated for connectivity. Accordingly, Microsoft came up with its own collaborative enterprise server application for emails: Microsoft Exchange Server.

Microsoft Exchange was initially meant only for the Microsoft’s internal mail server but it became stable and robust enough to pave the way for the global release in the form of Exchange Server 4.0 in the year 1993. Microsoft Exchange is now a very popular and reliable mail server application and messaging system. Exchange includes functionalities of a mail server, mail user system, or a client email program, and also serves in groupware applications to connect working people remotely.

Microsoft Exchange can be implemented on a group of autonomously connected systems (on-premise), in the cloud, at an organisational level, or somewhere else in between the network. Irrespective of where it has been implemented, the primary concern of everyone associated with the network is to have a secure and reliable connection. To make these email connections secure, Microsoft Exchange is deployed with Transport Layer Security (TLS) to encrypt the connection. TLS is an upgraded version of SSL and is often referred as SSL 3.1. Microsoft Exchange uses TLS to encrypt connections between servers, and once it is set up, the entire connectivity happens over a secure encrypted channel.

Note that in Exchange, TLS never encrypts a message. Instead, it encrypts the connection through which a message is transferred. If a user needs to encrypt the message along with the connection, then s/he is advised to integrate encryption software such as the office message encryption (OME) with Exchange. Whenever a user sends an email to another user in the Exchange environment, the email is automatically sent over an encrypted connection using TLS, which is in secured using forward secrecy.

Being an end user, it is beneficent to master the usage of TLS in Exchange, especially following our tips for general TLS and SSL practice. Below are few tips and recommendations which users are advised to follow when working in an Exchange environment. Also, to receive my future Exchange configuration guides and best practices recommendations like this one, don’t forget to sign up for updates here!

Keep your systems updated


First and foremost to all users of Exchange, make sure that all your systems and peripherals involved in connecting to the Exchange environment are updated to their respective latest versions. Most of the issues in Microsoft Exchange are caused because of using outdated software versions. That said, almost all peripherals involved in the Microsoft Exchange medium such as client/server systems, routers, bridges, printers, load balancers, and more receive timely updates, which brings in better functionality and improved security.

Running on an outdated software versions means that users in general will not be able to get the most of any system. In the case of Microsoft Exchange, general software updates typically include the latest TLS versions, advanced encryption algorithms, and better firewalls to make your connections more safe and secure.

Disable support for SSL 3.0 on all systems involved in the connection

Microsoft Exchange uses TLS to secure connections, and as mentioned earlier, TLS is an updated version of SSL 3.0 and is often referred as SSL 3.1. Therefore, users must disable the outdated SSL 3.0 in the system’s browser. Although the age of SSL 3.0 is long gone, there are a large number of system browsers still deployed with SSL 3.0.

Moving a step further, after disabling SSL 3.0 from system’s browser, it has to be disabled in both the client and server side of a connection, including every peripheral working with it. However, to avoid any sort of security breach, users first need to check whether the system is installed with any of the current TLS versions or not. In many cases, most advanced versions of TLS common in all devices are implemented across the entire system. Therefore, if a user or an organisation wants to get the benefits of the latest TLS, they have to make sure to deploy the latest TLS in all devices involved in a connection.


Note that by disabling SSL 3.0 from your systems, you are eliminating the chance for a session to downgrade itself. Microsoft Exchange sessions have been using TLS 1.0 for over a decade now, so almost all systems (except systems which are older than a decade) are secured by TLS 1.0. Therefore, any version older than TLS 1.0 would not even be adequate for the job of providing secure connectivity and could be a potential threat to the security of the entire system.

Always use the latest ciphers

The latest ciphers are more resilient to intruders’ attacks compared to previous versions. However, the task of installing latest ciphers is not so simple. It is not just enabling the latest version and disabling the previous one. Instead, you have to provide a choice for your clients on the network to choose the best available cipher with maximum compatibility.

This selection of the cipher on the client and the server is a two-way process. Initially, the client sends a list of ciphers which it can support and then the server responds back with a selected cipher for its implementation.


Among the currently available ciphers in Exchange, RC4 (Rivest Cipher 4) is the weakest and is an outdated encryption technique. Since RC4 is a stream cipher, it is relatively easy to break in by brute-forcing when compared to other advanced ciphers such as 3DES and AES. However, disabling the RC4 cipher might result in few incompatibility issues among older systems in a network. Therefore, care has to be taken when disabling ciphers from entire network of systems.

Avoid using MD5/MD2 certificate hashing in entire network chain

As mentioned earlier, systems in the network have to be installed with the latest ciphers for securing a connection. But ciphers are largely dependent on certificates installed in the systems for their functionality. That said, even if you install latest ciphers but do not update the certificates in the network, the system won’t be able to implement these latest ciphers. MD5 and MD2 certificates are examples of the aforementioned type of outdated certificates which do not support most of the latest ciphers. Therefore, it is very important to completely avoid using MD5/MD2 certificate hashing in the entire network chain.

Certificate management

A digital certificate is like a “passport” which allows a user to exchange information safely over the Internet. Therefore, it is an inevitable fact that users have to be very cautious in managing digital certificates.

Creation and renewal of these digital certificates have to be performed in a well-planned timely manner following current standards.

While creating a certificate, always use a 2048-bit RSA crypto-system. Anything below the standards of 2048-bit RSA crypto-system is not considered to be secure anymore.


After certificate creation, the next important step in certificate management is timely renewal of digital certificates. Always have an eye on certificate’s expiry date. Moreover, it is equally important to renew these digital certificates with current standards. Still, users have to consider updating signature algorithms of certificates to SHA2 from the existing SHA1. This is a one-time process and if users have already updated to the SHA2 algorithm, they just need to keep an eye on the expiry date of certificates and renew them beforehand to avoid any sort of security breach.


Security and compliance

Even though most crucial data of your organisation is not in the cloud, you must cautiously consider security of data within systems with equal importance. It is good practice to use a separate administrator account for all regular user accounts in a network. One should always keep administrative accounts restricted to certain extents to avoid any sort of security breach.
Moreover, a connection with third party systems should be established only if the connection is secured via TLS or any other secure channel such as RSA SecureID. Transacting through an insecure channel is an open invitation for intruders to enter into your system.


Understand your Exchange system

Although you have latest set of ciphers along with trusted digital certificates, Microsoft Exchange must be checked in a timely manner to understand whether the system is able to support these advanced protocols or not. Exchange, being the backbone of this entire system, has to sometimes undergo a recompilation process or a thorough testing phase to get the most of these latest security protocols.

A few of the most important protocols of Microsoft Exchange which have to be tested regularly are SMTP, HTTPS, POP/IMAP, and all client systems. All these aforementioned protocols support TLS 1.0 by default for security and are even capable of handling TLS 1.1 and TLS 1.2 by updating the system version.

Test your systems regularly

There are a lot of third party tools and websites which lets you test your Exchange system with respect to clients and servers in an organisation. Although the methods and techniques deployed by these tools might vary, the outcome is common and reflects the system’s performance. We suggest you start using these tools and analyse the system regularly. Moreover, always prefer tools which let you check specific settings such as certificate issues, ciphers, TLS versions, and system protocols in a network. There are a lot of online tools such as SSL Labs, nmap, and various other advanced network scanners which provide reporting on the health and accessibility of a network.

Microsoft Exchange is now being used all across the globe to safeguard an email network and is one of the most-trusted and secure mail servers. Although Exchange provides a very secure platform for organisational and individual security over the Internet, it is still vulnerable to threats and attacks. The only way to stay safe is to keep updating the devices and configuring the system efficiently.

About The Author

2 thoughts on “Best and worst practices for Microsoft Exchange TLS and SSL”

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