SSLNexus roadmap
Our goals, their current status, and the evidence needed to call them delivered.
Last reviewed: 26 October 2026. Current baseline: Client Server 1.0.12. Planned features are not available capabilities or delivery-date commitments. Purchase and deployment decisions should use the documented features of your installed release.
How to read this roadmap
- Planned
- A product goal with scope and acceptance criteria still to be completed. No delivery date is committed.
- Under consideration
- A candidate being assessed; implementation is not committed.
- In development
- Implementation has started and a concrete milestone can be identified. No item on this initial roadmap is claimed to have reached this stage.
- Released
- A published version, operating instructions and validation evidence are available. A roadmap entry alone is not release evidence.
HSM-backed key protection
Status: Planned · Delivery date: not committed.
Today: the local keystore encrypts supported stored artifacts using a same-host unlock key. The revised 1.0.12 installer enables it for fresh installations; upgrades preserve the existing setting. It does not provide native HSM/KMS wrapping or a general non-exportable-key signing path.
Goal: support externally protected key custody with a defined provider interface, explicit unlock policy, auditability and recoverable rotation. PKCS#11 is the selected first integration interface; supported HSM products and modules are not yet qualified.
- Separate HSM/KMS protection of storage-encryption keys from certificate keys generated and used inside an HSM.
- Define supported providers, supported adapters and how migration, backup, recovery and provider outages behave.
- Keep custody policy visible: identify which operations require exportable private keys and reject incompatible non-exportable-key deployments.
Completion evidence: a published provider/adapter support matrix; migration and rollback instructions; tested rotation, unavailable-provider and recovery cases; and demonstrations that keys promised to be non-exportable never pass through a PEM/PFX export path.
Dependency: many deployment targets require a PEM or PFX private key. HSM custody cannot be claimed for these workflows without target-side integration or an explicitly different custody model. Current key-protection limits.
Active-active controller HA
Status: Planned · Delivery date: not committed.
Today: operate one active controller per installation and use fenced backup/restore recovery. PostgreSQL replication and a load balancer alone do not make concurrent certificate workers safe.
Goal: allow multiple controller nodes to serve one logical installation while safely coordinating certificate jobs, renewal scheduling and deployment.
- Define cluster identity, node enrolment and licence/capacity accounting before enabling concurrent nodes.
- Coordinate database state, artifacts, secret access, sessions, audit events and plugin execution.
- Provide durable job ownership, fencing, retry/idempotency rules and a clear policy during network partitions.
- Define supported load-balancer, database and key-store topologies, rolling upgrades and disaster recovery.
Completion evidence: documented supported topology; tested node loss, process crash, partition and recovery; no duplicate issuance or conflicting deployment in those tests; and measured recovery objectives under a stated workload.
Dependency: HA and external key custody must agree on how every authorised node accesses keys. A failed or partitioned node must not continue acting as a second owner of a job. Current replacement-host recovery.
Further goals under consideration
These candidates have not been committed to implementation or a release date.
| Candidate | Problem to solve | Decision needed |
|---|---|---|
| Offline activation for restricted networks | Initial activation and some operations currently require Authority connectivity. | Define signed offline grants, expiry, revocation limits, capacity accounting and recovery identity. Outage tolerance is not an air-gapped mode. |
| DNS-01 for the installation certificate | The built-in local Let’s Encrypt route currently uses HTTP-01. | Choose supported DNS providers, least-privilege credentials, propagation checks and renewal behaviour. Existing external DNS-01 clients are a separate route. |
| Authenticated HTTPS bootstrap | First setup needs protection before the normal UI certificate exists. | Define trust enrolment without encouraging users to bypass browser warnings. Before a trusted UI certificate is available, an SSH tunnel provides an optional encrypted network path. Direct HTTP setup is supported only on a trusted management network with access restricted; the setup token does not encrypt that traffic. |
| Signed package repositories | Current downloads use release files and detached verification. | Define repository signing, key rotation, expiry, distribution support and rollback. Verify each release package today. |
| Client-to-Authority mutual TLS | Current client licensing uses HTTPS with application credentials. | Design initial enrolment, certificate renewal/revocation and recovery without introducing a circular activation dependency. |
| Independent security assessment | Implementation tests and SBOMs are not independent assurance. | Agree assessor, scope and remediation/publication process. No assessment booking or certification is claimed. |
| Recovery-key onboarding and target privilege reduction | Backup encryption needs a separately retained recovery identity; generated Linux setup currently grants broad sudo access. | Provide verifiable recovery-key custody and define constrained deployment privileges without breaking supported target workflows. No least-privilege guarantee is claimed for the current generated sudo policy. |
How progress will be recorded
At each release review, update this page’s review date and record changes below. Move an item to In development only when implementation has started. Mark it Released only with a link to the published version, applicable documentation and the evidence described above. Record changes of scope, deferrals and removed goals rather than silently deleting commitments.
Dates, priority order, supported providers and commercial availability remain uncommitted unless explicitly added here. Inclusion does not imply availability on a particular licence tier.
| Date | Change |
|---|---|
| 26 October 2026 | Initial roadmap: HSM-backed key protection and active-active controller HA recorded as planned goals. PKCS#11 selected as the first HSM interface; implementation and device qualification remain pending. Related candidates and completion criteria published for review. |
For functionality available now, use Features, Documentation and Versions.