Setting Up Let's Encrypt with Automatic SSL Renewal

Let's Encrypt certificate expired overnight: what breaks

An expired Let's Encrypt certificate doesn't manifest gradually — it happens all at once: browsers stop opening the connection and show an insecure site warning. The user won't bother figuring out who's to blame — they leave.

If payment, account login, or an inquiry form lives on the domain, the failure arrives together with the SSL error: the payment gateway rejects the request, authorization fails, inquiries don't get through.

At night it looks like "the site is down," even though the server and the application are alive.

The cause is almost always the same: auto-renewal didn't fire, and you found out about it from a client's email, not from monitoring. Let's Encrypt issues certificates for a short term and is designed for automatic renewal — manual control here doesn't work by definition.

Typical failures: the renewal task is in the scheduler but fails silently; domain validation stopped passing after a DNS change or a migration; the web server doesn't reload its configuration and keeps serving the old file; on several nodes, only one got renewed.

A separate case is rate limits on re-issuance: after several failed attempts, the request is blocked for a while, and "just restarting" no longer helps.

The cost of such downtime is higher than it seems. The nighttime window means lost orders and abandoned carts; the morning peak means reputation in search and with users who remembered the warning and didn't come back.

Worst of all, the failure repeats: if renewal isn't put on reliable rails, it will happen again after the same term.

This isn't fixed by a one-time file replacement but by a scheme: auto-renewal with a time buffer, verification of the actual expiration date on all nodes, alerts days before expiry, and automatic rollback if the renewal didn't go through.

Then the certificate stops being a point of failure that's only remembered at the moment of an outage. Let's break down how to set this up.

What automatic certificate renewal provides

Automatic renewal eliminates an entire class of failures that used to live in the on-call engineer's calendar.

A certificate is a file with an expiration date, and as long as renewal remains a manual operation, sooner or later someone's vacation, shift change, or forgotten ticket will coincide with that date.

The browser will respond with a warning about an insecure connection, and the site formally works, but the user sees it as broken.

With automatic renewal, the deadline stops being a point of risk. The Let's Encrypt client issues certificates for a short period, so renewal is triggered in advance, before expiration, and proceeds without human involvement.

If renewal fails for some reason — the validation server is unavailable, the web server configuration has changed — the task fails with an error and a notification is sent, rather than a silent "all good." This moves the problem from the category of "we found out from clients" to the category of "we found out from monitoring."

Recovery time changes fundamentally as a result. Previously, issuing and installing a new certificate took anywhere from a few minutes to hours: you had to recall the procedure, get access, restart the service, verify the chain.

Now a rollback or reissue is just re-running the automation, meaning minutes, and it doesn't depend on who happens to be on call today.

A separate effect is the manual work removed from releases. Renewal is no longer tied to a deployment window, doesn't require separate approval, and doesn't take up a slot in the change plan.

The same procedure runs for the primary domain, subdomains, and test environments, and the configuration is stored in the repository alongside the rest of the infrastructure.

Reliability here isn't about "the certificate definitely exists" but about predictability.

We verify that renewal actually works, not just that it's configured: we run the scenario in a test environment, monitor the expiration date, and keep a time buffer before expiration.

Then the only remaining risk is an external failure on the certificate authority's side, and there's a clear action plan for it.

Issuance and Validation Methods: Comparing Approaches

The choice of domain issuance and validation method determines how autonomously the certificate will renew going forward. A mistake at this stage doesn't show up immediately, but after 60-90 days, when the validity period nears its end and renewal fails silently. Below are the working options that are actually chosen in practice.

Operating Modes

The key fork is where the client lives and how it receives renewal. In standalone mode, the client spins up its own port during validation, so the web server must be stopped — this is acceptable on an isolated node, but breaks operation under live traffic.

In webroot mode, validation goes through the already running server, renewal doesn't drop connections, but requires that the path to the site root be accessible to the process.

In DNS-01 mode, no port is needed at all — this is the only path for wildcard and for servers behind a load balancer.

Limitations Worth Considering in Advance

Let's Encrypt has limits on the number of issuances for a single domain per period and on repeated failed validations — with mass deployment this hits the quota unless intermediate results are cached.

A certificate lives for 90 days, and renewal is triggered 30 days before the end: this margin is enough to catch a failure and avoid lapsing into expiration. For internal domains without a public DNS zone, DNS-01 remains the only working option.

How we implement automation: stages of work

We start with an inventory: which domains and subdomains are served, where the load balancer sits, which services are responsible for domain ownership validation.

Already at this step it becomes clear where renewal will break — for example, if validation goes through a separate server that no longer receives traffic after a routing change.

1. Configuration audit. We collect the current certificates, their expiration dates, and the issuance method. We check whether all names are covered, including those that were added manually and forgotten about in the automation.
2. Renewal scheme. We determine where the renewal client will live, how it obtains domain ownership validation, and where it stores the finished certificates. We establish a single point so there are no two competing processes.
3. Setting up automatic renewal. We set up a scheduled task with a time buffer before expiration, add restarts of the services that keep the certificate in memory, and notifications about failed attempts.
4. Verification. We run issuance on a test environment, then check real renewal and rollback to the previous certificate. We make sure the chain of trust is assembled correctly and older browsers don't drop off.
5. Monitoring. We set up expiration tracking and alerts a few days before expiry — so the problem surfaces with us, not with visitors.
6. Handover. We hand over the configurations, the deployment scheme, and instructions for adding new domains, so the client's team can expand the list without us.

Each stage ends with a verifiable result, not a report. After handover, certificates renew themselves, and manual intervention is only required when adding new domains.

What the client receives upon completion of the work

The work does not end with the fact that "the certificate has been issued," but with the handover of a set of deliverables that your team or another contractor can use to operate and restore the scheme without us. Below is exactly what is documented in the documentation and configuration.

• Issuance and renewal configurations — the final web server and Let's Encrypt client files with the issued certificates, including domain validation parameters and the intermediate certificate chain.
• Automatic renewal scheme — where the renewal task lives, how it is triggered, what happens on failure, and how expiration notifications are delivered.
• Traffic routing scheme — how domain validation requests reach the required service, what is configured on the load balancer, and where the secured segment ends.
• Access policies — which accounts and keys are authorized to issue and revoke certificates, who gets access to private keys and how.
• Maintenance procedures — how often expiration dates are checked, the procedure for handling a renewal failure, and the procedure for a planned migration to another server.
• Recovery instructions — a step-by-step scenario: how to reissue a certificate if the configuration is lost or the server is rebuilt from scratch.
• Change log — which domains and subdomains are covered, when parameters were changed, and who made the edits.

We hand over each artifact exactly as it resides on the server — with no discrepancies between the documentation and the actual state. We separately discuss what happens when a certificate is revoked and how to roll back to the previous configuration if an update fails.

Case study: how we eliminated nighttime certificate failures

Before automation, certificates were renewed manually: once a quarter, an engineer would open the hosting panel, generate a new issue, copy the files to the load balancer, and restart the web server.

On paper — four operations a year, in practice — dozens: the project had several domains and subdomains, each with its own expiration date, and any missed issue turned into a nighttime failure with a certificate error for all visitors.

What it was before

Over six months, we recorded three incidents with an expired certificate, each lasting from 40 minutes to several hours of downtime. The reason was always the same: renewal relied on human memory, not on a process.

Monitoring tracked site availability but not the certificate's expiration date — the outage was noticed through client calls, not through an alert.

What we changed

We set up automatic renewal via Let's Encrypt with domain ownership verification and reissuance well before expiration.

We added a separate check: if the certificate hasn't been renewed or expires before the control deadline, a notification goes to the on-call engineer, not the client. Manual operations with files and server restarts were removed entirely.

What it became

Certificates stopped being a point of failure: renewal happens on its own, and monitoring catches a deviation before a visitor notices it. Engineering time shifted from routine reissuance to tasks that move the product forward.

How is Let's Encrypt different from paid certificates?

From the browser's point of view, there is no difference: Let's Encrypt is an ordinary DV certificate from a trusted certificate authority whose root certificate is preinstalled in operating systems and browsers.

The connection is encrypted the same way, and the green padlock and HTTPS are displayed identically. The user will not see whether the certificate is paid or automatically issued — they will only see that the site is secure.

The key difference is the validity period and the issuance model. Paid certificates are issued for a year or more, while Let's Encrypt issues them for a short period, so renewal must be automatic.

This is not a drawback but a discipline: a short period means that if a key is compromised, the risk window is measured in days, not months.

Manual renewal simply does not work here — forget to renew, and the site greets visitors with a warning about an insecure connection, which hurts trust and search rankings.

In terms of trust level, the difference shows up in specific scenarios. A free DV certificate confirms only domain ownership — this is enough for websites, online stores, personal accounts, and APIs.

Paid OV and EV certificates additionally verify the organization and display it in the certificate: this is in demand in banks, the public sector, and payment gateways, where legal identification matters. If your scenario is an ordinary web service, there is no difference in trust for the client.

Support is a separate matter. A paid certificate comes with a contract, a guarantee, and a support service, while Let's Encrypt offers a community and automation.

In practice, this means: the paid option requires manual renewal control, while the free one requires a once-configured mechanism that renews the certificate itself and reloads the web server without downtime. For most projects, the second path is more reliable because it eliminates the human factor.

The choice is determined by the scenario: where organization verification is needed, a paid one is chosen; where automation and the absence of downtime matter, Let's Encrypt is chosen.

We set up issuance and auto-renewal so that renewal happens without intervention and without loss of availability.

Common technical concerns about SSL configuration

The concerns are usually the same: "we already have certificates from another authority — will we have to break everything?", "there are dozens of domains, is this manual work?", "internal services can't be exposed to the outside at all." Let's go through them one by one — these are exactly the places where Let's Encrypt configuration either goes smoothly or turns into downtime.

There are several domains — is this manual work for each one?

No. A certificate is issued for a list of domains and subdomains at once, and ownership verification is configured only once: either via a file in the site root or via a DNS record. After that, renewal happens automatically for the entire list.

An important nuance is the limits on the number of issuances: if there are many domains and they change frequently, it makes sense to combine them into a single certificate with a margin on validity periods, rather than issuing one per subdomain.

Internal services must not be accessible from outside — what should we do?

For internal services we use verification via a DNS record: it proves domain ownership without exposing the service to the outside. This way, private panels, test environments, and service addresses get a valid certificate while remaining inaccessible from the internet.

Ownership verification happens on the DNS provider's side, and the service itself continues to live on the internal network.

Compatibility with legacy clients and mobile applications

Let's Encrypt certificates are trusted by the vast majority of modern browsers and mobile platforms. Problems arise only on outdated devices where the root certificate hasn't been updated for years.

Before migration, we check which clients actually connect to your service, and if any of them are like that — we keep a separate node with the old certificate for them until the fleet is updated.

Each of these concerns is resolved at the design stage, not at the moment of failure. Describe your setup — how many domains, whether there are internal services, which certificate authority is currently in use — and we'll come back with an estimate and a migration plan.

Let's discuss your task and get back with an estimate

To get back with an estimate rather than generalities, we need a snapshot of your current configuration: where TLS terminates, who issues certificates, how load balancing is set up, and what is already configured for automatic renewal.

Based on these inputs, we will propose a work plan and an estimate — with no obligation on your side and no "we'll clarify later."

What to describe in your request so the conversation is to the point:

• Where certificates currently live: on a single server, on a load balancer, in a reverse proxy, or distributed across multiple nodes.
• How they are issued and renewed: manually, on a schedule, through a dedicated certificate management service.
• How many domains and subdomains are in scope, including service and staging environments.
• What is already breaking: expired certificates, desync between nodes, manual reminders, renewal errors.
• Infrastructure constraints: isolated environments without external access, an in-house certificate authority, access requirements.
• Who is responsible for operations and what change windows are acceptable.

Next, we will compare this against a typical automation scenario and get back with a plan: which domains we move to automatic renewal, where we place expiration checks, how we set up notifications, and what we do with nodes that have no direct outbound access.

The plan will include a sequence of steps, areas of responsibility, and rollback points — so that changes don't take down production traffic.

The next step is simple: send a free-form description of your configuration or a link to a diagram. We will review it, ask clarifying questions, and get back with an estimate and a work plan for setting up Let's Encrypt with automatic renewal.