In modern applications a TLS certificate is not just a security component — it is a direct part of availability. An expired certificate means a trust error on the user side, a connection rejection in API clients and, in some scenarios, a complete service outage. The failure typically surfaces while the application itself is running perfectly.
Short-lived certificates improve security but also increase operational burden. In a 90-day certificate cycle, a manual calendar, an email alert or an external script is not enough. Even if the certificate has been renewed, if it has not been applied to the ADC, the running service continues to serve the old one.
Enterprise environments also need more than one CA. When a rate limit, account problem or validation error occurs on one CA, a quick switch to an alternative provider is required. An architecture locked to a single CA makes certificate operations unnecessarily fragile.
In HA architectures the problem is more critical. If two devices try to issue certificates for the same domain using separate ACME accounts, rate limit and inconsistency risks arise. Certificate accounts, thumbprints and renewal state must be kept in sync across HA nodes.
TR7 ADC brings ACME certificate issuance and renewal — including account registration, threshold control, diff-detection, automatic checking and HA sharing — into the device's built-in certificate management flow.
TR7 treats ACME certificate renewal not as a one-off script but as a controlled, repeatable part of the certificate lifecycle.
Email address, CA selection, domain list, key type and EAB credentials are kept under the same structure. Missing or invalid fields are caught at registration time. Renewal flow therefore relies on a validated certificate object rather than ad-hoc command parameters.
TR7 checks certificates twice a day — morning and evening. When the remaining days drop below the per-certificate renewal threshold, the renewal flow starts. The operator does not need to maintain a calendar or write an external cron job.
When the CA, domain list or key type changes, TR7 treats this as a new certificate issuance. If the same configuration is preserved, only the renewal flow runs. This distinction prevents incorrect renew behavior when adding a domain or changing a key type.
The ACME account thumbprint is shared with the HA peer node. Both devices therefore behave consistently using the same CA account. Rate limit risk is reduced and certificate management stays within the same account chain during active-passive failovers.
ACME Cert Renewal brings CA selection, account registration, automatic renewal, HA sharing and audit visibility into a single certificate management flow.
TR7 ADC supports five CA options: Let's Encrypt, ZeroSSL, SSL.com, Buypass and Google Trust Services. The operator selects the provider through the certificate profile at creation time. This reduces dependence on a single provider. A different CA can be preferred for enterprise accounts, testing or services that require a different trust chain.
HTTP-01 challenge validates the domain over web traffic. When port 80 is reachable, a certificate can be issued without additional DNS integration. This enables fast onboarding especially for single-domain and standard vService scenarios. Wildcard automation is not claimed; this flow focuses on single-domain validation.
For CA accounts that require EAB, the key ID and HMAC credentials are stored in the certificate profile. The operator enters these through the interface; TR7 generates the authentication commands automatically. This reduces manual command errors in setups that use enterprise CA accounts. The onboarding process is simplified particularly for account-based ACME providers.
A certificate can include multiple domains. The domain list is stored as an array in the certificate object and each domain is processed with its own parameter in the validation flow. When a domain is added, TR7 detects this as a configuration change. The re-issuance flow then runs with the new domain set instead of incorrectly renewing the existing certificate.
A renewal threshold in days can be set per certificate. An earlier renewal policy — such as 60 days — can be applied for critical services; a shorter window can be chosen for standard services. TR7 compares the remaining days against this threshold. When the threshold is crossed, automatic renewal begins.
TR7 runs the certificate renewal check twice a day: at 07:00 and 22:00. This flow processes only certificates whose renewal window has arrived. The operator does not need to maintain an external cron job, shell script or manual checklist. Certificate renewal becomes part of the device's regular maintenance cycle.
When a certificate profile is first used and the relevant CA account does not yet exist, TR7 initiates account registration automatically. The account thumbprint is extracted and stored persistently. The same account is then reused for subsequent certificate operations. The operator does not need to manage a separate account registration process.
TR7 produces a configuration fingerprint from the CA selection, key type and domain list. If this fingerprint matches the previous value, the renewal flow runs; if it differs, a new certificate is issued. This behavior selects the correct action when the domain list or key type changes. Certificate management relies on change detection rather than assumption.
In an HA environment, both nodes share the same CA account credentials. This prevents the active and passive devices from repeatedly performing operations for the same domain using independent accounts. Rate limit and account conflict risk drops. After a failover, certificate management continues within the same account chain.
The default key type is ec-256. The operator can select ec-384 or RSA-based key lengths as needed. This preserves fast handshakes for modern clients while keeping the RSA option available for clients that require legacy compatibility. A key type change is treated as a new issuance flow.
During certificate issuance or renewal, process output is streamed line by line to the interface. Validation errors, rate limits, domain reachability problems or EAB issues are visible to the operator. This takes certificate renewal out of the black-box category. Troubleshooting time is reduced.
Account register, issue, renew, success and error events are written to the user log and audit stream. It is possible to see which operation ran for which certificate and when. With SIEM integration, certificate renewal events are forwarded to the central monitoring system. The certificate lifecycle becomes provable for compliance teams.
The ACME renewal flow does more than fetch a certificate — it works alongside account storage, process isolation, timeout handling, HA sharing and error management.
Each CA and email combination is kept in its own account directory. This prevents account credentials of different providers from mixing. Multiple CA accounts can be managed securely on the same device.
An upper time limit is applied to certificate issuance and renewal operations. Processes that run long or become stuck do not remain open indefinitely. Timeout, user-initiated stop and process closure are treated as separate states.
In multi-tenant setups and configurations using separate route tables, ACME operations can be executed through the correct network namespace. Challenge traffic therefore exits through the relevant tenant or zone's egress path. This reduces certificate validation errors in multi-network architectures.
When certificate issuance completes, the locations of the certificate, full chain and private key files are captured from the process output. TR7 reads these files and imports them into its own certificate store. The renewed certificate thus becomes available to the ADC.
The ACME account thumbprint is stored in persistent storage. Even if the device restarts, the account chain is not lost. HA sharing also continues based on this persisted information.
If certificate renewal fails, the error event is logged and can be forwarded to the central monitoring stream. A certificate approaching expiry can additionally be linked with the notification system. This allows the operations team to be alerted before the certificate expires.
Single-domain certificates for public web and payment vServices are issued via HTTP-01. TR7 checks the renewal threshold twice a day and renews the certificate as the expiry approaches.
Each tenant brings its own subdomain. TR7 stores the domain list in the certificate object and binds it to the relevant vService via SNI. Certificates are renewed in the background.
An enterprise CA provider requires EAB credentials. The operator defines the key ID and HMAC in the certificate profile; TR7 runs account registration and certificate issuance automatically.
In an active-passive TR7 pair, both devices share the same CA account thumbprint. Certificate operations remain consistent and the risk of unnecessary re-validation is reduced.
Certificate issue and renew events land in the audit log. During an audit it is possible to show which certificate was renewed, when, and which user or system event triggered the operation.
If a tenant's validation traffic must exit through its own network namespace, the ACME operation is executed in that context. Multi-tenant route separation is preserved while certificate renewal completes.
Five CAs, EAB, HA thumbprint sharing and twice-daily automatic checks — in a single certificate management flow. Let's walk through a live setup in your own environment.