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.