Last week I hit an issue where Play on Phone was not working. After entering the phone number in the appropriate field, Outlook would try for 30 seconds and then give the generic error indicating that it could not connect to the UM server. As a starting point I checked the URL that was being sent to the client (https://<CAS URL>/unifiedmessaging/service.asmx) to ensure there were no connectivity or certificate issues. Everything checked out fine there.
Next I looked at the UM server and found an event 1113 with the following description:
The Unified Messaging server failed to exchange the required certificates with an IP gateway to enable Transport Layer Security (TLS) for an incoming call. Check that this is a configured TLS peer and that the correct certificates are being used. More information: A TLS failure occurred because the certificate that was presented by the remote server is not trusted. The error code was "-2146762487" and the message was "A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider".
This particular customer has separate servers for the mailbox, hub transport, CAS, and UM roles. Since the client connection goes through the CAS server this would indicate that the UM server was rejecting the certificate that was presented by the CAS server. A quick check of the certificates on the CAS server via get-exchangecertificate showed the certificate that we expected, and we could successfully browse to the same /unifiedmessaging/service.asmx URL from the UM server without any issues. A netmon trace further confirmed that the certificate presented to the UM server was the one we expected. Despite all this, the CAS server insisted that it was not able to find a valid UM server:
Event Type: Warning
Event Source: MSExchange Unified Messaging
Event Category: Shell
Event ID: 1083
The Unified Messaging Web service was unable to process a "PlayOnPhone" request for user "Doe, John". The error was "A valid Unified Messaging server could not be found for dial plan NorthAmerica.".
Since the CAS server was configured with a Verisign certificate this really didn’t make sense, but for the sake of completeness I checked each certificate in the chain and verified that it existed in the UM server’s local computer certificate store. What I found was that the Verisign root certificate was indeed in the Trusted Root Certification Authorities store but the intermediate CA, from which the CAS server’s certificate was issued, was not in the Intermediate Certification Authorities store. This didn’t seem to cause any problems from IE but just to be safe I added the intermediate certificate into the store. Sure enough, this caused UM to begin accepting the connections from the CAS server.
I haven’t had a chance to research whether or not this is documented/expected behavior but it’s certainly interesting to note this, especially as certificate vendors are beginning to use new 2048 bit based CAs.