
Last month I was asked to perform a Cutover migration from Exchange Server 2007 to Exchange Online on Office 365. After I created the Migration Batch on Exchange Online, I got an error about the SSL/TLS certificate of Exchange Server 2007. Although I could not find any relevant information on Microsoft Docs, it appears that the version of TLS in Exchange Server 2007 is 1.0, which is considered deprecated by Exchange Online and, thus, not supported. However, I found no way to upgrade to TLS 1.3 so that the Cutover migration work for my case.
So, my idea was to put an SSL offload mechanism in front of Exchange Server 2007, that would provide TLS 1.3. At first, after some internal discussions, we considered to use Nginx as a reverse proxy, but this feature is included on the paid version, Nginx Plus. Our next option was HAProxy. So, we created a Linux VM on Azure, allowed incoming HTTPS traffic and configured HAProxy. There are some requirements though. First we needed a valid FQDN on a custom domain. Second, a valid SSL certificate for this FQDN. And third, an Azure VM (or a Linux server) with a static IP address.
For the FQDN you have to own a domain name and be able to edit the DNS zone. Let’s say this domain is ctlab.gr . We created an A record in DNS zone with the public static IP address of the Linux VM on Azure. You may wonder why we don’t use the FQDN of the Azure VM that Azure already provides, which is in the FQDN form of myhaproxyonazure.westeurope.cloudapp.azure.com . While this is true, Letsencrypt will deny to create a certificate for this FQDN. This is the reason we need to have a custom domain and to be able to manage the DNS zone.
As already mentioned, for the SSL certificate we used Letsencypt. Letsencrypt allows SSL certificate creation either through Web Hosting provider’s portal, or by using a piece of software called Certbot. There are customized instructions for Certbot’s installation and usage. Make sure you have stored the certificate in a path inside Linux VM, like /etc/letsencrypt/live/clientowa.ctlab.gr/ctlab.crt .
Now you need to install and configure HAProxy. It is recommended to use the method that your Linux distro provides. After successfuy installing it, make a backup of the configuration file and replace it with the following.
global chroot /var/lib/haproxy pidfile /var/run/haproxy.pid maxconn 65000 user haproxy group haproxy daemon log 127.0.0.1 local0 tune.ssl.cachesize 100000 tune.ssl.lifetime 600 tune.ssl.maxrecord 1460 tune.ssl.default-dh-param 2048 defaults log global option httplog option dontlognull mode http retries 3 timeout http-request 1m timeout queue 2m timeout connect 1m timeout client 15m # this value should be rather high with Exchange timeout server 15m # this value should be rather high with Exchange timeout http-keep-alive 15m timeout check 30s option redispatch option forwardfor option http-server-close listen stats bind 127.0.0.1:9000 stats enable mode http stats uri /stats stats auth admin:MySuperPassword frontend https-in bind *:443 ssl crt /etc/letsencrypt/live/clientowa.ctlab.gr/ctlab.crt http-response set-header X-Frame-Options SAMEORIGIN http-response set-header X-Content-Type-Options nosniff default_backend ms_backend backend ms_backend balance roundrobin server server1 owa.mycustomer.com:443 check maxconn 5000 force-tlsv10 ssl verify none http-request set-header X-Forwarded-Port %[dst_port] http-request add-header X-Forwarded-Proto https if { ssl_fc }
Note that:
- /etc/letsencrypt/live/clientowa.ctlab.gr/ctlab.crt is the path to your Letsencrypt certificate
- owa.mycustomer.com is the FQDN of your Exchange Server 2007 OWA (Outlook Web App) URL.
Then, restart (or start if already stopped) the HAProxy daemon.
As a last step, go to Exchange Online (Office 365) Administrative Center and create a new Cutover migration batch. Make sure that instead of the OWA URL of your Exchange Server 2007, you should provide the URL of your HAProxy; in our example, clientowa.ctlab.gr . The logical connection diagram should be similar to the one below.

Exchange Online should notice no issues and will be as happy as if it was connected directly to a modern Exchange Server with TLS 1.3 . In our case, we managed to migrate flawlessly all the mailboxes of the clients, even some really big ones.
One thing you should take into serious consideration, is that the Exchange Server owner should be aware about this routing, since technically speaking, the root user on the Linux VM could capture this traffic and actually see the contents of the mailboxes being transferred. This is more of a law issue rather than a technical one, but still it should be part of the things that your clients should know about.