May 2017 .Net Update may break Lync / Skype for Business

May 2017 .Net Update may break Lync / Skype for Business

Im Gegensatz zu sonst hier mal ein ziemlich technischer Post auf Englisch - aber das ist ein wichtiges Thema, das sonst noch nirgends im Netz zu finden war und das wir deshalb den Kollegen "in aller Welt" nicht vorenthalten wollten. Also alle "Enduser": Einfach ignorieren 🙈🙉🙊😉

When testing the May 2017 Updates for deployment, we noticed that our S4B-Frontend-Server could not create a connection to the Edge-Server.

Every Minute, it tried to connect and immediately disconnected:

After uninstalling the updates and rebooting, everything was fine again ...

OK, off to technet and the Update-descriptions - KB 4014597 has a small, important piece of information:

This security update for the Microsoft .NET Framework resolves a security feature bypass vulnerability in which the .NET Framework (and the .NET Core) components don't completely validate certificates.

To make a long story short: this update enhances the certificate verification of .Net to honor the "EKU" (Enhanced Key Usage) Field of certificates. This field describes for what the certificate may be used.
If you did like us (and probably most installations out there) and used the S4B Deployment wizard and an internal CA to create the INTERNAL certificates - you will find that they used the "Webserver" certificate template and this only includes the EKU "Server authentication":

Certificates on our server - the ones "issued by" CA are from our internal CA

So, these certificates cannot be used to authenticate a client to a server - but exactly that happens when S4B does MTLS (Mutual TLS - the client authenticates the server AND vica versa).

As the certificate verification fails, S4B immediately disconnects. Also note that it does NOT display any helpful logs (or at least we didn't find them in the logging tool).

So, what can you do?

1. do NOT yet install the Update on your Lync / S4B-Servers. Note that will not help very long, as these updates are cumulative, i.e. next month will be the same problem
2. activate the workaround to disable the new behaviour (yes, they actually realized that this was breaking backwards compatibility and provided a workaround via registry)
   HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework\v4.0.30319@RequireCertificateEKUs=0
   Not what I would recommend, but certainly a quick fix to get your server running again if you already installed the update and cannot roll back and cannot do 3.
3. the recommended fix: duplicate the Webserver certificate template on your internal CA, add the EKU "Client authentication", make this new template available for clients and re-issue the internal certificates - they will look like the one with the red border then.
   Afterwards, deploy the new certificate(s) to all Lync / S4B-Servers and assign them (via Powershell / Deployment Wizard)

Now, I know that 3. may take time, especially in companies where CA and S4B are managed by separate teams - this is why 2. will be an option. Just remember that this change in behaviour of .Net will probably affect other apps as well - as soon as they accept client certificates they could come crashing down. But now you know the secret and may be the hero to save the day 😎