7 Myths About Automating TLS Certificate Renewal (and What's Actually True)

Automating TLS certificate renewal does not mean giving up control. Your private key stays on your own servers, renewals run on your schedule, follow-up actions run automatically, and approvals stay with the team that owns each system. Only the identity checks a certificate authority performs by hand for OV and EV certificates stay manual.

One expired certificate can stop a business.. In July 2024, an expired certificate took down the Bank of England's RTGS payment system. Size did not protect the organisation. Only a reliable process does.

That process is about to get much harder to run by hand. In April 2025, the CA/Browser Forum approved ballot SC-081, which cuts the maximum lifetime of public TLS certificates step by step:

At 47 days, every certificate needs renewing roughly eight times a year. Spreadsheets, calendar reminders and tickets will not keep up, so automation is the only realistic option.

Yet when we talk to IT and security teams, we hear the same concerns again and again. Below are the seven most common assumptions about certificate automation, and what is actually true, based on how ASEE's Certiligent platform and its agent work.

Myth 1: "Our private key would have to leave our infrastructure"

Reality: your private key never leaves your infrastructure. It is created on your server or device and stays there for its whole life.

This is the concern we hear from almost every client, and rightly so. Here is what actually travels to Certiligent:

• At registration: only a public key.
• At issuance or renewal: a Certificate Signing Request (CSR). A CSR is a signed request that contains the public key and the domain details, never the private key.

The answer is the same whether you use the Certiligent agent or a standard ACME client. ACME (Automatic Certificate Management Environment) is the open protocol for automating certificate issuance and renewal.

Myth 2: "Every certificate goes through a manual company check, so it can't be automated"

Reality: it depends on the certificate type. Domain checks are fully automated. Only the identity check a certificate authority (CA) performs on your company is manual, and that check does not have to happen at every renewal.

The manual step sits with the CA, so no platform can skip it, Certiligent included. But the company check and the domain check run on different clocks:

• Company (organization) validation can be reused for up to 398 days since 15 March 2026. In practice, the CA vets your company about once a year.
• Domain control validation can be reused for 200 days now, 100 days from March 2027 and only 10 days from March 2029.

So in the 47-day world, an OV certificate will look like this: one manual company check per year with the CA, and about eight renewals in between that each need only a fresh domain check. Certiligent automates that domain check. If the CA's company validation has lapsed, the CA will not issue the certificate, so keep the yearly vetting in your calendar.

Myth 3: "Someone still has to deploy the renewed certificate by hand"

Reality: post-renewal actions are defined once and then run automatically. Nobody has to log in to apply the new certificate or notify the teams that depend on it.

In Certiligent, you set up what should happen after each renewal in advance, for example:

• restarting the service that uses the certificate
• creating a PKCS#12 (.p12) file
• installing the certificate into a truststore

You also define a grace period: how many days before expiry the renewal should happen. That way a renewal never lands at the last minute.

Myth 4: "Our infrastructure isn't standard. HSMs, clusters and containers can't be automated"

Reality: they can, with some extra setup for your environment. The private key still never leaves your hardware.

• Hardware security modules (HSMs): the CSR is signed inside the HSM, so the key never leaves the device. The setup depends on the HSM vendor and how the partition is accessed.
• Clusters: one agent runs on a management server and distributes certificates to the cluster nodes through their API or commands.
• Containers: a single agent can serve several containers at the same time.

Myth 5: "Our internal CA sits behind a firewall, so it can't connect to a SaaS platform"

Reality: a site-to-site VPN connects Certiligent to your environment. The same automation then works for internal CAs as for public ones.

• Same principle for public and private PKI: discovery, renewal and deployment work the same way for certificates from internal and public issuers.
• No domain validation needed: an internal CA does not have to run DV checks.
• No ACME needed: if your internal CA does not support ACME, Certiligent integrates with it over a REST API instead.
• Supported internal CAs include EJBCA and Microsoft Certificate Services (MSCA).

This matters because the 47-day rules apply only to publicly trusted certificates. Internal certificates are not forced to shorten, but they expire too, and they cause the same outages when they do.

Myth 6: "Renewal will happen in the middle of a working day and disrupt our traffic"

Reality: you decide when renewals run. They can be scheduled for nights or weekends, to fit your maintenance windows.

• Renew a few days before expiry, never on the day itself. If the CA is briefly unavailable at the scheduled time, the agent simply retries later, and the buffer means nothing expires in the meantime.
• Scheduling is set per agent. Today the schedule applies to everything an agent manages on a server, not to each certificate on that server individually. If two certificates on the same server need different windows, plan for that during setup.

Myth 7: "Automation means losing control over who approves what"

Reality: approval stays with the person or team responsible for each system. Automation runs the renewal; it does not take the decision away from the people who own the service.

Larger organisations often have separate teams for networks, applications, cloud and security. With Certiligent, approving a certificate for a system stays with the team that runs it, so there is no need for one person or one central team to oversee and control everything.

Key takeaways

• Your private key is created and kept on your own servers or HSMs. Only public keys and CSRs reach Certiligent.
• DV certificates can be fully automated. For OV and EV, the CA's company check stays manual, but only about once a year.
• Deployment steps, restarts and truststore updates run automatically after each renewal.
• HSMs, clusters, containers and internal CAs are supported, with setup tailored to your environment.
• You control when renewals happen and who approves them.

Tired of chasing renewals?

Certiligent automates certificate issuance, renewal, and deployment, with zero manual steps.

See how it works

Certificates don't need remembering. They need automating. See how Certiligent discovers, renews and installs certificates across your infrastructure. Contact ASEE to assess your readiness before the next deadline.

Frequently asked questions