Summary

  • Let’s Encrypt’s 9 November 2015 policy set a 90-day maximum to limit the useful life of a compromised or mis-issued certificate and push HTTPS toward automation. Its day-60 renewal target left operators roughly a month to recover by hand while subscribers were still learning the new routine.
  • The public-beta announcement three days later reported more than 11,000 certificates issued during limited beta, while saying the client experience still needed to work smoothly across many platforms.

Analysis

A visitor does not get a valid certificate because the site worked yesterday. RFC 5280 requires the current time to fall inside the certificate’s validity period during path validation. Once notAfter passes, the site operator needs a replacement issued and in service. A date field becomes a deadline for keeping the connection trusted.

On 9 November 2015, Josh Aas, executive director of the Internet Security Research Group, explained why Let’s Encrypt had chosen a 90-day ceiling. His post named two jobs for the same limit. If a private key was stolen or a certificate had been mis-issued, the period during which that certificate remained valid would be shorter. And the renewal deadline would arrive often enough to make automation a condition of easy HTTPS rather than a nice extra.

The detail that gives the policy its shape is the 60-day recommendation. Let’s Encrypt did not tell a new subscriber to wait until the certificate’s last day. It recommended renewing at 60 days, leaving roughly a month before the 90-day limit. Aas said the service was young and automation was new to many subscribers. The month between the day-60 target and the 90-day limit gave an operator time to notice a failed renewal and intervene by hand. The interval was short enough to press for software and long enough to leave a human recovery route.

That was a rollout decision as much as a security setting. On 12 November, Aas reported that limited beta had begun on 12 September and produced more than 11,000 certificates. Public beta was scheduled for 3 December. The same announcement called automation a cornerstone, then admitted that client experience still needed work across a wide range of platforms. Issuance had reached thousands; universal, smooth renewal was still a job to finish.

Let’s Encrypt’s argument was unusually plain. Administrators could not be expected to renew certificates by hand across the entire Web. If issuance and renewal ran automatically, a shorter lifetime would not add inconvenience for the person running a site. The security gain and the operating model were joined: a 90-day limit made certificates age faster; a client that renewed and deployed them made that clock manageable.

The policy kept a manual path open while betting that it would become the exception. A subscriber had time to notice a failed renewal and intervene. But the system’s steady state depended on client software, scheduled jobs, platform compatibility and deployment steps working together. A 60-day recommendation was a calendar instruction. Automation was the answer to how that instruction could scale.

The beta count says how many certificates Let’s Encrypt had issued by 12 November. It says nothing about how many renewals succeeded or failed. A dated renewal-success series would show whether the manual interval was an adequate recovery window; the two announcements do not report one.

Sources