[cisco-voip] re-genarate certifications

[Dave Cardwell]

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.

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 :)

IPSec vpn's manage to gracefully handle key rollover in PKI environments.


On 23 Jun 2017 21:16, "Brian Meade" <bmeade90 at vt.edu> wrote:

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.

With websites, people don't have persistent connections as well so it's
easy to switch certs.

Anyone know of any persistent services able to use technology like
Let'sEncrypt without dropping connections?



On Fri, Jun 23, 2017 at 3:29 PM, Dave Cardwell <dave.cardwell1 at gmail.com>
wrote:

>
>> The bigger problem is the automatic phone reset.
>> -Rya
>>
>
> Well fix the phones, why do they need to reset to support new
> certificates?
>
> 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.
>
>
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20170623/5484f161/attachment.html>