I recently came across an interesting issue when trying to integrate Lync Server 2010 with Exchange Server 2010 SP1 Unified Messaging.
The symptom was that, whenever we tried to transfer a call from the Auto Attendant to a Lync Server telephone extension, we would get two warning messages logged in the Application log on the Exchange UM server, that were similar to the following:Event 1079, MSExchange Unified Messaging The VoIP platform encountered an exception Microsoft.Rtc.Signaling.OperationFailureException: An exception was detected that the platform was not expecting. This may be because of abnormal shutdown, lack of resources, or failure of application code. —> System.Security.Cryptography.CryptographicException: Invalid provider type specified. Event 1136, MSExchange Unified Messaging An error occurred while transferring a call to “email@example.com”. Additional information: The call transfer type is “Blind.”, the transfer target is “phone number”, and the caller ID is: “6c53752d10394feeab50e8656010afdd”.
The first warning message was the key to our issue.
Some background information
When we created certificates for the Exchange UM and Lync servers, we did so using a modified Version 3 Web Server template from an Enterprise CA running Windows Server 2008 R2, Enterprise Edition.
Traditionally, Windows applications have used a cryptographic API called CryptoAPI. CryptoAPI makes use of providers called cryptographic service providers (CSPs). CSP’s typically implement cryptographic algorithms and provide key storage.
Windows Server 2008 introduced a new cryptographic API called Cryptography Next Generation (CNG). CNG is the long term replacement for the CryptoAPI. Unlike CryptoAPI, CNG separates cryptographic providers (algorithm implementation) from key storage providers (key storage). Key storage providers (KSPs) can be used to create, delete, export, import, open and store keys.
When you create a certificate for Exchange Server 2010 Unified Messaging with SP1, using a modified Version 3 Web Server template, it is quite possible that a KSP is used instead of a CSP. This is what happened in our case.
For the Unified Messaging server, this is not an issue because CNG support was introduced with Exchange Server 2010 SP1. Unfortunately, several applications, including Lync Server 2010, have issues with certificates created using a KSP.
Verifying the Issue
We ran the following command from an administrative command prompt on both the Lync and Exchange Unified Messaging servers:
certutil -store my
On the Lync server, the following output was produced:================ Certificate 0 ================ Serial Number: 1b89a124000000000029 Issuer: CN=Bongo Issuing CA, DC=internal, DC=bongo, DC=com NotBefore: 08/11/2011 5:54 pm NotAfter: 07/11/2013 5:54 pm Subject: CN=Lync.internal.bongo.com, O=Bongo Ltd, L=Bongoland, C=US Non-root Certificate Template: BongoWebServer, Bongo Web Server Cert Hash(sha1): 53 45 85 75 a3 dd 1f be ac 37 48 17 f5 5e cb 22 f3 e0 4a 1c Key Container = 34b04971930a70b4646b20c4c2d3adfe_8b81c452-42c5-4f2a-8549-934c5 c7bbda9 Simple container name: le-2edee22b-c80c-471e-b517-99b239557e05 Provider = Microsoft RSA SChannel Cryptographic Provider Encryption test passed CertUtil: -store command completed successfully.
On the Exchange Unified Messaging server, the following output was produced:================ Certificate 0 ================ Serial Number: 12d673a900000000002f Issuer: CN=Bongo Issuing CA, DC=internal, DC=bongo, DC=com NotBefore: 30/11/2011 5:13 pm NotAfter: 29/11/2013 5:13 pm Subject: CN=exum.internal.bongo.com, O=Bongo Ltd, L=Bongoland, C=US Non-root Certificate Template: BongoWebServer, Bongo Web Server Cert Hash(sha1): 58 ac 70 8d a0 ef c6 a1 eb 24 5d 1f 33 cc df d5 88 44 70 cf Key Container = a55403ffb55cfb95386e8826a1fa687e_88367876-51f5-48da-ad0f-1e2fb b955a2f Simple container name: CertReq-BongoWebServer-92f40563-8b2a-49b8-bf5f-6204287b69 dd Provider = Microsoft Software Key Storage Provider Encryption test passed CertUtil: -store command completed successfully.
Reissue the certificate on the Exchange Unified Messaging server, but explicitly specify:
Provider = Microsoft RSA SChannel Cryptographic Provider