Download Domains, CVE-2021-1730, and Microsoft Exchange Server Spoofing Vulnerability....

 https://www.reddit.com/r/exchangeserver/comments/onhchg/download_domains_cve20211730_and_microsoft/?rdt=64153

Done it back in March, no problems, virtually no downtime. Notes:

1. I hate their weird wording in that guide, it's potentially confusing. The writer was likely not fluent in English, and nobody copy-edited it. By "certified domain name" they mean "you need an additional name within the same DNS domain on which your OWA is served, and you need to expand the Exchange certificate to include it." Had multiple people be tripped up by that odd phrasing.

2. It doesn't need to be of the form download.mail.contoso.com; if you want, it can be whatever.contoso.com, at the same level as autodiscover.contoso.com etc -- for example, you could use d.contoso.com to shorten the URLs. Mostly an aesthetic choice, you can absolutely use their suggested scheme, as long as it doesn't complicate your cert issuance process since it's an additional subdomain level. Just needs to be different from the hostname in the URL from where OWA is served, so that the cookies from the DownloadDomain-served resources aren't valid for the main OWA resources. Just don't use the root domain name, obviously :)

3. You will need to reissue and install your Exchange client-facing certificate to include the new name, unless you were using a wildcard certificate for *.contoso.com -- but I wouldn't recommend wildcard certs on an Exchange CAS role in the first place, and be aware that the * in *.contoso.com for wildcard certs does not match subdomains -- i.e. it'll match a.contoso.com but not b.a.contoso.com.

4. Operationally, mostly just like any other Exchange CAS role cert renewal.

5. No need to reboot the server; in fact, it's utterly stupid that they would suggest that. You just need to recycle (or stop/wait 10 seconds/start) the MSExchangeOWA app pool on the CAS roles. 10 second downtime, versus however much downtime a full reboot is. And you don't lose the hot caches this way either.

6. Whether you need to create both external and internal names and certs depends on your DNS and network setup and on exactly how your clients hit the CAS role, there's no right or wrong answer. I always try to keep internal and external names identical by using split horizon DNS, so I set them to the same value, and I use the same certificate for both types of client traffic flows since it's the same name. If it helps, you can think of it just like another TLS-enabled IIS vhost, which just happens to be managed by Exchange.

7. No problems encountered.

8. If things go wrong, you can always turn it off and restart the app pool. No biggie.

9. To double-verify it works, apart from their (correct) suggestion to inspect the URL, you can also look at the server response for resources served from DownloadDomains and check the cookie (use a fresh browser profile for that, or a Guest profile, obviously, to avoid caching surprises.) It should not be valid for mail.contoso.com, contoso.com, and .contoso.com (evidently, adjust as per your setup and URL structure.) See the standard rules on how browsers restrict cookie applicability. It's not necessary as such, but I like to doublecheck; they have... some... history of implementing half-assed fixes which don't fully work.

Edit: Some additions, and one correction (app pool restart).