[cisco-voip] Couple misc. CTL/certificate questions...

[Ed Leatherman]

Just by way of a follow-up from my work today.

- The troubleshooting section of Jason's CTL doc was very handy to follow
through and verify operations when I finished all my tasks.

- Regenerating certs went off without a problem

- The login for CTL Client is the application administrator login, not the
platform administrator as I had expected, thought that was a little odd.

- The CTL client refused to recognize my security tokens as valid when run
on my crappy windows XP laptop - said they were not from Cisco CA. I even
downloaded the newer CTL Client from cisco.com, thinking it was just a
newer security token manufacturer (since there is a bug about that). I've
used the same tokens to sign my CTL on cm 8 test cluster without issues.

- Ended up installing CTL on my windows 7 desktop and running in
compatibility mode. Everything worked fine, and it accepted all my tokens.

- The serial numbers printed on the tokens/packaging do not match the
serial number listed in the CTL. The SN in CTL is in the format
SAST-ADNXXXXXX, which matches up with what Jason's CTL document is showing.
The serial numbers printed on my tokens/packaging all look like FTXXXXXXX,
like a router serial number or something.

- Before restarting all phones/CM services, I reloaded TFTP and then reset
my desk phone and a couple other phones in interesting locations on campus
(ie behind asa's etc), and used that to verify correct CTL was downloaded
etc. Yes i'm a little paranoid, but I figured this way if I had an issue I
could run the CTL client again and switch back to non-secure mode before
any other phones started requesting signed configs.

- It was not sufficient to just restart the CM service to get phones to
request a CTL file, I had to actually reset them. CM service needed to be
restarted anyway so no harm done. I was just hoping for the former just to
minimize how many devices I had re-registering this morning, oh well
learned something :)



On Wed, Jun 20, 2012 at 1:37 PM, Ed Leatherman <ealeatherman at gmail.com>wrote:

> Jason,
>
> Thanks for the reply! That was exactly what I was looking/hoping for. I
> will just regenerate the certs and reset CCM prior to setting up security
> to get the certs refreshed, and then again after I'm done to push the
> changes out.
>
> Ed
>
>
> On Wed, Jun 20, 2012 at 12:18 PM, Jason Burns <burns.jason at gmail.com>wrote:
>
>> Ed,
>>
>> Good catch on the CAPF certs on every node. You're right that they just
>> get ignored on the subscriber nodes. I'm not sure myself what function they
>> serve as the only useful CAPF cert is the one from the publisher.
>>
>> Since you're on 7.X and you're about to enable security but this isn't a
>> new install, I would definitely recommend taking a look at all of your
>> certificate expiration dates. They're typically 5 years from creation for
>> the self signed certificates (install date). Personally, I would regenerate:
>>
>> CAPF.pem - Publisher
>> CallManager.pem - All Nodes
>>
>> before I enabled security with the CTL client and USB tokens. This means
>> you'd have 5 years before ever having to worry about running the CTL client
>> again for certificate expiration. You may have to run it again if you
>> changed other things that  regenerated certs (host name change), and it's
>> easy to run again, but why worry about it. You'll also have 5 years before
>> CAPF expires, which gives you a guaranteed 5 year life time before worrying
>> about any LSCs signed by this CAPF (since the LSC is what gets pushed to
>> the phones and they're signed by CAPF).
>>
>> Now is also a good time to point the cluster to an SMTP email server, as
>> well as populate an email address in the Certificate Monitor fields in OS
>> Administration. This will notify someone before that 5 year timer pops.
>>
>> Once you've regenerated CAPF and CallManager certificates you'll want to
>> restart CAPF on the pub and CCM on all nodes. If you can't restart CCM for
>> operational reasons then I'd skip the CallManager.pem regen step but still
>> perform the CAPF regen step. We want to make sure we don't have to mess
>> with any CAPF or LSC regeneration for another 5 years.
>>
>> Enable security and push LSCs to the phones.
>>
>> In 4 years and some months you'll get an email telling you the CAPF cert
>> is about to expire. You also know that all of your LSCs are about to
>> expire. You can take proactive action to generate a new CAPF cert, run CTL
>> client, reset phones, and use BAT to push new LSCs to phones.
>>
>>
>> If this is 8.X you can still regenerate the CAPF.pem, but don't touch the
>> CallManager.pem unless you have to.
>>
>> -Jason
>>
>> On Wed, Jun 20, 2012 at 9:12 AM, Ed Leatherman <ealeatherman at gmail.com>wrote:
>>
>>> I'm getting ready to install security tokens soon on CM 7.1, and noticed
>>> a few things while I was pulling my plan together. I was hoping someone
>>> might know the answer(s)
>>>
>>> - While looking around at the existing certs on my cluster (non-secure
>>> mode right now) I noticed a CAPF.pem on every node, with a different serial
>>> numbers and CNs. I thought this should only exist on the publisher? Does it
>>> just ignore the certs on the other nodes when i put the cluster in mixed
>>> mode?
>>>
>>> - Also while poking around - once again, non-secure mode - I noticed all
>>> the CallManager.pem files have varying expiration dates on them (seems to
>>> coincide with when I refreshed hardware). Some of them expire as early as
>>> 2014.. would it be a good idea to refresh the certs now so that they have
>>> later expiration dates, before I start pushing CTL files out to phones? If
>>> I do this, do I need to restart the CM service?
>>>
>>> Thanks !
>>>
>>>
>>> --
>>> Ed Leatherman
>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>
>
> --
> Ed Leatherman
>
>


-- 
Ed Leatherman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20120624/4162e376/attachment.html>