<div dir="ltr">In 8.0 I believe, cert changes didn't reset phones. I think that started in 8.5 as a fix for everyone breaking their clusters regenerating all the certs at once.<div><br></div><div>It would be a good idea to allow for a much larger ITL where you can add whatever certs you want but I think the older phone hardware is pretty limited for memory and you also don't want these files getting too large. Kind of similar to Phone VPN Cert changes where you add an additional cert to the VPN Gateway in CUCM ahead of time. Difference there is the phones are only downloading a hash of the certificate to compare against.</div><div><br></div><div>Probably need a new feature to put your CA root on the 7800/8800 CA list, everyone gets on those model phones, then just allow those model phones to use that CA list for trusting config files and we may be good to go. I think right now the CA list is only used for MRA.</div><div><br></div><div>There's probably some security concerns there though about the CA list being used for these items.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 23, 2017 at 5:00 PM, Dave Cardwell <span dir="ltr"><<a href="mailto:dave.cardwell1@gmail.com" target="_blank">dave.cardwell1@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Fair enough, the 90 day cycle of LetsEncrypt is probably too short for the situation where you have phones sat on shelves. But, if you implement the fix to allow phones to import multiple certs and not reset when doing so it solves a whole lot of other problems and reduces the stress involved in migrations.</div><div dir="auto"><br></div><div dir="auto">You can still use longer cert lifetimes. In the case of your large regen project you push out the new certs 60 days before the old ones expire then roll the servers over 30 days later. You now, first, have a month to make sure all the phones have been plugged in and then if there are any problems with the cutover you can just roll back and have another month to deal with it. That sounds less stressful than the current process. It shouldn't even require downtime :)</div><div dir="auto"><br></div><div dir="auto">IPSec vpn's manage to gracefully handle key rollover in PKI environments.</div><div><div class="h5"><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On 23 Jun 2017 21:16, "Brian Meade" <<a href="mailto:bmeade90@vt.edu" target="_blank">bmeade90@vt.edu</a>> wrote:<br type="attribution"><blockquote class="m_-6961515030025233627quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">You still are going to have issues with phones that were offline when the new cert was pushed. For a large regen project, we just plan to have everyone make sure their phones are online but you can't do this every couple of months.<div><br></div><div>With websites, people don't have persistent connections as well so it's easy to switch certs.</div><div><br></div><div>Anyone know of any persistent services able to use technology like Let'sEncrypt without dropping connections?<br><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div class="m_-6961515030025233627elided-text">On Fri, Jun 23, 2017 at 3:29 PM, Dave Cardwell <span dir="ltr"><<a href="mailto:dave.cardwell1@gmail.com" target="_blank">dave.cardwell1@gmail.com</a>></span> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-6961515030025233627elided-text"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br>
</div>
<div>The bigger problem is the automatic phone reset. <span class="m_-6961515030025233627m_7491742421686452077m_150597442788381373m_-7754333688865238740HOEnZb"><font color="#888888"><br>
<div class="m_-6961515030025233627m_7491742421686452077m_150597442788381373m_-7754333688865238740h5">-Rya<br>
</div></font></span></div></div></blockquote><div><br></div></span><div>Well fix the phones, why do they need to reset to support new certificates? <br><br>Key rotation is a long solved problem, push out the new new certificate when its generated after 60 days but don't activate it on the server. The phones should now trust both the new one and the old one (until it expires 30 days later), then activate the new one on the server a couple of days before the old one expires. Once the phones can import certificates without reloading the switch-over on the server side should be a non-issue.<br><br></div><div><br></div><div><br><br></div></div></div></div>
<br></div><div class="m_-6961515030025233627quoted-text">______________________________<wbr>_________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank">https://puck.nether.net/mailma<wbr>n/listinfo/cisco-voip</a><br>
<br></div></blockquote></div><br></div>
</blockquote></div><br></div></div></div></div></div>
</blockquote></div><br></div>