Exchange 安全补丁一直打不上，会是什么问题呢（） _EXchange

枕上从妨一夜睡，灯前读尽十年诗。这篇文章主要讲述Exchange 安全补丁一直打不上，会是什么问题呢？相关的知识，希望能为你提供帮助。
背景公司使用的Exchange版本是2013，近几年随着漏洞的不断爆出，陆续升级cu，打exchange安全补丁，数不清多少个了。
【Exchange 安全补丁一直打不上，会是什么问题呢（）】但是从今年7月份发布的安全补丁KB5004778开始，补丁安装后会导致ecp管理后台登录失败，最终只能和安全同学协商，暂时不打，看看微软后续是否会有相关说明。
再到10月份的KB5007011，11月份的KB5007409, 打完后均导致ecp虚拟目录登陆失败。
11月份和360集团做了一次技术交流，交流中可以明显体会到他们对于安全这块的重视程度。对于重大安全问题都会即刻执行，甚至于停服。
11月9号，微软发布了KB5007409的漏洞修复补丁。 IT进行测试安装后，还是会影响ecp登陆。但是考虑到近几次安全补丁不能安装，甚至于以后发布的安全补丁可能都不会成功安装。决定一探究竟。
分析& 找解决方案先看下报错日志：

[Owa] An internal server error occurred. The unhandled exception was: Microsoft.Exchange.Diagnostics.ExAssertException: ASSERT: HMACProvider.GetCertificates:protectionCertificates.Length< 1 在 Microsoft.Exchange.Diagnostics.ExAssert.AssertInternal(String formatString, Object[] parameters) 在 Microsoft.Exchange.Clients.Common.HmacProvider.GetCertificates() 在 Microsoft.Exchange.Clients.Common.HmacProvider.GetHmacProvider() 在 Microsoft.Exchange.Clients.Common.HmacProvider.ComputeHmac(Byte[][] messageArrays) 在 Microsoft.Exchange.HttpProxy.FbaModule.SetCadataCookies(HttpApplication httpApplication) 在 Microsoft.Exchange.HttpProxy.FbaFormPostProxyRequestHandler.HandleFbaFormPost(BackEndServer backEndServer) 在 Microsoft.Exchange.HttpProxy.FbaFormPostProxyRequestHandler.ShouldContinueProxy() 在 Microsoft.Exchange.HttpProxy.ProxyRequestHandler.BeginProxyRequestOrRecalculate() 在 Microsoft.Exchange.HttpProxy.ProxyRequestHandler.InternalOnCalculateTargetBackEndCompleted(TargetCalculationCallbackBeacon beacon) 在 Microsoft.Exchange.HttpProxy.ProxyRequestHandler.< > c__DisplayClass3f.< OnCalculateTargetBackEndCompleted> b__3e() 在 Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(TryDelegate tryDelegate, FilterDelegate filterDelegate, CatchDelegate catchDelegate)

文章图片

网上确实有很多反馈该问题的，也都是从KB5004778开始。
装过这么多次补丁了，一直对安装补丁的方式还是非常了解的。但是既然出现问题，就会有一定的疑虑，是不是自己的操作流程有问题？
所以仔细查看官方的操作说明，有了些意外发现：官方给了一个修复后遇到问题的处理链接。

文章图片

打开链接后：
微软列出了各种可能遇到的错误及对应的原因和处理方式：

文章图片

文章图片

最终跳转到页面 https://docs.microsoft.com/en-us/exchange/troubleshoot/administration/cannot-access-owa-or-ecp-if-oauth-expired?preserve-view=true#resolution
可以看到：事件id和官方指出的错误是匹配的。但是日志详情是有很大差异的。网上也有用户，报错和我们不太一样，但是最终也是通过这篇文章介绍的方式解决的。原因就是oauth证书丢失或者过期导致。
再没有更好的其他解决方案的情况，我决定尝试一下。虽然有一些忐忑。
测试并在生产环境实施我们有Exchange测试环境，但是测试环境oauth证书是正常的，所以可以正常打补丁。为了和实际场景更接近，我把测试证书给删掉,证书名称为" Microsoft Exchange Server Auth Certificate" 。删除后在该机器打补丁，发现出现了和生产环境一样的现象，ecp登陆失败。
按照官方的操作[上诉的跳转链接] ，重新创建并发布证书。官方提示中，证书生效可能要在1个小时以上。因此，操作完后，我们并没有立即打补丁。而是等到第二天上午来到公司后，再打补丁测试。最终发现打补丁后，可以解决ecp登陆问题。

文章图片

在生产环境实施

因为这个操作是第一次操作，官方并没有说这种操作的影响面，比如是单台服务器，还是整个exchange组织。所以在生产环境配置还是冒着服务受影响的风险的。测试环境毕竟没有那么多用户，感知能力和现实不一样。
为此，我们新部署了一台exchange管理机(提供web管理)，如果影响单台服务器的话，我们还有另一台进行管理。
在新增的管理机上，执行如下操作：

# New-ExchangeCertificate -KeySize 2048 -PrivateKeyExportable $true -SubjectName "cn=Microsoft Exchange Server Auth Certificate" -FriendlyName "Microsoft Exchange Server Auth Certificate" -DomainName @()# Set-AuthConfig -NewCertificateThumbprint < ThumbprintFromStep1> -NewCertificateEffectiveDate (Get-Date) Set-AuthConfig -PublishCertificate Set-AuthConfig -ClearPreviousCertificate# stop-service -name MSExchangeServiceHost start-service -name MSExchangeServiceHost# iisreset /noforce

验证配置：