<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Inline.
<div class=""><br class="">
</div>
<div class=""><br class="">
<div class="">-Ryan </div>
<br class="">
<div>
<div class=""></div>
</div>
<blockquote type="cite" class="">
<div>
<div class="">On Aug 12, 2015, at 11:23 PM, Dave Goodwin <<a href="mailto:Dave.Goodwin@december.net" class="">Dave.Goodwin@december.net</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class="gmail_default" style="font-family:tahoma,sans-serif">Ryan, let me lay out an example to make sure I understand. Please note that I haven't found anywhere that this has been well-explained, so I am laying out the following logic flow as a guess. Hopefully
 it's at least close; please set me straight. Say we have an old cluster and a new cluster, and that I want to move phones registered to the old cluster to instead register to the new cluster. Are you saying:</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br class="">
</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">
<ol class="">
<li class="">Download the CallManager.pem from new cluster pub and upload that cert as phone-trust to the old cluster. This will enable the old cluster TVS to have TVS-aware phones trust the new cluster.<br class="">
</li></ol>
</div>
</div>
</div>
</div>
</blockquote>
<div class="">Correct.  I’d do this between both clusters so phones can move back and forth. </div>
<br class="">
<blockquote type="cite" class="">
<div>
<div class="">
<div dir="ltr" class="">
<div class="gmail_default" style="font-family:tahoma,sans-serif">
<ol class="" start="2">
<li class="">When the phone is told (say, via change in DHCP option 150 value) to register to the new cluster, it will fail to authenticate the new cluster's CTL file due to a different file signer.<br class="">
</li><li class="">So, the phone will then connect with its already-trusted TVS server in the old cluster. At this point, since the new cluster pub cert was added as phone-trust in the old cluster, TVS will instruct the phone to trust the cert.<br class="">
</li></ol>
</div>
</div>
</div>
</div>
</blockquote>
<div class="">Correct, phone will get CTLsepmac.tlv from the new cluster first, reach out to OLD TVS to validate it. </div>
<br class="">
<blockquote type="cite" class="">
<div>
<div class="">
<div dir="ltr" class="">
<div class="gmail_default" style="font-family:tahoma,sans-serif">
<ol class="" start="4">
<li class="">Then, based on TVS's go-ahead, the phone will now load and install the new cluster CTL file.<br class="">
</li></ol>
</div>
</div>
</div>
</div>
</blockquote>
Correct.<br class="">
<blockquote type="cite" class="">
<div>
<div class="">
<div dir="ltr" class="">
<div class="gmail_default" style="font-family:tahoma,sans-serif">
<ol class="" start="5">
<li class="">At this stage, the phone will trust only the entries in the new cluster CTL file - and also any certs that the new cluster's TVS can trust.<br class="">
</li></ol>
</div>
</div>
</div>
</div>
</blockquote>
The phone won’t use the new TVS until it gets a config file from the new cluster. Since the CTL should allow it to update the ITL and trust the new config file there should be no need for TVS after the CTL is loaded.</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div>
<div class="">
<div dir="ltr" class="">
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br class="">
</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">Also, it seems like this procedure would also work with the token-based CTL client, as long as TVS is present and all the moving endpoints support TVS.</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">Except that the token-based CTL file is signed by the eToken and you can’t import that cert.  The key to moving between clusters with tokens is that the CTLs on both clusters are signed by the same tokens.</div>
<br class="">
<blockquote type="cite" class="">
<div>
<div class="">
<div dir="ltr" class="">
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br class="">
</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">-Dave</div>
</div>
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Wed, Aug 12, 2015 at 10:45 PM, Brian Meade <span dir="ltr" class="">
<<a href="mailto:bmeade90@vt.edu" target="_blank" class="">bmeade90@vt.edu</a>></span> wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr" class="">Ryan, would you need to add the other cluster in the TFTP server list?  I know I usually had to do this with the actual CTL client but not sure how this would work in tokenless unless there's a CLI command for it.</div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Wed, Aug 12, 2015 at 10:03 PM, Ryan Ratliff (rratliff)
<span dir="ltr" class=""><<a href="mailto:rratliff@cisco.com" target="_blank" class="">rratliff@cisco.com</a>></span> wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">The tokenless CTL is signed by the CallManager.pem on the publisher.  Upload that cert as a phone-trust cert and TVS on that cluster will be able to authenticate files signed by that cert.
<div class=""><br class="">
</div>
<div class=""><span style="white-space:pre-wrap" class=""></span>CTL Record #:1<br class="">
<span style="white-space:pre-wrap" class=""></span>          ----<br class="">
BYTEPOS<span style="white-space:pre-wrap" class=""> </span>TAG<span style="white-space:pre-wrap" class="">
</span>LENGTH<span style="white-space:pre-wrap" class=""> </span>VALUE<br class="">
-------<span style="white-space:pre-wrap" class=""> </span>---<span style="white-space:pre-wrap" class="">
</span>------<span style="white-space:pre-wrap" class=""> </span>-----<br class="">
1<span style="white-space:pre-wrap" class=""> </span>RECORDLENGTH<span style="white-space:pre-wrap" class="">
</span>2<span style="white-space:pre-wrap" class=""> </span>1701<br class="">
2<span style="white-space:pre-wrap" class=""> </span>DNSNAME<span style="white-space:pre-wrap" class="">
</span>20<span style="white-space:pre-wrap" class=""> </span>videolab-ucm11a-pub<br class="">
3<span style="white-space:pre-wrap" class=""> </span>SUBJECTNAME<span style="white-space:pre-wrap" class="">
</span>70<span style="white-space:pre-wrap" class=""> </span>CN=videolab-ucm11a-pub.videolab.local;OU=TAC;O=Cisco;L=NC;ST=RTP;C=US<br class="">
4<span style="white-space:pre-wrap" class=""> </span>FUNCTION<span style="white-space:pre-wrap" class="">
</span>2<span style="white-space:pre-wrap" class=""> </span>System Administrator Security Token<br class="">
5<span style="white-space:pre-wrap" class=""> </span>ISSUERNAME<span style="white-space:pre-wrap" class="">
</span>70<span style="white-space:pre-wrap" class=""> </span>CN=videolab-ucm11a-pub.videolab.local;OU=TAC;O=Cisco;L=NC;ST=RTP;C=US<br class="">
6<span style="white-space:pre-wrap" class=""> </span>SERIALNUMBER<span style="white-space:pre-wrap" class="">
</span>16<span style="white-space:pre-wrap" class=""> </span><font color="#ff4013" class="">52:0B:74:69:CF:4F:5A:CD:5B:48:6F:EE:99:9E:E0:B8</font><br class="">
7<span style="white-space:pre-wrap" class=""> </span>PUBLICKEY<span style="white-space:pre-wrap" class="">
</span>270<span style="white-space:pre-wrap" class=""> </span><br class="">
8<span style="white-space:pre-wrap" class=""> </span>SIGNATURE<span style="white-space:pre-wrap" class="">
</span>256<span style="white-space:pre-wrap" class=""> </span><br class="">
9<span style="white-space:pre-wrap" class=""> </span>CERTIFICATE<span style="white-space:pre-wrap" class="">
</span>961<span style="white-space:pre-wrap" class=""> </span>76 5D 15 01 0E 41 0D 16 BE EA 8A 98 29 33 EE 27 B6 3E D3 01 (SHA1 Hash HEX)<br class="">
10<span style="white-space:pre-wrap" class=""> </span>IPADDRESS<span style="white-space:pre-wrap" class="">
</span>4<span style="white-space:pre-wrap" class=""> </span><br class="">
This etoken was used to sign the CTL file.<br class="">
<br class="">
<br class="">
</div>
<div class="">admin:show cert own CallManager/CallManager.pem<br class="">
[<br class="">
  Version: V3<br class="">
  Serial Number: <font color="#e32400" class="">520B7469CF4F5ACD5B486FEE999EE0B8</font></div>
<div class="">…</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
<div class="">
<div class=""> -</div>
<div class="">Ryan </div>
<br class="">
<div class="">
<div class="">
<div class="">
<div class="">On Aug 12, 2015, at 9:06 PM, Dave Goodwin <<a href="mailto:Dave.Goodwin@december.net" target="_blank" class="">Dave.Goodwin@december.net</a>> wrote:</div>
<br class="">
</div>
</div>
<div class="">
<div class="">
<div class="">
<div dir="ltr" class="">
<div class="gmail_default" style="font-family:tahoma,sans-serif">For anyone who has an environment with multiple mixed mode clusters (CTL file is present), do you know of a way to move devices from one cluster to another?</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br class="">
</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">Using the eToken SAST (physical USB devices), it seems you can do this by using the same signing token to sign the CTL file on each cluster. With the new tokenless CTL client, it seems each cluster's
 publisher private key is used to sign that cluster's CTL file - so it seems the old way will not work.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br class="">
</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">I realize it can be done by deleting the CTL file on the phone (or factory reset) if you're standing in front of it, and I also realize there are commercial software tools that can perform feats
 like this (like UnifiedFX and other competitive offerings). I am looking for a way to do this without either of those methods.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br class="">
</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">-Dave</div>
</div>
</div>
</div>
_______________________________________________<br class="">
cisco-voip mailing list<br class="">
<a href="mailto:cisco-voip@puck.nether.net" target="_blank" class="">cisco-voip@puck.nether.net</a><br class="">
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank" class="">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br class="">
</div>
</div>
<br class="">
</div>
</div>
</div>
<br class="">
_______________________________________________<br class="">
cisco-voip mailing list<br class="">
<a href="mailto:cisco-voip@puck.nether.net" target="_blank" class="">cisco-voip@puck.nether.net</a><br class="">
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank" class="">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br class="">
<br class="">
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
<br class="">
</blockquote>
</div>
</body>
</html>