Today Microsoft silently released an update to their Exchange roadmap, which includes information regarding Exchange 2019 CU15 and Exchange vNext. You can read all the Microsoft marketing stuff on the Exchange Server Roadmap Update article.
What’s new is that vNext is rebranded to Exchange Server Subscription Edition, just like we have Sharepoint Subscription Edition.
The most important part about Exchange Server Subscription Edition is that it is ‘code equivalent’ to Exchange 2019 CU15. So, if you have Exchange 2019 CU15 running later this year, then updating to vNext is just a matter of an in-place upgrade. There’s one thing we need to look out for, the underlying Operating System. If you install CU15 on Windows Server 2022 (or worse, on Windows Server 2019) and SE only supports Windows Server 2025 we will be very unhappy 🙂
What are new features in Exchange 2019 CU15 and thus Exchange Server SE?
Support for TLS 1.3 (which was planned for CU14).
Certificate management in the Admin Center.
Removal of the UCMA (makes sense, since there won’t be any support for Unified Messaging.
Removal of the MSMQ components in the setup application (MSMQ components are not needed in earlier versions of Exchange 2019, please check the Exchange 2019 requirements article).
Re-introducing certificate management in the Admin Center.
So, when can we expect Exchange Server Subscription Edition? As Exchange Server SE is identical to Exchange 2019 CU15 (in will include the necessary security updates of course) the only difference is the licensing of Exchange Server SE. You need a subscription license for the server, and old Client Access Licenses are no longer supported and you can use the regular Office 365 licenses for clients.
Microsoft states it will be available early Q3 2025, which means early July 2025. Since support for Exchange 2016 and Exchange 2019 will end in October 2025 Microsoft cannot afford to slip this date since you need sufficient time to upgrade from earlier versions of Exchange server.
What’s also interesting is that Microsoft is already releasing information about Exchange Server SE CU1, which should be released by the end of 2025 (can slip though).
The most interesting features in Exchange Server SE are Kerberos authentication for server-to-server authentication, the removal of Outlook Anywhere and the deprecation of Remote PowerShell. This brings Exchange server SE nicely inline with Exchange Online.
There’s one very important announcement Microsoft makes: Exchange server SE CU1 will stop supporting co-existence with ALL PREVIOUS VERSIONS of Exchange server. So, this means that in that timeframe, only Exchange Server SE CU1 (and later) will be supported and all previous versions of Exchange server must be removed from your environment.
Exchange Server SE is still approx 18 months away from now, but it is time to start thinking about your Exchange environment. Do you want to fully move to Exchange Online, or do you want to keep mailboxes on-premises in Exchange Server? If so, it’s time to start working on moving to Exchange 2019 CU14 and upgrade to CU15 later this year (or skip CU14 and move directly to CU15).
It is not a strange idea, I’m currently working with three large Exchange 2016 on-premises deployments to move them to Exchange 2019 and prepare for Exchange server SE.
Wait, what? On April 23, 2024 Microsoft has released a hotfix update for Exchange 2016 and Exchange 2019 and as MVP’s we only learned about this last week.
A hotfix update or HU contains fixes for issues that might arise with a security update in Exchange server. For example, the March 2024 SU for Exchange server introduced a number of issues, and these are fixed with this HU. Besided hotfixes, a HU can also contain new features that did not make it in the last security update (SU) or Cumulative Update (CU). In this HU for example, Hybrid Modern Authentication for OWA and ECP is introduced as a new feature. Another new feature introduced in this HU is the support for ECC (Elliptic Curve Cryptography) certificates. ECC certificates however are not supported for the federation trust certificate, the Exchange server OAuth certificate and ECC certificates cannot be used when ADFS claims-based authentication is used.
The following issues are fixed in this HU:
“We can’t open this document” error in OWA after installing March 2024 SU
Search error in Outlook cached mode after installing March 2024 SU
OwaDeepTestProbe and EacBackEndLogonProbe fail after installing March 2024 SU
Edit permissions option in the ECP can’t be edited
Outlook doesn’t display unread message icon after installing Exchange Server March 2024 SU
My Templates add-in doesn’t work after installing Exchange Server March 2024 SU
Download domains not working after installing the March 2024 SU
You can download this hotfix update for Exchange server here:
Be aware that the filename for all versions of this HU is the same (Exchange2019-KB5037224-x64-en.exe) so when downloading multiple versions make sure you store them at different locations.
A hotfix update is cumulative and includes all security features and fixes from the previous security updates. When running Exchange 2019 CU14 and you have not installed the March 2024 security update then there’s no need to install this first. Just continue with the immediate installation of this HU.
On February 13, 2024 Microsoft has released a new Cumulative Update for Exchange 2019, the 2024 H1 Cumulative Update (or CU14). One major ‘new’ feature and some minor features.
Extended Protection
One of the interesting things in this update is that it by default enables Extended Protection on all virtual directories of your Exchange 2019 server.
Extended Protection is an enhancement on the existing Windows Authentication. Extended Protection mitigates authentication relay or ‘man in the middle’ attacks. It is implemented by using channel binding information using a Channel Binding Token (CBT). There’s no need to configure anything, Extended Protection is automatically configured by the CU14 setup. It is a per server setting, so it is only enabled on the server you have installed CU14 on.
If you want to install CU14, but you environment does not meet the prerequisites, you can install CU14 unattended with the /DoNotEnableEP or /DoNotEnableEPFEEWS (EPFEEWS is Extended Protection FrontEnd EWS) switch.
Please be aware that this is not the recommended approach. The recommended approach is to prepare your environment for Extended Protection, enable it on older server and then install CU14 with automatic enabling Extended Protection.
TLS 1.3
Unfortunately TLS 1.3 (which is supported on Windows 2022) did not make it in this update, and is now scheduled to be included in CU15 (2024 H2 Cumulative Update, so by the end of this year).
CVE-2024-21410
CVE-2024-21410 was also released today, and this CVE is addressed in CU14 by Extended Protection. This is also true for Exchange 2016 CU23 (EP was introduced in an earlier Security Update for Exchange 2016).
Installing Exchange 2019 CU14
CU14 does not come with an Active Directory Schema update; the Schema is still at version 17003. The Exchange configuration version is increased by one (now 16762) and the Domain version has not changed (still 13243).
Use the following commands to upgrade the Configuration and Domain Partition in your environment:
You’ll notice the following output on the console:
Exchange Setup has enabled Extended Protection on all the virtual directories on this machine. For more information visit: https://aka.ms/EnableEPviaSetup.
We recommend running Exchange HealthChecker script to evaluate if there are any configuration issues which can cause feature breakdowns. HealthChecker script can be downloaded from https://aka.ms/ExchangeSetupHC.
At this point, nothing has changed on the virtual directories of your Exchange server so the information is not needed at this point. Running the HealthChecker script is always a good thing before running any upgrade. When using the unattended upgrade, use the following command:
Knowledgebase article KB5035606 contains more information, including known issues with this release.
Before bringing in production, please test thoroughly in your test environment.
The only supported versions of Exchange 2019 are Exchange 2019 Cumulative Update 14 and Cumulative Update 13. Earlier versions are no longer supported (and no longer receive Security Updates)
Exchange 2013 is old, and out of extended support. No more Security Updates will be released for Exchange 2013. If you are still running Exchange 2013, make sure you migrate to Exchange 2019 or Exchange Online anytime soon!
Exchange 2016 is out of mainstream support, which means that Microsoft will no longer release new Cumulative Updates for Exchange 2016. Security Updates will be released until Extended Support for Exchange 2016 ends.
My previous blogpost was about DANE and discussed how DANE can be used to make TLS negotiations between mailservers more secure. Another topic in this area is MTA-STS. MTA-STS stands for Message Transfer Server – Strict Transport Security and MTA-STS is a mechanism to enforce the use of TLS and the use of a valid 3rd party server certificate.
MTA-STS, DNS and Policies
When an MTA-STS capable servers wants to send an email, it first retrieves the MX record for the recipient domain. The second step is that the sending server check for an MTA-STS record in DNS. This record looks like:
_mta-sts.exchangelabs.nl. IN TXT "v=STSv1; id=202306242147;"
The id is an identifier and defines the version of the MTA-STS record when changes are made to the MTA-STS record. A good practice is to create an identifier based on the date and time of the last change. In this example, it is June 24, 2023 at 9:47pm.
The next step is that the sending servers looks for a policy. This policy is not stored in DNS, but on a website. The URL for this policy looks like: https://mta-sts.exchangelabs.nl/.well-known/mta-sts.txt. The subdomain mta-sts, the filename mta-sts.txt and the directory .well-known (including the dot) directory are mandatory for the MTA-STS policy. It must also be secured using a valid 3rd party server certificate.
Note. If you have configured DANE for inbound email in Exchange Online, your MX record should be something like Exchangelabs-nl.y-v1.mx.microsoft.
The MTA-STS policy is structured as follows:
Version identifies the version of MTA-STS but must always be STSv1 (for now at least).
Mode defines how the policy must be applied:
Enforce: Sending MTAs MUST NOT deliver the message to hosts that fail MX matching or certificate validation or that do not support STARTTLS.
Testing: Sending MTAs that also implement the TLSRPT (TLS Reporting) specification [RFC8460] send a report indicating policy application failures (as long as TLSRPT is also implemented by the recipient domain); in any case, messages maybe delivered as though there were no MTA-STS validation failure.
None: In this mode, Sending MTAs should treat the Policy Domain as though it does not have any active policy.
MX defines all MX records in use by the recipient domain. This can be one entry, but it can hold multiple MX records, each on a separate line as shown in the policy above.
Max_age defines the time (in seconds) that the MTA-STS policy can be cached by a mail server. In this example, the policy is cached for 604800 seconds, which equals to 1 week. When a sending server must send a new email within a week, the policy is still cached. After checking the MX record the server retrieves the TXT record from DNS (as explained in the second step above) and when the identifier has not changed it uses the policy that is cached. If the identifies has changed within the lifetime of the cached policy, a new policy is downloaded.
So, in my example an MTA-STS capable mail server will check the MTA-STS policy and only connects to my mail server using TLS 1.2 (this is enforced with MTA-STS when mode is set to ‘enforce’) and only when a certificate that matches the FQDN is used. When authentication fails for an entry, the sending server continues with the next line in the policy, in my example with the MX record pointing to Exchange Online.
An interesting option in MTA-STS is reporting. DMARC has a reporting function as well, but reports are only sent by receiving domains. Reporting in MTA-STS is performed daily by sending mail servers that supports MTA-STS and TLS-RPT.
To configure the reporting functionality, create a mailbox in Exchange 2019 or Exchange Online and assign it an email address like TLSReports@Exchangelabs.nl. The next step is to configure the following DNS TXT record:
_smtp._tls.exchangelabs.nl. 3600 IN TXT v=TLSRPTv1;rua=mailto:TLSReports@exchangelabs.nl
There are several online tools available for checking the MTS-STS record. Just like in my other blogs, I often use MXToolbox to check for DNS records as shown in the following screenshot:
The first one is obvious, the second line is a Microsoft IP address, the third line is a Yahoo IP address. So, Google, Microsoft and Yahoo are using MTA-STS when sending email.
MTA-STS versus DANE
MTA-STS and DANE share a common concept, that is to secure the (initial) communication between mail servers. The ‘problem’ with DANE is that is relies on DNSSEC and the global roll-out of DNSSEC is very slow (to put it mildly).
MTA-STS was developed to overcome the slow roll-out of DNSSEC (since it does not use DNSSEC of course). MTA-STS can be seen as a ‘light-weight’ version of DANE and it will be sufficient for most customers.
And how about Exchange?
Just like with DANE, the ugly part is that Exchange 2019 does not support MTA-STS. You can configure the MTA-STS record in DNS and the policy on a website so that MTA-STS capable servers use your Exchange 2019 server safely. But for sent messages by Exchange 2019, MTA-STS is a no-go, it does not support it and most likely will never do.
Exchange Online on the other hand does support MTA-STS (since the beginning of 2022) for both inbound and outbound messages. The only thing you must do to enable it for inbound messages is create the TXT record in DNS and create and publish the MTA-STS policy.
In the past I have written about SPF, DKIM and DMARC for email authentication in Exchange server to improve e-mail security. Additional topics to improve security are secure DNS (DNSSEC) and DNS-based Authentication of Named Entities (DANE). Where SPF, DKIM and DMARC are focusing more on the email messages and the sending hosts they are coming from, is DANE more focusing on setting up the TLS connection between mail servers. DANE has a dependency on DNSSEC but since my focus is on Exchange and Exchange Online, I don’t discuss DNSSEC and leave that to my provider (DANE only works when DNSSEC is enabled).
When two mailservers setup a connection, they negotiate a common TLS protocol and this handshake as it is called is unencrypted. As such, this handshake is vulnerable for man-in-the-middle or downgrade attacks.
DANE is using a special DNS record (a TLSA record, Transport Layer Security Authentication) where an organization can publish information regarding the certificate on the mail server and thus the TLS options available.
The TLSA record for my own domain is shown in the following example:
_25._tcp.smtphost.exchangelabs.nl IN TLSA 3 1 1 50167c478a2f536a88ee9ec232b14b0d223c2d5bdc837451eee104c153376cbe
When a mailserver wants to send email to my Exchange environment it retrieves the MX record first which is smtphost.exchangelabs.nl (this is an Exchange 2019 Edge transport server, with a Digicert certificate that matches the servername). When DNSSEC is not used at the recipient domain, opportunistic TLS is used. When DNSSEC is used at the recipient domain, a DANE capable mail server will check for a TLSA record.
When a TLSA record is found and retrieved, the sending server sets up a TLS connection with the receiving server, which in turn returns the fingerprint of the certificate. The sending server compares the fingerprint with the information found in DNS and when it matches, the connection is established and communication between the two servers continue, and the email is sent.
So, how do you create the TLSA record? There are publicly available webservers that can create TLSA records. Shumon Huque is a software engineer and technologist based in Washington DC who has a site that can generate TLSA records. As a bonus his site can also check TLSA records.
To generate a new TLSA record, navigate to his website on https://www.huque.com/bin/gen_tlsa and fill out the necessary information as shown in the following screenshot:
The easiest way to create a PEM format X.509 certificate is using the MMC certificate snap-in. Select your certificate and export it. Select the ‘No, do not export the private key’ option, select the ‘Base-64 encoded X.509 (CER)’ option and export the certificate. You can use Notepad to open the certificate export, and copy-and-past this into the PEM format X.509 textbox.
Select the port number (25), the protocol (TCP, not SMTP) and enter the domain name. This is the FQDN of the receiving server, so in my example it is smtphost.exchangelabs.nl and click Generate.
It will show the generated TLSA record, including the certificate information as shown in the following screenshot:
For my domain the following TLSA record is generated:
_25._tcp.smtphost.exchangelabs.nl. IN TLSA 3 1 1 a63d74fc7ec1acad702017d13479a1b60b36f234ccb96b90f97c9619ba2c91ab
How is this TLSA record structured?
TCP port 25 and the FQDN of the server make up the first part of this TLSA record.
The first number after the TLSA text is the certificate verification or the certificate usage on the server and this number can have 4 values:
0 – CA Constraint. The certificate provided when establishing the TLS connection must be issued by the listed root-CA or one of its intermediate Certificate Authorities.
1 – Service Certificate constraint. – The certificate used must match the TLSA record, and it must also pass the certification path validation to a trusted root-CA.
2 – Trust Anchor Assertion. The TLSA record must match the certificate of the root CA, or one of the intermediate CAs of the certificate in use by the mailserver.
3 – Domain Issued Certificate. The TLSA record matches the used certificate itself. The certificate does not need to be signed by other parties and as such a self-signed certificate can be used (this is interesting on an Exchange server).
In my TLSA record a value of 3 is used for the certificate usage, so the TLSA record must match the certificate on the Exchange 2019 server.
The second number that is used is the selector. The selector can have two values:
0 – The entire certificate is used for matching.
1 – Only the public key of the certificate is used for matching.
In my TLSA record the value is 1 for the selector, so only the public key is used.
The third number that is used is the matching type. The matching type can have three values:
0 – the entire information select is present in the certificate associated data (the last text string in the TLSA record)
1 – The SHA-256 hash of the public key of the certificate must match the certificate associated data.
2 – The SHA-512 hash of the public key of the certificate must match the certificate associated data.
In my TLSA record a value of 1 is used for matching, to a SHA-256 has of the public key of the Exchange server certificate must match the data in the TLSA record.
The next step is to add the generated TLSA record in DNS and check the TLSA record once added.
You can use the same site (https://www.huque.com/bin/danecheck-smtp) to check the TLSA record. The site queries the MX record for your domain and checks the accompanying TLSA record. The result is shown in the following screenshot:
In this blog I am discussing DANE for mail server, but it can also be used for other services. For a website a TLSA record can be:
_443._tcp.www.exchangelabs.nl. IN TLSA 3 1 1 a63d74fc7ec1acad702017d13479a1b60b36f234ccb96b90f97c9619ba2c91ab
Or for IMAP it can be:
_995._tcp.mail.exchangelabs.nl. IN TLSA 3 1 1 a63d74fc7ec1acad702017d13479a1b60b36f234ccb96b90f97c9619ba2c91ab
The ugly part is that Exchange 2019 does not support DANE out of the box. For incoming mail, you can configure the TLSA record based on the certificate that is installed on the Exchange (Edge Transport) server. A DANE capable mail server automatically checks for a TLSA record and when available, use this to setup the TLS connection.
Exchange Online on the other hand only supports DANE for outbound connections at the time of writing. As an Exchange Online customer, there’s nothing you must configure, it’s available for everyone. DANE for inbound mail will become available in the future, but when is unclear. According to Microsoft it is ‘near future’ but unfortunately this is already the case for quite some time.
One final (and very important) closing note: When you have configured a TLSA record for your (inbound) Exchange server you MUST update your TLSA record when renewing the Exchange certificate. You must also do this when the Exchange server is used in a hybrid configuration, since Exchange Online will check for a TLSA record. Mail flow from Exchange Online to Exchange 2019 will halt and the following error message is shown in Exchange Online message trace:
Reason: [{LED=450 4.7.323 tlsa-invalid: The domain failed DANE validation [Message=450 4.7.323 tlsa-invalid: The domain failed DANE validation] [LastAttemptedServerName=smtphost.exchangelabs.nl] [LastAttemptedIP=185.116.41.45:25] [SmtpSecurity=11;-1] [HE1EUR01FT069.eop-EUR01.prod.protection.outlook.com 2023-06-06T10:23:06.0. OutboundProxyTargetIP: 185.116.41.45. OutboundProxyTargetHostName: smtphost.exchangelabs.nl
This is solved when a new TLSA record is generated and published in DNS.
Jaap Wesselius 
You must be logged in to post a comment.