Documentation | CertSecure

v3.4.0 Release Notes

Release date: 18 November 2026

New Features

The v3.4.0 release of Encryption Consulting CertSecure Manager adds the following features:

Certificate Authority Integrations

Sectigo Partner Services (PS) CA Connector: Register Sectigo Partner Services, Sectigo's reseller ordering service, as a certificate authority, separate from Sectigo Certificate Manager. Request SSL/TLS certificates (DV, OV, and EV) from the standard enrollment screen using a template. Certificate orders can be collected, replaced, and revoked from CertSecure, and a pending order is tracked until Sectigo issues it.
Sectigo PS Organization Pre-Validation Tracking: Sign an organization up for OV or EV pre-validation from CertSecure Manager. Each sign-up is stored and shown with its status, stage, whether it can be used for orders yet, and the next action required. Sign-ups still in progress are re-checked with Sectigo automatically, at a limited rate so the account is not flooded with requests.
GoDaddy SSL (Credits) Integration: Onboard a GoDaddy account as a CA using its API key, secret, and customer ID (or shopper number). Enroll, collect, and revoke certificates against purchased certificate credits. Domain control validation is automated: CertSecure publishes the DNS TXT record and asks GoDaddy to re-check, so orders no longer wait for manual DNS edits. Inventory sync also finds certificates issued outside CertSecure.
GoDaddy Automated SSL Integration: New connector for GoDaddy's subscription-based, auto-reissuing 90-day certificates, issued over ACME. The External Account Binding is derived from the same API key and secret, so nobody has to copy an HMAC key by hand. It shares one license entitlement and one dialog (with a Product Model selector) with GoDaddy SSL, and syncs the account's full certificate inventory.
GlobalSign Atlas ACME Integration: Adds GlobalSign Atlas over ACME as a second connection type next to the existing Atlas mTLS connector, using the account's EAB Key ID and MAC key. A single GlobalSign dialog has a Connection Type selector. Certificates use the Atlas ACME 200-day term. A mistyped MAC key is rejected at onboarding instead of at first issuance.
Native ACME Connectors (Let's Encrypt, Google Public CA, AWS ACM ACME CA, Generic ACME): ACME issuance, renewal, and revocation now run on built-in connectors instead of certbot. The ACME account is stored encrypted in the database, so any CertSecure node can issue and several certificates can be issued at once. Any RFC 8555 ACME server can be onboarded by its directory URL, with optional External Account Binding. Every ACME CA is onboarded explicitly from CA Management.
AWS GovCloud Support (AWS Private CA and AWS Certificate Manager): AWS GovCloud (US) regions can be selected when onboarding AWS Private CA and AWS Certificate Manager. Certificate template ARNs are adjusted automatically for the region's AWS partition, so templates work in GovCloud without manual edits.
Certificate Hold and Unhold (Microsoft CA): Place a certificate issued by a Microsoft CA on hold, and release it later, without permanently revoking it.
Automated DNS Domain Validation: One registry of DNS zones that CertSecure can write to, shared by every CA that needs domain proof: ACME dns-01, Sectigo CNAME DCV, GlobalSign domain claims, and GoDaddy DCV. Supports Cloudflare, AWS Route 53, GoDaddy DNS, and about 90 other providers, and reuses credentials a CA connector already holds. Before the CA is asked to validate, the record is confirmed on the zone's authoritative nameservers.
Guided CA Onboarding with Credential Test and Default Template: The Add and Edit CA dialogs test credentials against the CA's live API and fill dropdowns with the account's own products, organizations, and profiles. Each CA is registered with a default certificate template, so the first inventory sync is tagged correctly and enrollment works straight away. Saved credentials can be re-tested without retyping them.
CA Credential Health Indicator: Each CA in CA Management shows whether its stored credentials still work: Valid, Rejected, Unknown (CA unreachable), or Not configured. Credentials are re-checked in the background, after every edit, and on demand with Verify Credentials, which is recorded as a task. Rejected appears only when the CA itself refused the credential, so a revoked or rotated key is caught before an enrollment fails.
Pending CA Orders (Awaiting CA): Public-CA orders that take minutes or days to validate are tracked as Awaiting CA instead of failing. CertSecure collects each order by ID in the background. When the certificate is issued, it completes installation, the inventory update, and notifications. No duplicate order is placed or paid for.

Certificate Management

Manual Third-Party Certificate Import and Attach: Register a third-party certificate in inventory from typed metadata alone (common name, serial number, expiry, SANs, organization fields, and tags), with no PEM needed up front. The real certificate can be attached later, by its owner or an administrator. Duplicate serial numbers within the same CA are rejected, and attaching is refused if a certificate is already attached or if the serial number does not match the one entered. Download and PFX export no longer fail for records that have no certificate yet.
Re-run Failed Tasks: A failed certificate task can be re-run from the Tasks screen with its original request. If the first attempt already placed an order at the CA, CertSecure adopts that order instead of creating a duplicate.
Certificate Trust History and Trust Store Management: CertSecure records when a certificate's chain changes, such as a new intermediate, a cross-sign, or a distrusted root. Changes appear in a History tab beside the chain, and PKI Admins, the owner, and watchers are notified. Trusted roots come from the bundled Mozilla root store, so no internet access is needed (air-gap safe). Administrators can import or remove roots, and a removed root stays removed.
Out-of-Band Revocation Detection: Certificates revoked outside CertSecure, for example in the CA's own console, are detected through OCSP and CRL checks. They are marked Revoked in both enrollment and inventory, and the owner and PKI Admins are notified. Certificates issued under a revoked intermediate CA are identified and reported too.
ServiceNow Change Requests: Raise a ServiceNow change request (standard or normal) from a certificate, enrollment record, Renewal Manager endpoint, or task, or as a standalone request. Rules can raise changes automatically for renewal and revocation tasks and for expiring certificates. One open change is kept per item and action, and CertSecure operations do not wait for approval.
CertSecure Enrollment Gateway (EST / CMPv2 / CMC): Devices and network equipment that enroll over EST, CMPv2, or CMC can get certificates from supported connected CAs through the downloadable Enrollment Gateway agent. Gateways register with a token and report a heartbeat, and their authentication profiles are managed in CertSecure. Requests go through the usual approvals, policy checks, and audit trail. CMPv2 key update (re-key) and per-serial certificate status lookup are included.
Per-CA Risk and Issue Counts on the Dashboard: The dashboard shows risk and issue counts for each CA.
Status Filtering for Third-Party and Self-Signed Certificates: Third-party and self-signed certificate queries can be filtered by status.

Certificate Discovery

Java Keystore Discovery: Discover certificates in JKS, JCEKS, and PKCS12 keystores on Windows and Linux paths, including the default Linux Java truststores. A password is needed only for PKCS12. Windows-path scans run only on Windows agents, which now report their OS at registration.

Renewal Manager

Database Servers (SQL Server, MongoDB, Oracle): Agentless certificate renewal now covers Microsoft SQL Server, MongoDB, and Oracle Database as well as web servers. SQL Server needs the instance name and SQL service account; MongoDB needs the certificate file path and the service to restart; Oracle needs the wallet path, the wallet password (stored encrypted), and the listener service. Renewal Manager installs the new certificate and restarts the service.
Per-Endpoint Renewal Configuration: Each endpoint on a server now has its own CA, template, owner, and DigiCert settings. Automation is also set per endpoint instead of for the whole Renewal Manager, with a renewal window of 2 to 35 days before expiry. Endpoints can be edited in place instead of being deleted and re-added, and a save does not overwrite a change someone else made in the meantime. While automation is on for an endpoint, manual and scheduled renewals for it are refused, so two renewals cannot run against the same endpoint. Applies to IIS, Apache, Tomcat, Nginx, SQL Server, MongoDB, and Oracle.
Bulk Endpoint Automation: Turn automated renewal on or off for many endpoints of a server in one action, and set their renewal window together. A newly added endpoint starts with automation off, so nothing on a live server is renewed until an administrator switches it on.
Push Certificate: Provision a new certificate onto a server already registered in Renewal Manager, without linking it to an existing endpoint. Supply the subject details, SANs, and key size (2048, 3072, or 4096 bits). The certificate goes to the Windows certificate store for IIS and SQL Server, to a directory you choose for Apache, Nginx, Tomcat, and MongoDB, and to a wallet for Oracle. Nothing is rebound and no service is restarted, so administrators put the certificate into use on their own schedule.
Service to Restart per Server: Each server now names the service to restart after a renewal, in place of a free-form restart command. If it is left blank, the default service for that server type is used.
DigiCert Renewals: Servers and F5 profiles that renew from DigiCert store the DigiCert organization and order validity, and both are sent with every renewal order. When a server's CA is changed, its DigiCert settings are cleared unless new ones are supplied, so they are never sent to a different CA.
Per-Server and Per-Device Task History: View the renewal history of a single Renewal Manager server (manual renewals and expiry scans), or the full task history of a single F5 device (syncs and renewals in every status), with the logs for each task.
Server-Level Endpoint Automation: Automation for server-level endpoints is handled correctly. Renewal Manager now reports its automation types when it checks in with CertSecure, and Cisco ISE endpoint renewal settings follow the new automation types.
Java Keystores: Renew certificates held in JKS and PKCS12 keystores, with keytool-based key generation for Linux Tomcat.
AudioCodes Mediant SBC: Renew TLS contexts on AudioCodes Mediant SBCs, with keys generated on the device.
Palo Alto Networks PAN-OS: Agentless certificate renewal for Palo Alto firewalls and Panorama over the PAN-OS XML API. Renews local or template certificates, with template-stack push. After commit, it verifies that each listed host (for example, GlobalProtect gateways) serves the new certificate, and rolls back automatically if a listener stops responding. IKE-only certificates are supported.
Cloudflare Integration: Cloudflare is supported as a certificate target in CertSecure and Renewal Manager, including CSR generation and endpoint management.
Cisco ISE Integration: Certificate management for Cisco Identity Services Engine endpoints through Renewal Manager.
Cisco ACI Integration: Certificate management for Cisco ACI, including key ring and trustpoint handling. Key ring and trustpoint names use prefixes, validation rules are enforced, and SANs are required.

F5 BIG-IP Orchestrator

F5 BIG-IP Orchestrator: One agent manages certificates across many F5 BIG-IP devices. Each device is onboarded with its hostname and credentials, which are encrypted so that only the registered agent can read them. The Orchestrator finds every client-SSL and server-SSL profile in every partition, including each certificate/key/chain entry. It re-syncs every 12 hours by default, or on demand with Sync now, which can be queued while the agent is offline. Administrators see the certificate currently bound to each profile and choose which profiles CertSecure manages, and with which CA, template, and owner.
F5 Zero-Touch Certificate Renewal: Turn on automation for a managed F5 profile and CertSecure renews its certificate before expiry (15 days by default) with no manual steps. It issues the certificate, uploads it with its chain, updates the profile, and saves the F5 configuration. Renewals can also be run on demand, either all the way through (renew and bind) or stopping after the upload (renew and push), or scheduled for a maintenance window. Only one job runs per device at a time. A failed automated renewal is retried after six hours, and a job that stops making progress is marked failed so it does not block the device.
F5 Push Certificate: Provision a new certificate to any partition of an F5 device. The key and CSR are generated on the F5, so the private key never leaves the device. CertSecure gets the CSR signed by the chosen CA and installs the certificate and chain in that partition. The certificate is left unbound so the administrator can attach it to whichever profile they choose.

Alerts, Notifications, and Licensing

Configurable Certificate Expiration Alert Tiers: Expiration alerts now use the alert durations configured in CertSecure instead of fixed 7/30/60/90-day buckets. The weekly digest email now includes the most urgent tier, which was previously left out.
PKI Health and License Expiry Alerts: Tiered, mandatory alerts on a 30/14/7/2/1-day ladder for expiring CA certificates, expiring CRLs, missing or stale health configuration, and missing or corrupted health data. A matching countdown covers CertSecure license expiry. Supported for MSCA, AWS PCA, AWS ACM, GlobalSign, and Sectigo. Each tier fires once per occurrence and resets when the condition clears (certificate renewed, fresh CRL published). Emails state the actual days remaining or overdue, and recipients are managed through a new PKI health alert emails setting.
Notification Sync: Notification settings and state are kept in sync.
Microsoft 365 (Entra ID) and SendGrid Email Delivery: CertSecure email (alerts, approvals, and reports) can be sent through Microsoft Graph using an Entra ID app registration, with no SMTP AUTH or mailbox password. SendGrid's API is also supported, and standard SMTP is still available. Secrets are never displayed after saving, and large attachments are delivered reliably.
License Certificate Limit: A new license claim, Certificate Limit (across all CAs), is stored on activation. The license view shows the Certificate Limit (unlimited for older licenses) and the Certificate Count (all inventory records), and the UI shows usage. The limit is not enforced yet. Existing customers see unlimited until they activate a new-format license.
License Usage Reminder Email: At 90% or more of the certificate limit, the license-alert recipients (global Admins, PKI Admins, and additional alert emails) receive a reminder to upgrade, with a per-CA table. It repeats every 7 days while usage stays at or above 90%, is sent immediately on a new license or limit, and re-arms once usage drops below 90%. Unlimited licenses never alert.

Authentication and User Security

On-Premises Active Directory / LDAP via Keycloak: Connect on-premises Active Directory (or Red Hat DS, IBM Tivoli, eDirectory, or other LDAP) from the CertSecure UI. Includes vendor presets, a connection test, and automatic attribute mapping (User Principal Name, email, names, and groups). Directory users are synced before their first login, so departments, approvers, and watcher groups can be assigned in advance, and AD groups can be mapped to departments.
Directory User Deregistration and Orphaned-Account Alerts: A deregistered directory user is not re-created by the next sync, and their API tokens are revoked. They appear in a Deregistered list and can be added back from there. Users who disappear from the directory are reported to administrators by email instead of being deleted, so their certificate ownership and approver roles are kept.
Single Browser Session per User: A new interactive sign-in signs the user out of any earlier browser session, so one account cannot be active in two browsers at once. The earlier tab is told it was signed out elsewhere. API tokens are not affected. This is on by default and can be turned off in server configuration.
Self-Service Forgot Password: Users can reset a forgotten password from the login page. CertSecure emails a single-use reset link that is valid for 30 minutes and gives clear password-policy feedback. After the reset, the account is signed out of all sessions. Repeated requests are rate-limited without revealing whether an account exists.

PKI Assistant, MCP, and API

PKI Assistant: A chatbot assistant for CertSecure Manager, available in the UI. A Stop button lets users halt a response in progress.
CertSecure CLM MCP Server: An MCP server for CertSecure certificate lifecycle management. MCP is an optional add-on with its own installer step. A backend restart does not update MCP, so re-run the installer's MCP step to update it.
OpenAPI 3.1 API Reference (ReDoc): A complete API reference, generated from the product itself, for Health, Inventory, Certificate Enrollment, Reports, and Tasks. The single-page ReDoc reference is at /api/redoc. Every input has a description, a realistic example, its required status, and its authentication. /api/spec provides the machine-readable contract for generating clients.

Enhancements and Bug Fixes

The v3.4.0 release of Encryption Consulting CertSecure Manager includes the following enhancements and bug fixes:

Security and Authorization

Certificate Ownership: Ownership checks in certificate enrollment now require an exact, case-insensitive email match. Previously, an email that was merely contained in the owner's email (for example, [email protected] and [email protected]) was treated as the owner for private-key/PFX download, revoke, renew, watcher-list edit, third-party delete/transfer, and certificate download/view. Users who had access only through such a partial match now get 403, and users whose login email differs from the stored owner only in capitalization now gain access to their own third-party certificates.
Ownership Transfer: Global admins are no longer refused (403) when transferring certificate ownership. PKI Admin is deliberately not admitted.
Bulk CSV Upload: The bulk upload no longer reads, writes, or deletes files in the install directory. The CSV is now stored in the database per user and file name, so two users uploading the same name no longer overwrite each other. Uploads are limited to 5 MB, are kept for 1 hour, and are kept after a validation error so they can be retried. Action required: CSVs uploaded before this fix but never generated may remain in the install directory. Review and delete stray *.csv files there by hand.
Logging (Personal Data): Certificate subjects and SANs, CSRs, PEMs, user emails and usernames, alert recipient lists, and email bodies are no longer written to the application log, which ships to SIEM. Logs carry identifiers and counts instead (such as task ID, EnrollmentID, and SAN count). SIEM searches that matched on those values will stop matching, and the /enroll_csr audit record no longer carries the CSR. An internal /enroll_csr failure is now audited as failed due to an internal error rather than as user is unauthorized. Routine ACME and GlobalSign debug lines moved to DEBUG, so there are fewer spurious ERROR and WARNING lines.
Logging (Sessions and Tokens): Authentication logs no longer contain session IDs or bearer tokens. They log a short non-reversible fingerprint (fp=<sha256[:12]>) instead of the session ID, using the same algorithm in the backend and MCP server so one search correlates a session across logs. Rejected bearer tokens are logged by length only. Search for the fingerprint instead of a raw session ID, and expire existing sessions if older logs were exposed.
Logging (Private Keys): Enrollment records, decrypted task payloads, and user records are no longer logged, so private keys and personal data no longer reach certsecure_backend.log and SIEM. Action required: logs written by earlier builds may already contain private keys. Rotate server-generated keys and purge old logs.
MCP: The find_certificate tool no longer returns the enrollment private key, CSR, certificate body, or p7b to the calling agent. A malformed CA restriction is now treated as restricted. Deregistered accounts are denied, and MCP reports CertSecure's version.
Security / API: ACME configuration and certificate template endpoints now require an authenticated session and a valid license. Private keys kept in task records for certificate re-runs are now encrypted at rest.
Splunk Integration: HEC tokens are redacted in logs, blank, whitespace-only, or malformed tokens are rejected before a request is sent, and health responses are logged as healthy or unhealthy. Reading and updating the Splunk configuration now requires authentication. Saving the configuration no longer fails (500) for session callers, audit logs are no longer lost silently, HEC health checks and request timeouts were added, and HEC requests are batched. Discovery agent logs now ship to Splunk as logType: Discovery Agent. The HEC host field strips or rejects a URL scheme and gives Splunk Cloud host and port guidance; the field is renamed from url to hec_host (both are still read), and host is now derived per record and refused on save.

Certificate Authorities

GoDaddy: GoDaddy certificates whose serial number starts with a zero are now matched correctly, so they are no longer duplicated in inventory and can be revoked.
CA Management: Let's Encrypt is no longer added automatically from the license. Every CA is onboarded by an administrator from CA Management.
CA Onboarding: Errors (wrong directory URL, CA refusal, TLS problems) now give a clear message naming the cause. Onboarding works through an HTTP(S) proxy, and ACME directory requests cannot reach loopback or link-local addresses. GlobalSign Atlas can now be registered when its validation policy fixes the extended key usages, and the template no longer asks for usages that cannot be chosen.
PKI Health: PKI Health now covers only the CAs it can act on, Microsoft CA and AWS Private CA, and no longer shows empty or misleading health data for public CAs. The Online/Offline heartbeat still covers every CA, and CAs with no active configuration are no longer shown as Offline.
HashiCorp Vault: Vault certificates now record extended key usages with the same names as every other CA connector (server_auth, not serverAuth), so EKU filters in reports, MCP tools, and the assistant include them. An unrecognized EKU is kept as its OID instead of the text Unknown OID. The CA/B Forum anyExtendedKeyUsage risk rule now works; it never fired before. After the first refresh following the upgrade, certificates that allow any extended key usage score High Risk, so High Risk counts may rise.
Connectors: A connector disabled in CertSecure no longer floods the backend with polls. It now waits 30 seconds between polls, doubling to a 5-minute cap, so re-enabling may take up to about 5 minutes to be noticed.

Enrollment and Tasks

Enrollment: Certificate requests are checked before they reach the CA: the CSR signature is verified, and the key type and size are checked against the template and CA policy (EC keys included), with a clear message on failure. Also fixed for Enrollment Gateway clients: non-PKCS#10 EST/CMPv2 requests, renewal keys, serials, status responses, and downloads. Requests now always include the common name in the Subject Alternative Names, so public and ACME CAs no longer refuse CN-only requests.
Enrollment (Status): Requests the CA rejected no longer stay Pending forever. They are marked Failed and counted separately on the dashboard, and records already stuck are repaired on upgrade. Denied certificates are no longer dropped from the inventory list when no template filter is applied, so dashboard counts and the inventory list agree.
Enrollment (Email): Resending a certificate email no longer fails when the record is found by serial number, denying a certificate no longer calls the approval routine with the wrong argument, and missing PKI admin lists no longer cause errors.
ACME: Failed ACME orders now show the CA's own reason (for example, a rejected CSR) instead of an empty or generic message, with a hint when the CSR has subject fields the ACME CA may not accept.
Policies: Password policy for PFX/ZIP downloads: messages now name the rule that failed, a maximum length is enforced, policies from earlier versions are handled, and only onboarded CAs are listed in the policy workflow.

Inventory and Reports

Inventory: A certificate stored twice (issuance and CA sync spelled the serial or order ID differently) is merged into one record on upgrade, and new duplicates are prevented. Revoked status is kept, and the repeated revoked outside CertSecure notification stops. The inventory also no longer stores a second copy of each certificate body, which reduces database size and speeds up CA inventory sync.
Certificate Chain: Chains for ECDSA-, RSA-PSS-, and Ed25519-signed certificates are now built up to the root instead of showing Not Trusted. The chain the CA supplied at issuance is used first, so chain building also works on air-gapped installations.
Reports: Signature algorithms are now named correctly in inventory and reports, including post-quantum algorithms such as ML-DSA, and SHA-1 signatures stay visible in risk reports.

Discovery

Discovery Scans: Scans running longer than 24 hours are no longer re-queued while the agent is still running them. Windows store scans use the OU and server filters from the scan configuration.
Discovery Failures: Cloud and HashiCorp Vault discovery failures show the actual cause, with identifiers removed from stored and logged text. One unreadable certificate no longer stops a host scan, and missing values are no longer stored as None.
Deleting a Discovery Scan: Deleting a scan now deletes the certificates it discovered, removes its configuration and cached analytics, and cancels its future scheduled runs. It runs as a background job with progress, so large scans no longer time out, and it is refused (409) while a run of the scan is in progress. The owner of each deleted certificate (or, for an unowned certificate, its watcher-group members) receives an email listing them. There is no config-only delete any more, and API callers now receive 202 with a job ID instead of 200 True. Known limitation: a certificate found by more than one scan belongs to whichever scan saw it last, so it may be deleted with one scan and reappear on another scan's next run without its owner.
Scan Details: Scan details no longer show a deleted scan's runs or certificate counts, and a scan recreated under the same name no longer inherits them. Run history is kept but hidden. Upgrade step: run internal_scripts/backfill_deleted_scan_tasks.py --apply once to clear scans deleted before this release.

Alerts

Expiry Alerts: Expiry alert emails are sent once per day again. Builds since late July could send the same daily alert many times a day. Alert emails no longer re-alert certificates every day, and the background email sender no longer stops permanently when SMTP is not configured and now retries. Duplicate To addresses are removed, the Alerts setting defaults to all when unset, and SMTP connections are closed after sending.
Alert Settings: Expiry alerts no longer stop for every CA when no alert tiers are configured. Saving alert settings no longer clears the configured tiers, and invalid alert durations are rejected with a clear message. Expiry-alert email attachments are no longer empty, and the unable to load PKCS7 object message no longer appears on the console at startup.

Users

Roles and Users: Role names are validated when users are registered or roles are assigned, so an unknown role is rejected instead of silently granting nothing. The View Enrollment Database permission name is corrected, and the CA list no longer fails with a server error for a deregistered user. The department-admin lookup returns an empty list instead of nothing when the department is missing.
Watcher Groups: Watcher group membership is updated when a user changes department or is deleted.

Renewal Manager and F5 Orchestrator

Reinstall and Re-registration: Reinstalling or re-registering Renewal Manager or F5 Orchestrator could leave the earlier install polling with its old token, taking tasks it could not decrypt credentials for and failing them with CSR generation failed. Now only the current install picks up renewals and syncs, and the old one no longer makes the agent show as online.
DigiCert: DigiCert renewals requested by Renewal Manager and F5 Orchestrator now include the certificate's SAN list and keep the DigiCert organization and validity, so they are issued the same way as an order placed from the enrollment screen. Servers saved earlier with DigiCert settings in an older format keep working unchanged.
Offline Queueing: Manual renewals and Push Certificate requests can be queued while Renewal Manager is offline, and run when it next checks in.
Server List: The server list now shows the service account each server uses. The password is still never returned.
Cleanup: The deprecated trust sync routes and related logic were removed from Renewal Manager, and ACI integration fixes were added following the initial release.

Agents and Packages

Packages: Obsolete per-server renewal agent packages (IIS, Apache, Nginx, Tomcat, SQL Server, and MongoDB) were removed from the installation bundle, because Renewal Manager covers these servers. The Renewal Manager package now ships as a signed executable. The F5 Orchestrator agent, Microsoft CA Connector, and Renewal Manager agent packages were updated, including the Palo Alto PAN-OS fix.

Deployment and Stability

Stability: Fixed 503 errors for several seconds after every backend restart, a login hang on a gunicorn worker, a CA document lost-update race that could revert health and expiry fields, and a strptime lock hang.
Startup: If MongoDB is unavailable at startup, CertSecure now reports it clearly and waits for it during host boot, instead of failing silently or exiting with a traceback.
Web Server: Security headers were added to the nginx configuration, large sign-in headers are supported, and the configuration is validated before nginx restarts, so a bad configuration no longer causes downtime.
Linux Installer: The RHEL-family installer has better OS detection and EPEL handling, verified downloads, Keycloak on Java 21, MongoDB log-rotation diagnostics, larger upload limits, and tooling PATH fixes. Unused dependencies were removed for a smaller install.
Containerized Deployment: Agent and connector downloads no longer return 404, and SSO login no longer fails because of an internal Keycloak URL. Known issue: MongoDB does not start on Linux kernels 6.19 to 7.0.13.

On this Page: