Automating SSL/TLS certificate renewal in FortiGate environments

At a glance

What this is: This is an analysis of automating SSL/TLS certificate renewal on FortiGate, with the key finding that automation shifts operational risk from manual renewal to configuration and renewal governance.

Why it matters: It matters because identity and security teams still own certificate lifecycle control, and a failed renewal can create avoidable outages, trust breakage, and weak governance over machine identities.

Context

SSL/TLS certificate renewal is a lifecycle control problem, not just an admin task. When renewal is automated, the control burden moves from humans remembering expiry dates to systems maintaining the right configuration, bindings, and renewal thresholds.

For identity and security teams, that matters because certificates are machine credentials. In FortiGate environments, automation can reduce manual effort, but it also creates dependency on the ACME integration path, certificate validity timing, and reliable offboarding of old configuration states.

Key questions

Q: What fails first when FortiGate certificate automation is misconfigured?

A: The first failure is usually the renewal path, not the certificate itself. If the ACME account binding, server URL, or threshold is wrong, the system can appear configured while silently missing the renewal window. That is why teams need monitoring for unrenewed certificates and explicit ownership of the renewal workflow.

Q: Why does certificate automation increase governance risk in security appliances?

A: Because automation replaces a visible manual task with a persistent dependency on configuration accuracy. If no one owns the renewal policy, failure detection, and fallback path, certificate expiry becomes a hidden operational risk. In practice, the business impact is service disruption and loss of trusted TLS connectivity.

Q: What are the signs that certificate renewal is failing before the certificate actually expires?

A: The clearest signs are repeated alerts, inconsistent validation across IPv4 and IPv6, and monitoring that reports green while renewal never completes. Teams should also watch for infrastructure changes that introduce proxies, extra records, or alternate termination points. If expiry checks only cover one path, they can miss the route that actually governs certificate renewal.

Q: Who should be accountable for SSL/TLS certificate lifecycle in network appliances?

A: Accountability should sit with the team that owns the appliance, the CA integration, and the renewal policy end to end. Security may set the control requirements, but operations must own the configuration, monitoring, and fallback execution. Without clear ownership, renewal automation becomes an orphaned control.

Technical breakdown

ACME renewal on FortiGate depends on correct account binding

ACME automates certificate issuance and renewal by letting the client prove control of the domain to the certificate authority, then request new certificates before expiry. In this FortiGate workflow, the important control point is not the certificate request itself but the external account binding used to connect the firewall to the CA service. If that binding, server URL, or account data is wrong, the renewal path can fail even though the initial setup looked complete. The result is a hidden dependency chain, where the certificate lifecycle is only as reliable as the configuration behind it.

Practical implication: Treat ACME account binding as a governed dependency and validate it as part of certificate lifecycle monitoring.

Renewal timing matters more than manual issuance effort

Automated renewal works only if the renewal threshold is set early enough for the system to act before expiry, but not so early that it creates unnecessary churn. The article shows a configurable remaining-validity window that triggers renewal when a certificate reaches a specified number of days left. That makes timing a policy decision, not a convenience feature. In practice, renewal automation replaces calendar reminders with a control that must be tuned to the environment, certificate validity period, and change window behaviour.

Practical implication: Set renewal thresholds with enough safety margin to absorb CA delays, maintenance windows, and failed first attempts.

GUI limits shift governance to command-line configuration

The article notes that the ACME setup is performed through CLI rather than the GUI, which changes the governance model for certificate operations. A task that would normally sit in a visible admin workflow now becomes scriptable and less obvious to casual operators. That can be beneficial for repeatability, but it also means the organisation needs stronger change control, review, and documentation around certificate automation. In certificate lifecycle terms, the technical debt is not automation itself, but invisible configuration drift and unmanaged exceptions.

Practical implication: Place ACME configuration changes under formal change control and keep a documented fallback process for manual renewal.

Threat narrative

Attacker objective: The practical objective is not direct compromise of the firewall, but disruption or degradation of trusted certificate operations through weak lifecycle governance.

1. Entry occurs through the operational dependency created by external ACME configuration on the firewall and CA service connection.
2. Credential or binding abuse would arise if the account link, server details, or renewal settings were misconfigured or left stale.
3. Impact is certificate renewal failure, which can lead to expiry drift, service disruption, and loss of trusted TLS connectivity.

Breaches seen in the wild

• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
• CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Certificate automation shifts the control plane from issuance to lifecycle governance. The article shows that ACME reduces manual renewal work, but it does not remove the need for policy, validation, and monitoring. In identity terms, the certificate becomes a managed machine credential, and the real control is whether renewal still happens before service trust expires. Practitioners should treat automation as a governance redesign, not a convenience feature.

External account binding is the brittle point most teams will underestimate. The article's configuration path depends on the ACME server URL, account binding, and renewal parameters all remaining aligned. That is a classic lifecycle assurance problem: the asset can be healthy while the renewal path is already broken. Teams should assume certificate automation can fail silently unless binding integrity is monitored.

FortiGate certificate renewal exposes a broader machine identity problem. Certificates, API keys, and service tokens all behave like non-human identities when their validity depends on configuration rather than human memory. The named concept here is renewal drift: the gap between a credential's intended renewal policy and its actual operational state. Practitioners should close that gap with alerts, ownership, and recovery runbooks.

Automation improves consistency only when exception handling is explicit. If the organisation cannot explain who reviews renewal failures, who owns CA integration changes, and how manual renewal is triggered, then automation is only reducing visible labour. It is not reducing risk. The practical conclusion is to govern the exception path as tightly as the normal renewal path.

What this signals

Renewal drift: automation exposes a new class of failure where the certificate lifecycle policy exists, but the operational renewal path no longer matches it. That is a governance issue, not a tooling issue, and it deserves the same oversight you would apply to any managed machine credential.

When certificates are tied to external account binding and renewal thresholds, lifecycle assurance becomes a control objective in its own right. For practitioners, the key question is whether expiry will be detected and corrected before users or services experience trust failure.

For practitioners

• Define a certificate renewal owner Assign one team accountable for ACME configuration, renewal thresholds, and certificate replacement on FortiGate. The owner should verify that the ACME account binding and server settings remain current after every change.
• Monitor expiry drift continuously Alert on certificates that are inside the renewal window but have not rotated, and on certificates that are nearing expiry without a recent renewal event. Treat missing renewal telemetry as a control failure, not a logging issue.
• Test the manual fallback path Document how to renew or replace the certificate if ACME fails, including who can execute the CLI workflow and how to validate the updated certificate on the virtual server.
• Review renewal thresholds against change windows Set the remaining-validity trigger early enough to survive maintenance windows, CA delays, and change freezes, then recheck that threshold whenever certificate validity periods change.

Key takeaways

• Automated SSL/TLS renewal reduces manual effort, but it does not eliminate the need for ownership, monitoring, and recovery planning.
• The most important failure mode is not issuance failure. It is silent renewal drift caused by configuration errors, stale bindings, or poor timing.
• Teams should govern certificate automation as a machine identity lifecycle control, with explicit thresholds, fallback procedures, and change oversight.

Key terms

• ACME: ACME is a protocol used to automate certificate issuance and renewal between a client and a certificate authority. For practitioners, it reduces manual renewal work, but it also introduces a dependency on correct client configuration, credential handling, and monitoring of the automation path.
• Certificate Renewal Window: A certificate renewal window is the period in which a certificate must be replaced before expiry to avoid service disruption. Shorter validity periods compress this window and increase operational pressure, which is why renewal processes need to be automated and monitored continuously rather than handled manually.
• External Account Binding: External account binding ties an ACME client to the CA account that authorises certificate requests. It gives the issuing authority a way to link a renewal action to a known account, improving accountability and reducing the chance of unauthorised issuance.
• Expiry Drift: Expiry drift is the gap between a certificate's intended renewal policy and the point at which it is actually renewed or expires. It usually reflects weak monitoring, broken automation, or unclear ownership rather than a failure in certificate issuance itself.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build lifecycle controls that hold up under automation and change.