I’m building out our WAC server, and although the server appeared to be working correctly, it was constantly in an unhealthy state.
This can be checked by issuing the command:
Get-OfficeWebAppsMachine
I looked through several articles including the often referenced How to Get Office Web Apps Server 2013 to Report a Healthy Health Status and Office Web Apps Server 2013 – machines are always reported as Unhealthy. I’ve found that Wictor’s articles tend to have the level of detail that I prefer when trying to solve in the problem.
We were experiencing the exact issue that was reported with the Watchdog processes not establishing an SSL connection.
<HealthMessage>BroadcastServicesWatchdog_Wfe reported status for BroadcastServices_Host in category '4'. Reported status: Contacting Present_2_0.asmx failed with an exception: Could not establish trust relationship for the SSL/TLS secure channel with authority 'machinename.internaldomain.tld'.</HealthMessage>
Initially, we had a certificate issued by GlobalSign. Even though it was trusted it still wouldn’t work. For troubleshooting, I switched to a certificate which was issued by our internal CA – one that I knew would work.
I issued the certificate with the CN=webapps.ourdomain.com and the SAN=machinename.internaldomain.com.
In the past, I’ve never repeated the CN as a SAN.
Both of the articles mentioned having the domain listed as a SAN, but they didn’t explicitly mention needing in both the CN and SAN.
I went ahead and reissued my internal cert, and repeated webapps.ourdomain.com as both a CN and SAN. Lo and behold, the errors with SSL stopped.
Upon further research about the necessity of having a domain name repeated in both the CN and SAN, I learned that its often repeated for best practice for compatibility.
Viktor Varga summarized it very nicely in this Stack Exchange question: SSL – How do Common Names (CN) and Subject Alternative Names (SAN) work together?