Polycom CX700 – certificate issue

At many clients I used and installed the Polycom CX700 (aka “Tanjay”) device succesfully. However, during my latest project, it was not that easy. As with every implementation, DNS and WINS were updated for the Device Updater, and DHCP reservations were created for the Polycom device.

After installing the update succesfully, I tried to log on to the tanjay device. Using the domain FQDN, it accepted the credentials and started the logon procedure. It is important to understand the procedure the Office Communicator Phone Edition will follow during the log on proces;

• locating domain controller, based on input information
• download the root certificate
• install the root certificate
• connect to the OCS pool / sip domain, based on input information
• authenticate to the OCS pool
• log on

There are many blogs out there about configuring your environment to get these devices up and running.

However, in this particular case, when trying to log on on the phone it showed the following status updates in a loop;

·         Locating Domain Controller

·         Downloading Certificate

·         Installing Certificate

·         Connecting to office communications Server

This ofcourse is abnormal, it should just log on. And as the OCS environment was all OK and both software and hardware devices were communicating properly, I must have overlooked something.

After a logn resarch, I found only mino facing the exact same problem. and bingo! the root certificate of this particular company was SHA2 @ 4096 bits. As the Polycom CX700 runs Office Communicator Phone Edition, it runs on Windows CE. And Windows CE isn’t able to read these kind of strong certificates!

The solution of mino is ofcourse a very valid one, but this company didn’t want to have its PKI infrastructure aqdapted to the requirements, and installing a new one was also a no-go. But, in this case, there was a much, much easier solution!

As I installed the full set of servers and features of OCS at this client, it also featured remote user access. When you think of it – it uses different certicates, only the public ones. And these happened to be at the lower SHA1 @ 2048 bits level! a simple – but effective – trick solved our problem.
We just adjusted the DHCP reservation for this Polycom CX700 device with public DNS servers, instead of the internal ones. This tricked the CX700 to use the external DNS, which of course could only resolve the external DNS queries. And this resolved the problem, as it would connect to the external interface of the edge server, using the public certificates, on a supported PKI infrastructure.

After this change and a reboot of the device, it was able to log on succesfully, and the full feature set was available again. Happy ending after all 🙂