On Aug 31, 2018, at 4:42 PM, Robert Moskowitz <rgm at htt-consult.com>
wrote:>
> [Let?s Encrypt] is designed for getting web servers quickly into TLS
Yes.
> ...and then to a more stable provider.
[citation wanted]
> If your content is short information, your contacts will never notice that
you go to a new cert quarterly.
They?ll never notice regardless.
I?m looking at a Google.com certificate right now that was generated on August
14th of this year and will not be valid past October 23. That?s the same
replacement schedule as Let?s Encrypt.
The old model of long-lived certificates has no special value. It?s purely a
business decision on the part of the providers and customers. Automation
removes much of this model?s value.
> I can see web services where a new cert every 90 days will cause a pain
point.
Describe one.
I?ve been running some of my domains on Let?s Encrypt for years now, and have
never had a single user complain to me that my certs are changing too often.
> And for other services like IMAP, SMTP, LDAP (maybe not LDAP) constant
changing certs even with a long lived root may get old for your customers.
As long as both the old and new certs are valid at the time of replacement, the
client should care nothing about it unless they?ve gone to the trouble to
download the cert and check it against the cached copy every time.
I remember hearing about at least one browser plugin that did this, but since
the idea of rapid cert replacement has been gaining ground, I expect that plugin
has lost much of the small amount of popularity it once held.
> Unfortunately, there has never been an effective business model for small
customers.
There is now: it?s called Let?s Encrypt. :)