On our new Office Web Apps installation, I was seeing errors in the event viewer repeating every few minutes such as

Faulting application name: SandboxHost.exe, version: 15.0.4502.1000, time stamp:
0x512d262b
Faulting module name: KERNELBASE.dll, version: 6.3.9600.17278, time stamp:
0x53eebf2e

I applied each of the April, May, June and July Cumulative updates, and each time hoped that they would solve the problem. They didn’t.

The key here was taking a closer look at the ULS logs, which have additional detail. This log can be found (default) at C:\ProgramData\Microsoft\OfficeWebApps\Data\Logs\ULS

I found a corresponding entry which provided the hint to the real problem

Failed to launch sandbox process, SE_ASSIGNPRIMARYTOKEN_NAME
and SE_INCREASE_QUOTA_NAME privileges are required

This error is typically seen in Sharepoint installations, but the root cause is the same. The service account which is running doesn’t have the necessary permissions.

Office Web Apps uses the LocalSystem account by default. I had changed this to a specialized service account which had permissions into Sharepoint Content databases, in order to isolate a different problem related to Web Apps not working on Sharepoint personal sites.

As a result, it didn’t have the required permissions.

Utilizing this article at Al’s Tech Tips, I made the appropriate changes to the Local Security Policy. Whereas his article talks about the service account running the Sharepoint User Code Host, the one we are concerned about with Office Web Apps Server is Office Web Apps (WACSM)

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?