Questions regarding Certificates on C Series codecs...

[juriss]

Like many folks on the forum, we have been very busy upgrading our systems to TC7.1.1 in response to the Heartbleed vulnerability.

Cisco has been very cooperative with release keys for older systems and those without contracts... Thanks

However our Security folks are requesting that we change password on our systems and replace the Certificates

My questions are:

1 - Is it possible to join these system to our MS domain and use AD authentication rather than the local admin account?

    - We do this today for the VCSs and it works well for us

    - These system may need to be joined to the domain eventually if we do Lync Integration

2 - Does anyone replace the Tandberg/Cisco security certificates that come preloaded on the C/MX/EC/SX systems

     - We ensure that Telnet and HTTP are off in favor of SSH and HTTPS, but do not load a new Certificate

     - Our systems are not in a Top Secret or Classified environment or exposed to the public Internet

3 - Can a single Security Certificate be used on multiple systems or must they be unique, does the IP address changing via DHCP cause issues?

Thanks for your input and comments

SCJ

[Steve Kapinos]

1 - No you can't add them to the domain.  Your VCS setup is not domain membership, but rather using LDAP as the source of user authentication.  This functionality is not available on the codecs.

2 - It would be best security practice to do so, but certificate management is not something most customers are very good at and many do not.  The default certificates are not giving you trust of identity and authentication... simply ensuring there is encryption in play to 'someone...' which you hope is your device and no one in the middle.. and no one capturing the traffic.  How significant that risk is, is something you must decide for yourself.

3 - Certificates would be unique per device and you would typically use hostnames to reach the systems, not IP addresses so the browser address can be matched to the common name in the certificate.  DHCP changes can be integrated if you have DHCP giving dynamic updates to DNS.

[juriss]

Steve K... thanks for the reply

#1 - In "VCS Authenticating Devices Deployment Guide X6".... it has the following:

To join the VCS into the AD domain, access to VCS via the root login is required.
1. Login as root over SSH or via the serial interface, then:
a. Type domain_management you will be presented with the options:
----------------------------------------
1) Join Domain
2) Leave Domain
3) VCS Status
4) Domain Information
5) Exit
----------------------------------------
b. Choose option 1) Join Domain.
c. When asked, enter the domain administrator username.
d. When asked, enter the domain administrator password (case sensitive).

I think LDAP query is used for Admin login
An the direct AD join is for Provisioning Extension ???
Later this function was added to the web interlace of X7

Either way, I would think that others besides me would like the functionalityy of using AD/LDAP credentials to login to an endpoint....   Would love to see that on the roadmap

#2 - We have been using the included Certificates, but with the Heartbleed vulnerability it has caused us to change the Certs on all systems and possible revisit who is a Certificate Authority on those certs... not fun

#3 - I have since learned through a TAC case I opened, that if a Factory reset is done on the systems, it will re-generate a new self signed certificate and it appears in some cases a new cert will be generated during the upgrade process.

So on one of the test system we have on old Tandberg Cert with a date of 2010 and a new Cert from Apr 2014 that is Cisco... 

We thing we can use the new one that was generated from the TC7.1.1 upgrade, however we cannot  the old one from 2010

Generating our own Certs is not going to be fun....

Anyone else facing these issues?

Thanks

SCJ

[Chris Swinney]

Hi SCJ,

On a web interface on a TC endpoint that has been upgraded to TC7.1.1, navigate to Configuration --> Security

You should then see in the Certificates list, both the old and New Certificate and you can assign the new cert to the HTTPS, SIP or 802.1x. Then reboot the system.

There are a few annoying bits to this:

• It doesn't set the new cert as the default cert automatically
• You cannot seem to delete the the old cert
• A new cert does not appear to be created during an upgrade to TC6.3.1, only when you upgrade to TC7.1.1
• I cannot find a way to automate this

Hopefully, Steve will be able to provide us with more answers.

Cheers

Chris

[juriss]

Chris - Thanks for the reply

I did set the new Cert to "On" and rebooted a C40 in our support center

I then webbed into the system with Firefox and looked at the Cert used and it was the new Cert that was created during the TC7.1.1. upgrade

My guess is that Cisco knew that the Heartbleed issue would cause folks to want to change the Cert and built that function of generating a new self signed Cert into the TC7.1.1 code

I agree that I do want to delete the old Cert, but it does not allow me to

I feel we will need to manually web into each of our 300+ systems and change the admin password, activate the new Cert (with the date we upgraded to TC7.1.1) and then reboot

We can then verify that the new Cert is in use with looking at the Firefox info..

Not fun... but necessary

[Steve Kapinos]

>#1 - In "VCS Authenticating Devices Deployment Guide X6".... it has the following:

Yes, sorry, I overlooked that specific device authentication method.  It's been far too long that I've been so specialized I've lost my SME-credentials on most other topics :)  VCS has been offering a lot of advanced functionality that only the VCS SMEs can really keep up with :)

>#2 - We have been using the included Certificates, but with the Heartbleed vulnerability it has caused us to change the Certs on all systems and possible revisit who is a Certificate Authority on those certs... not fun

Certificate management is daunting for most people new to it, but deploying is not so bad.. it's the keeping tabs and upkeep that is the burden IMO.  It's easy enough to cut certificates using OpenSSL utilities or a Microsoft CA if you are willing to use an internal CA.  There is a lot of best practice overhead if you are really serious about it... but for people that have been running the default certs for so long, I doubt they are interested in going to the full on detached CA world :)

>#3 - I have since learned through a TAC case I opened, that if a Factory reset is done on the systems, it >will re-generate a new self signed certificate

This is an area you must approach device by device and version by version.  Things have improved and evolved over time.  It's good to hear they are re-generating certificates like that.

But for anyone concerned about heartbleed - you shouldn't been using self-signed certificates either as you do not have the identification validation part of SSL when using self-signed certificates or if you are always ignoring certificate errors.  SSL is both encryption AND identification.  Else, you risk just sending your traffic to anyone who inserts themselves in the conversation.