Automating SSL/TLS certificate renewal in FortiGate environments

At a glance

What this is: This post explains how ACME-based automation can renew SSL/TLS certificates on FortiGate VM deployments and what configuration steps are required for renewal to work reliably.

Why it matters: It matters because certificate lifecycle failures create service outages and governance gaps, and identity teams should treat certificates as managed credentials inside broader workload and machine identity programmes.

By the numbers:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

👉 Read Cybertrust Japan's guide to automating SSL/TLS certificate renewal on FortiGate

Context

SSL/TLS certificates are operational credentials, not just web security artefacts. When renewal is manual, expiry becomes a governance problem because a missed date can break trust chains, interrupt access, and expose weak ownership across application and infrastructure teams. In this case, the primary keyword is SSL/TLS certificate renewal, and the article focuses on how to automate it for FortiGate VM environments.

The identity angle is real because certificates are a form of machine identity with lifecycle controls, renewal timing, and revocation dependencies. For IAM, PAM, and workload identity teams, the lesson is that certificate governance needs the same discipline as secret rotation and offboarding, even when the tooling sits in network security rather than identity platforms.

Key questions

Q: What fails when certificate renewal is only manually operated in appliance environments?

A: Manual renewal fails when ownership is unclear, expiry dates are not tracked consistently, or the replacement process depends on a single administrator. In appliance environments, those gaps can leave a valid certificate in place until it silently expires, which breaks trust and service continuity. Renewal should be treated as a lifecycle control with monitoring, ownership, and rollback planning.

Q: Why do SSL/TLS certificates need identity governance as well as security operations?

A: Certificates are machine identities with issuance, renewal, and replacement lifecycles. If teams govern them only as infrastructure artefacts, they miss ownership, validation, and offboarding controls that determine whether trust can be maintained over time. Identity governance gives certificate management an accountable lifecycle model instead of a reactive maintenance model.

Q: How do security teams know if automated certificate renewal is actually working?

A: Teams should verify successful renewal events, confirm the updated certificate is installed on the correct service endpoint, and test what happens as expiry approaches. A healthy automation process produces auditable renewal logs, consistent subject and domain bindings, and no last-minute manual intervention. If renewal is only assumed, the control is not working.

Q: Who is accountable when an automated certificate renewal path fails?

A: Accountability should sit with the service owner who depends on the certificate, the team that operates the renewal workflow, and the platform team that controls the domain or virtual server configuration. If those responsibilities are not documented, incident response will be slow and blame will move between teams instead of to the control owner.

Technical breakdown

How ACME automates SSL/TLS certificate renewal

ACME is a protocol for requesting, validating, issuing, and renewing certificates with minimal manual handling. In this workflow, the client proves control of the domain or endpoint, then the CA issues a certificate that can later be renewed automatically when the configured lifetime threshold is reached. The operational value is consistency, but the governance burden shifts to correct enrollment, correct domain binding, and correct renewal triggers. If those inputs are wrong, automation will faithfully repeat the failure instead of preventing it.

Practical implication: treat ACME enrollment as a controlled identity binding process, not a one-time setup task.

External account binding and CA trust relationships

External account binding links the requesting system to the CA account used for certificate issuance. That matters because it establishes which server or administrator is allowed to request renewals on behalf of the domain and prevents unauthorised certificate issuance through the same automation channel. In practice, this is a trust and ownership control, not just a technical requirement. If the binding is absent or misconfigured, renewal may fail or the organisation may lose clear accountability for which system owns the certificate lifecycle.

Practical implication: inventory every ACME account binding and associate it with an accountable service owner.

Certificate lifecycle drift in appliance environments

Appliance-based environments often hide certificate renewal behind GUI workflows, API calls, or CLI configuration steps, which makes drift easy to miss. A certificate can still appear healthy while the renewal path quietly depends on a specific hostname, port, validity window, or virtual server assignment. That creates a lifecycle risk similar to unmanaged secrets: the credential is present, but the renewal and replacement path is fragile. The stronger the automation, the more important it becomes to test expiry behavior before the certificate enters its final validity window.

Practical implication: test renewal paths under real expiry conditions, not just initial issuance.

NHI Mgmt Group analysis

Certificate automation is now a lifecycle governance problem, not a point product feature. ACME removes manual renewal work, but it also creates a dependency chain across domain ownership, validation, and account binding. That chain belongs in the same governance model used for secrets and workload credentials. Practitioners should treat renewal automation as a managed identity lifecycle.

Machine identity controls break when renewal is assumed instead of verified. A certificate that is configured once can still fail later if the renewal path is not tested, monitored, and owned. This is the same failure mode seen in unmanaged NHI programmes: credentials exist, but no one can prove they will be refreshed before expiry. The practical conclusion is that certificate lifecycle assurance must be evidence-based.

External account binding creates accountability, but only if the organisation maps it to service ownership. Without that mapping, the renewal channel may function technically while operating outside clear administrative control. That is a governance weakness because trust decisions and incident response both depend on knowing which team owns the binding, the domain, and the renewal threshold. Practitioners should formalise certificate ownership the same way they formalise service account ownership.

Shorter certificate lifetimes make automation mandatory, but they also raise the cost of configuration drift. As renewal windows narrow, manual exception handling becomes harder to justify and harder to recover from. That shifts the market toward lifecycle-aware controls, inventory, and monitoring rather than ad hoc certificate maintenance. The likely outcome is that certificate governance converges more closely with broader machine identity management.

Named concept: certificate renewal drift. This is the gap between a certificate's current validity and the organisation's ability to renew it reliably before expiry. It appears when ownership, validation, or timing controls are incomplete. Practitioners should monitor drift as a lifecycle failure indicator, not as a simple certificate housekeeping issue.

What this signals

Certificate renewal drift will increasingly look like a machine identity governance issue rather than a network administration task. As certificate lifetimes shorten and automation spreads, teams will need evidence that renewal paths work under real expiry pressure, not just in staging. The control question becomes whether ownership, monitoring, and recovery are documented tightly enough to survive operator turnover.

For programmes that already manage secrets and service accounts, certificates should now sit in the same inventory and escalation path. That aligns with broader machine identity control expectations in the Ultimate Guide to NHIs and with identity assurance principles in NIST SP 800-53 Rev 5 Security and Privacy Controls.

The practical signal for practitioners is whether certificate renewal can be proven, not merely configured. If the team cannot show who owns the binding, when renewal will occur, and how replacement is verified, the environment still depends on manual rescue.

For practitioners

• Implement certificate ownership mapping Assign every SSL/TLS certificate to a named service owner, renewal path, and recovery contact so failures do not sit between infrastructure and identity teams.
• Test renewal before expiry windows Run renewal simulations against real FortiGate environments before certificates enter their final validity period, and confirm the updated certificate is applied to the correct virtual server.
• Track external account bindings Maintain an inventory of ACME bindings, the account that owns each binding, and the domain or FQDN each binding can renew.
• Monitor certificate drift as a control signal Alert on certificates approaching expiry, failed renewal attempts, and mismatches between the certificate configured on the load balancer and the one expected from the CA.

Key takeaways

• Automated SSL/TLS renewal reduces manual work, but it also creates a lifecycle governance obligation around ownership, binding, and expiry monitoring.
• Certificate failure is a machine identity problem when renewal paths drift, because trust can break even while the credential appears valid.
• The control that matters most is verified renewal before expiry, backed by accountable ownership and auditable replacement paths.

Key terms

• Acme: ACME is an automated protocol for issuing and renewing certificates with minimal manual intervention. It uses challenge validation to confirm control of a domain or service endpoint, then allows the certificate lifecycle to be repeated in a machine-driven way.
• 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.
• Certificate Lifecycle Drift: Certificate lifecycle drift is the gap between a certificate's current validity and the organisation's ability to renew or replace it reliably before expiry. It usually appears when ownership, monitoring, or renewal testing is incomplete.
• Machine Identity: A machine identity is a non-human credential used by systems, appliances, or workloads to establish trust. Certificates, tokens, and keys all fit this model when they are used to authenticate a service rather than a person.

What's in the full article

Cybertrust Japan's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step FortiGate VM configuration for ACME enrollment and certificate renewal.
• Exact CLI setup sequence used because the GUI cannot complete the ACME configuration.
• The external account binding and server URL values needed for successful renewal requests.
• Validation screenshots showing certificate update timing and the updated expiry date on the virtual server.

👉 Cybertrust Japan's full post covers the FortiGate ACME setup steps, validation flow, and renewal configuration details.

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 in operational terms. It helps practitioners translate lifecycle control concepts into policies that fit identity, infrastructure, and security programmes.