Let's Encrypt: Make the Certificate Routine

A certificate can be installed correctly and still create a problem three months later. Its expiration date is not a request for the server to keep working. It is a boundary on the credential’s validity.

That makes certificate handling a continuing job. Somebody must obtain the right credential, install it, present the appropriate chain and repeat the process before the current one expires.

Let’s Encrypt’s public beta began on December 3, 2015, removing the invitation requirement for its free certificates. Josh Aas’s announcement identified automation as a cornerstone while acknowledging that the client experience still needed improvement.¹

The consequential change was not merely a lower price. Certificate management could become a repeatable software operation instead of a succession of manual administrative errands.

This was also a staged arrival. The first certificate appeared in September. Browser trust through cross-signatures followed in October. Open public participation followed in December. Treating those as one launch would conceal three different problems the project had to solve.

What a domain check can establish

Imagine an invented operator responsible for preview.example. The operator wants a certificate for that name so a server can participate in authenticated encrypted connections.

A certificate authority needs grounds for issuing the credential. A domain-validation procedure concerns control of the name or a resource associated with it. It does not establish that the site’s business is honest, its advice is good or its files are harmless.

That distinction is central to making validation automatable. A machine can check a narrowly specified response without conducting a general investigation of the organization’s merits.

The July 2015 ACME draft describes a Simple HTTP challenge in which a client provisions specified content on a web server answering for a domain. The authority checks that resource.² This is period protocol background, not a claim that every field of that draft exactly matches the December production service.

The draft was work in progress. Its vocabulary and details should not be silently replaced by the eventual standard and then attributed backward to 2015.

For the conceptual procedure, the important sequence is enough: request authorization for a name, receive a challenge, make the required response available and let the authority verify it before issuance.

A miniature challenge has a narrow answer

Here is an original teaching model. The authority selects a fictional required marker, proof-for-preview-17. The operator places that marker in the response associated with preview.example.

A check of the intended name and matching marker returns true. A marker left over from a different challenge returns false. A matching marker associated only with a different name also returns false.

The companion Python check confirms these three outcomes using a dictionary. It is not an ACME implementation. The marker is not cryptographic proof, and the model omits account signatures, key material, challenge construction, network behavior and security checks.

Its purpose is to make the scope legible. The response is evidence about a specified resource under a specified name. A success on another name does not answer the original request. An old response does not become valid merely because it looks like the right kind of response.

The exact real protocol does much more to bind those operations securely. A three-case dictionary model cannot test that construction or demonstrate that an actual authority would issue a certificate.

Even at this small scale, however, the reason for automation is clear. The question is repeatable, the expected evidence is explicit and the result can guide another operation without someone interpreting an email by hand.

The operator still has to control the relevant configuration. A response saved in a local directory is not necessarily a response reachable at the domain. Routing, serving and access are part of the actual operation, not decorations around the check.

Modern original teaching model, drawn in 2026. The fictional marker and dictionary check are not ACME protocol messages or cryptographic validation.

Issued and trusted are different milestones

Let’s Encrypt’s September 14 announcement described its first certificate and explicitly noted that the cross-signature was not yet in place. It worked for clients whose trust stores already included the ISRG root.³

A newly issued credential therefore did not automatically imply broad acceptance by existing browsers. Clients need a way to connect the credential’s signing chain with something they already trust.

The October 19 announcement reported IdenTrust cross-signatures for the two Let’s Encrypt intermediates and instructed servers to present the appropriate cross-signed certificate as part of the chain.⁴

This makes the deployment problem more concrete than saying a server has a certificate file. It needs the relevant chain, and the client must be able to validate that chain against its trust configuration.

Our fictional operator can perform issuance correctly and still present an incomplete arrangement. Conversely, a browser’s acceptance of a chain is not an endorsement of everything the site says after the connection is established.

The narrow meanings are useful. Domain validation, certificate issuance, chain presentation and client acceptance are related stages. Each stage answers a particular question rather than replacing the others.

The October announcement’s statement about major browsers belongs to the contemporary provider record. It is not a claim that every historical device or every independently configured trust store behaved identically.

Ninety days encourages a different habit

In November 2015, Let’s Encrypt explained its ninety-day certificate lifetimes. Its account linked shorter validity to limiting the duration of some compromise or mis-issuance risks and encouraging automation. It recommended renewal every sixty days.⁵

That combination changes the operator’s calendar. A manual task performed occasionally has to become a dependable recurring process.

Use an original abstract timeline. Certificate A begins on day zero and expires at day 90. A replacement B is obtained and installed on day 60, expiring on day 150. Replacement C is installed on day 120, expiring on day 210.

Each successful renewal occurs while thirty days remain on the previous certificate. The time margin is easy to calculate: ninety minus sixty equals thirty. It is not a guarantee that every actual renewal is immediate or successful.

Suppose the day-60 attempt fails. A still has validity remaining. The operator can investigate and retry before day 90. Suppose instead the process silently fails through day 91. The arithmetic no longer supplies a valid current credential from that initial issuance.

The companion check verifies the expirations and overlap intervals in this invented day-number model. It does not issue a certificate, contact Let’s Encrypt or model actual timestamp precision.

The example’s distinction is between having room to recover and actually using it. A margin helps when failure is detected. It does little when everyone assumes the recurring task is still succeeding because it once did.

Modern original timeline, drawn in 2026. It illustrates the November 2015 recommendation with abstract days; it is not current certificate-lifetime guidance.

Renewal must reach the running service

Obtaining replacement B is only part of our timeline’s intended outcome. The server must actually use it.

Imagine a renewal job writes the new certificate successfully, but the running service keeps presenting A. Looking only at the newly written file can produce a reassuring answer to the wrong question. Visitors are interacting with the live service, not the operator’s filesystem inventory.

A useful operational check should consequently concern what the service presents, alongside whether acquisition succeeded. The details depend on the server and client arrangement. This historical article does not offer obsolete installation commands as current operating instructions.

The same care applies to coverage. If a site is reached through multiple names, a certificate covering one name does not automatically answer for every other name the operator uses. Explicit intended names and actual requests need to agree.

Automation can repeat an incorrect configuration as diligently as a correct one. Its virtue is repeatability, not clairvoyance.

For a team handing the site to another operator, that recurring process also needs an intelligible record: which service is covered, where failure is reported, and how to confirm the live credential. A working first installation becomes more useful when its maintenance can survive the person who performed it.

Free issuance did not abolish maintenance

The December beta announcement presented free public access and also singled out client reliability as unfinished work. That admission belongs in the history. The project was making a recurring task easier, not claiming that every installation was already effortless.

The ACME draft’s operator model similarly envisaged continued client contact with the authority and automated deployment. The vision concerned a lifecycle, not just the first successful download.

For our fictional operator, the resulting responsibilities are understandable: establish the required control, obtain the credential, ensure the service presents it appropriately, repeat before expiry and notice when repetition fails.

A certificate’s purpose remains specific. It helps authenticate a name within an encrypted connection’s trust arrangement. It does not inspect the application’s logic, fix an insecure endpoint or make an unreliable organization reliable.

Let’s Encrypt’s 2015 milestones mattered because a widespread security mechanism had been encumbered by procedures poorly suited to routine, universal use. Free issuance removed a purchasing barrier. Automation addressed the continuing administrative barrier. Cross-signing addressed acceptance by existing clients.

The result was a useful change in expectations: keeping a certificate current could be ordinary software maintenance.

Ordinary maintenance still needs somebody to notice when it stops happening. The day after expiration is an unhelpful time to discover that an automation job has spent a month quietly failing.

Sources

Footnotes

1. Josh Aas, “Entering Public Beta”, December 3, 2015. The preserved page includes later client advice; it is not used as launch-client evidence. ↩

2. Barnes, Hoffman-Andrews and Kasten, ACME draft-barnes-acme-04, July 21, 2015, abstract, deployment model, terminology, SimpleHTTP opening and selected security considerations. Historical work in progress, not the final standard or exact beta implementation. ↩

3. Josh Aas, “Our First Certificate Is Now Live”, September 14, 2015. ↩

4. Josh Aas, “Let’s Encrypt is Trusted”, October 19, 2015. Contemporary cross-signing milestone and chain requirement. ↩

5. Josh Aas, “Why ninety-day lifetimes for certificates?”, November 9, 2015. Historical lifetime and sixty-day renewal recommendation; not current operational advice. ↩