On Sat, Dec 05, 2015 at 04:23:16PM -0800, Jacob Hoffman-Andrews wrote:

> On 12/04/2015 11:54 AM, Viktor Dukhovni wrote:
> > Can anyone using LE automated rotation check whether the key stays the
> > same or not? 
>
> It is up to the user. The official client will generate new keys for
> each issuance by default, but you can provide a CSR for an existing key
> using the --csr flag.

Thanks for the follow-up.  It might be useful to provide an option
for users of the official client to keep the key unchanged, and
advise DANE users to use that option as part of automated certificate
rollover.  

They would then periodically (at their convenience) generate new
keys and publish corresponding TLSA records before deploying new
certificates for those keys.  At that point automated renewal can
proceed as before.

My DANE SMTP survey has so far found 19 domains with 11 distinct
LE certificates, whose expiration dates are:

   2 ; Expiration = 2016-02-01T10:02:00Z
   1 ; Expiration = 2016-02-02T14:15:00Z
   1 ; Expiration = 2016-02-02T14:29:00Z
   1 ; Expiration = 2016-02-08T15:58:00Z
   4 ; Expiration = 2016-02-08T19:45:00Z
   2 ; Expiration = 2016-02-14T20:07:00Z
   3 ; Expiration = 2016-02-18T11:48:00Z
   2 ; Expiration = 2016-02-22T03:22:00Z
   1 ; Expiration = 2016-02-22T05:57:00Z
   1 ; Expiration = 2016-02-28T00:02:00Z
   1 ; Expiration = 2016-03-02T21:45:00Z

IIRC automated renewal attempts kick in after 60 days with 90 days
total, so I'll not see how well the combination of LE certificate
renewal with DANE TLSA records works for these users until the
beginning of January.

Some sort of advice for the early adopters would be useful I think.

-- 
        Viktor.

Reply via email to