Notifications
Clear all
Topic starter
11/07/2026 8:34 pm
TL;DR: Automating SSL/TLS certificate renewal on FortiGate with ACME reduces manual certificate operations, but it also shifts governance to configuration accuracy, renewal timing, and dependency on the external account binding used by the CA integration, according to Cybertrust Japan. The operational risk is less about issuance itself and more about preventing silent renewal failure and certificate expiry drift.
NHIMG editorial — based on content published by Cybertrust Japan: SureHandsOn ACME x FortiGate, automated SSL/TLS certificate renewal
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Cybertrust Japan's guide to automating SSL/TLS certificate renewal on FortiGate →
SSL/TLS certificate renewal in FortiGate: what changes for teams?
Explore further
11/07/2026 9:02 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Automating SSL/TLS certificate renewal in FortiGate environments
