Mike Stacy's Blog

Exchange UM Fails to Validate Certificate

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
Description:
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.

Exchange 2007 UM SIP Integration with Mitel 3300

Rather than individually send out this Mitel document to everyone that asks for it on the forums I figured I'd just post it here for people to download.  I don't claim that this is the latest version or that it is accurate for all versions, etc., but since this document seems to have avoided all known search engines I've attached it here.  Also be aware that Microsoft has some Mitel configuration notes for other connectivity options.

Download MitelTechNoteForExchangeUM

Exchange UM Certificates with OCS

While Exchange 2007's UM functionality is capable of integrating with OCS for voicemail, Exchange 2007 SP1 adds new options to more easily facilitate this integration.  The information to do so is outlined here.  As you can imagine, the certificate requirements add a new level of complexity for even experienced Exchange engineers.

When Exchange 2007 is installed, it generates a self-issued certificate for use with IIS, SMTP, and SIP (if you're using UM).  This certificate generally isn't ideal for Outlook and OWA clients because it's not trusted by any machines except for the Exchange server, and one of the first tasks to do is replace this certificate with one that is trusted by the user's machines.  Additionally, the certificate you use to replace it may not match the FQDN of the server since the server may be referenced by a more generic name (for example, mail.domain.com) to make it an easy to remember OWA address.  However, one of the requirements of UM/OCS connectivity is that the certificate used for UM exactly match the FQDN of the server so that MTLS is successful.  For MTLS to be successful, the certificate must be trusted by the OCS server(s).  This means you must either import the self-signed Exchange certificate to each OCS server or replace it with one that is trusted.  Most customers will want to use a certificate that is automatically trusted by OCS.  To do this, create a new certificate to be used by Exchange (outlined towards the bottom of this article) and then use the Enable-ExchangeCertificate cmdlet to assign it to the UM service.  Once this is complete and you've followed all the other steps for UM integration you should be all set.