Target Registry for certificate deployment packages
Every system aethercert can install a certificate into is described by a package: a signed manifest of operations, permissions and deployment steps. New products and new product versions ship as packages, without waiting for an agent release.
Installing first-party packages is available on every plan, Community included. See plans and limits
"apiVersion": "registry.aethercert.com/v2""kind": "DeploymentTarget""name": "netscaler-target""version": "2.0.0""versions": [">=13.0 <15.0"]"capabilities": ["certificate.importWithPrivateKey","certificate.inventory", "configuration.activate"]"permissions": { "network": ["{{ config.host }}"] }
What it does
A package declares what it needs - configuration fields, secrets, network destinations, access to the certificate and key - and the operations that use them: REST calls, PowerShell, file writes, service reloads and TLS checks. The agent runs only what the manifest declares and refuses anything else.
aethercert publishes 29 first-party packages. Your organization installs the ones it needs - pinned to an exact version until you update it - and can publish its own packages; MSPs can also test them on pilot customers. Community packages are available but disabled until an admin enables them.
How it works
- 01
Install
Browse the registry and install a package into your organization. Configure it once; reuse it for many certificates.
- 02
Version
Packages move through Draft, Test and Published. An installation stays on its exact version until you update it and review its permissions again.
- 03
Dispatch
At deploy time the control plane checks your registry policy, then sends the signed package to the agent.
- 04
Execute
The agent verifies the signature and the declared permissions, then runs the deployment steps.
Key capabilities
Signed packages
Every published version is signed and verified by the agent before it runs.
Declared permissions
Network destinations, secrets and key access are declared up front and enforced on the agent.
Trust levels and policy
aethercert, MSP and community publishers; an organization policy decides what may be installed and run.
Draft, Test, Published
A signed Test version can be installed in your own organization - and, for MSPs, in pilot customer workspaces - before it is published.
Visual builder and OpenAPI import
Build a package from operations and steps in the dashboard, or start from a device's OpenAPI description.
MCP authoring
Connect an AI assistant over MCP to draft packages. It can read and draft - never release or publish.
Compared with deployment scripts
| By hand | With aethercert |
|---|---|
| A script per appliance, copied between servers and edited in place. | One signed package, versioned and installed from the registry. |
| Nobody knows which script version runs where. | Each installation is pinned to an exact, signed version. |
| A script can do anything the service account can. | A package can only use the permissions it declares. |
First-party packages
The 29 packages aethercert publishes and maintains.
Microsoft and Windows Server
Citrix and VMware
Load balancers
Firewalls
Virtualization
Security considerations
AI can draft, people release
The MCP server issues OAuth-scoped access to read and draft packages only. Releasing and publishing stay with a person in the dashboard.
Policy checked on every dispatch
Your registry policy is enforced when a package is installed and again every time it runs.
Network guardrails
REST packages may only reach the hosts they declare, built from your configuration.
Example: rolling out a new package version
An updated NetScaler package version, tested before it reaches every agent.
draftThe new version is drafted in the builder or over MCP and validated against the schema.testReleased for testing as a signed Test version and installed against a lab NetScaler.publishAfter successful deployments it is published and signed.updateEach organization updates its installation explicitly, after reviewing the permission summary.
Frequently asked questions
Target Registry
Can I write a package for my own appliance?
Yes - as a JSON manifest, with the visual builder, starting from the device's OpenAPI description, or by drafting it with an AI assistant over MCP. The authoring reference in the documentation describes every field.
Can an AI assistant publish a package?
No. The MCP server only grants read and draft scopes. Moving a version to Test or Published is done by a person in the dashboard.
Are community packages trusted?
They are disabled by default. An admin decides in the organization's registry policy whether community packages may be installed and run.
Install your first package
Pick a first-party package for your system and attach it to a certificate.
Community plan, no card required. Open registration - your account is ready in a few minutes.