I'm having some difficulty using HTTPS for phone books coming from TMS.
As long as I don't require SSL in IIS, the phone book is downloaded from TMS successfully. However, if I enable the "Require SSL" setting, the codecs are no longer able receive the phone book.
A couple of potential obstacles that come to mind:
- DNS is not available on the VLAN where the C-series codecs are connected, so I must use the server's IP address rather than hostname in the phone book URL. However, the SSL certificate is signed using the server's hostname.
- The SSL certificate on the TMS server is signed by our company's CA, not an external CA. I'm not sure if I need to upload a "Trusted CA list" (PEM format) and if so, how to generate the file.
But this makes me wonder, since the phone book evidently is capable of being downloaded via HTTPS, what is it about requiring SSL that is causing a problem?
Go into the codec, check or change the external manager to use HTTPS if it isn't already set to that. If it's on HTTP than it won't work when trying to communicate to TMS that is set to send via HTTPS.
Thanks for the quick reply - here are the ExternalManager settings - it is already set to HTTPS:
|Provisioning ExternalManager Address||TANDBERG C-series Endpoint|
|Provisioning ExternalManager Path||TANDBERG C-series Endpoint||tms/public/external/management/systemmanagementservice.asmx|
|Provisioning ExternalManager Protocol||TANDBERG C-series Endpoint||HTTPS|
|Provisioning HttpMethod||TANDBERG C-series Endpoint||POST|
|Provisioning Mode||TANDBERG C-series Endpoint||TMS|
Interesting don't know then.
Can TMS communicate with the codec for management over HTTPS?
Is it just the phonebook that is affected?
Yes, TMS management over HTTPS works fine. (I have HTTP disabled on the codecs.)
The strange thing is the phone book even works over HTTPS as long as I don't use the Require SSL setting in IIS. However I would like to use that setting so that web browsers accessing TMS will be required to use HTTPS.
Have you enabled or tried "Secure-Only Device Communication" under Administrative Tools > Configuration > Network Settings? This would require each codec to use HTTPS in their external manager, not sure if it affects the phonebooks though.
One work around I've done for our TMS is use a redirect in IIS to change the url to HTTPS. That might be a quick easy solution if you can't get the Require SSL to work.
Hi Scott, Please refer to following document - Configuring Secure HTTPS between Cisco TelePresence products Reference Guide from http://www.cisco.com/en/US/docs/telepresence/infrastructure/tms/config_guide/Cisco_TelePresence_Implementing_Secure_Management_Config_Guide.pdf
Yes, this is old document but the steps will be the same for 13.x version. Please refer to the steps for C - series and TMS in the document.
BR, Mahesh Adithiyha
I've read through the document but I don't see anything that addresses the issue at hand (phone book failure when "Require SSL" is set in IIS.) I'm not having any problems with device managment generally over HTTPS, and even the phone book works over HTTPS as long as "Require SSL" is unchecked. Is there something specific in this document you wanted me to verify?
Hi Scott, Most SSL certificates are bound to the hostname of the machine and not the ip address.
IMHO, you should have DNS enabled in the C series connected Vlan and try the phonebook.
BR, Mahesh Adithiyha
Thanks for the advice... unfortunately, I'm not in a position to add DNS service to the VLAN. However, since the Phone Book URL is pointing directly to an IP address and not the server name, how would DNS fix this problem? Remember that the phone book does download over HTTPS as long as I don't require SSL in IIS.
I just enabled require SSL in my IIS server and I am able to get phonebooks still, not on http of course, only if I set the phonebook server to https. Do you have ignore client certificates or do you require validation on this? If you have set it to require client certificate then that might be the problem, what happens if you set it to ignore? Users will still have to use HTTPS to access the application.