I experienced issues intermittently when I rebooted an OCS front-end server where it would make an attempt to bind the SSL cert but fails to do so. This causes all the services that relies on the IIS website to fail. In the case of this client, this was the “Address Book Server”.
After working with Microsoft’s partner forum support with Paolo, I was told that in order to fix this, all I had to do was log onto the server, go into the bindings for the website and select the cert as it was empty.
Reviewing the logs shows the following 2 errors:
A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x80090011.
Followed by this one:
A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x8009030d.
After some troubleshooting, it was suspected that this error is caused by one of the private key that is bound to the certificate was corrupted for some reason. I went ahead and tried to export and re-import the certificate. When this didn’t fix the problem, I went ahead and deleted the cert and reissued it. As none of these fixed the issue, I made a deeper look into the event logs and found this error:
After a bit more research it was found that this was a result of some service trying to access the certificate machine store during a time when IIS was trying to bind the certificate which caused a handle leak. This results in the OCS service not able to load certificate and its private key correctly. Unfortunately, the problematic process is the lsass.exe which is a basic windows service and it could be called by any application.
One of the ways to try and prevent this from happening is to set the service “rtc” to depend on the “KeyIso” service so it will make an attempt to load the certificate when it’s available. The command to do this is the following:
sc config rtcsrv depend= WinMgmt/KeyIso/WmiApsrv/rasman
The default behavior when the error mentioned at the top is supposed to restart automatically where the second trial is most likely to succeed and will allow the IIS site to be fully functional.