Target Registry
Community, MSP and aethercert-published deploy target templates you install rather than configure by hand - trust levels, org policy, and what publishing one means.
The 31 built-in deploy targets cover the presets aethercert ships and reviews itself. The Target Registry is a separate, growing catalogue of deploy target templates - published by aethercert, by MSPs, by confirmed publishers, or by any registered community member - that your organization can install the same way you'd install a package from a language's own package registry.
Installing one adds a new preset to your certificate/policy target picker, pinned to an exact, signed version. A package describes which operations to run - REST calls, file writes, TLS checks, service reloads and its own PowerShell scripts - and with what configuration. Whether a package may be installed and run is your organization's policy; community packages are off until an admin enables them. See Trust levels and PowerShell scripts in packages.
This is not the same thing as a custom script
A custom script target runs a script you wrote and placed on the agent host yourself. A registry package is a signed, declarative description of the operations to run - REST calls, file writes, a TLS check, a service reload, PowerShell - in a fixed order, with the exact permissions they need. Reach for a custom script when nothing in the registry covers your case; reach for the registry when someone else already solved it.
Browsing and installing a package
Nothing is installed for you, including aethercert's own packages for IIS, Exchange, NGINX and the other built-in targets. Your organization installs each package it wants to use, and installing it is how you allow that package to run on your agents.
Go to Store > Target Registry > Browse registry to open the Target Store. Search by name, and filter by category, trust level and whether your organization already has the package installed. Sort by popularity, name or newest. Each package shows how many organizations have it installed. Opening a package shows its compatibility (vendor, product, supported version range), the exact permissions it needs (which certificate material it reads, which hosts it may reach, which local service it may restart, whether it runs PowerShell), what each operation does - including which key material it receives and the full source of any script - and its deployment flow: the steps in order, plus a rollback, if the package defines one.
Installing pins your organization to that exact version - the same "signed, immutable release" guarantee an agent binary itself gets. A newer version publishing later never changes what's already installed; update explicitly from Store > Target Registry when you're ready, and review the same permission summary again before you do - a version bump can add a permission the previous one didn't need.
Trust levels
Every package carries one of four trust levels, shown as a badge wherever it appears:
| Trust level | What it means |
|---|---|
| Verified by aethercert | aethercert has technically reviewed and tested this specific package version - the highest tier, shown with a blue checkmark. |
| Verified Publisher | The publisher's organizational identity has been confirmed (e.g. Fortinet, Citrix) - shown with its own outline checkmark. This says nothing about whether aethercert reviewed the package itself, only who published it. |
| Verified by MSP | A private endorsement your own managing MSP granted for its customers, shown with a gray checkmark naming that MSP. Only ever visible to you - never a registry-wide signal, and unrelated to whether aethercert or anyone else has reviewed it. |
| Community | Published by any registered user, with automated validation only - no functional guarantee from aethercert. Shown with no checkmark. |
These four badges are deliberately distinct from each other - by icon, color and label, not color alone - because they are different promises. Confusing "aethercert tested this" with "we confirmed who published this" would be exactly the wrong thing for a security product to let happen by accident.
A trust level never implies you should skip the permission review
Even a Verified by aethercert package only received a technical review of that package version. It still declares exactly which certificate material it reads and which hosts it reaches, and that summary is still worth reading before you install - the review confirms the package does what it says, not that what it says is right for your environment.
Why a community package can still be safe to run
A package's operations run through a small, fixed set of mechanisms the agent itself implements and aethercert reviews with every agent release: a REST call, a file write, a TLS check, reloading or restarting one named service, and a PowerShell script. Community packages are off by default because their scripts are reviewed by nobody but their publisher - read the script source before you enable and install one.
The agent enforces the rest at runtime, whatever the trust level:
- Least privilege. A package declares exactly the hosts it may reach, the paths it may write, the service it may restart and the key material it reads - and publishing refuses a package that asks for more than its operations need.
- Key material per operation. Each operation receives only the material it declares. An operation that only restarts a service never sees the private key.
- Secrets stay yours. Passwords and tokens you enter are stored encrypted and are only referenced by the package, never part of it, and they are redacted from every error.
PowerShell scripts in packages
Windows targets - IIS, Exchange, the certificate store, AD FS, RDP and the others - work through PowerShell scripts that are part of their package. Any publisher can write them, community publishers included. Such a script:
- is part of the signed package, and its full source is shown on the package page and before you install;
- receives values only through parameters it declares, checked by the agent before it starts - nothing is ever pasted into the script's source;
- runs wherever your organization's policy allows the package, unless the host's own agent configuration blocks package scripts entirely.
Organization policy
Manage > Settings > Target Registry policy (admin or owner role) controls which trust levels this organization's admins may install at all, independently of what an individual admin decides package by package:
- Allow community-trust targets
- Allow Verified Publisher targets
- Allow targets verified by your own MSP
- Allow Verified by aethercert targets
- Require approval before an install takes effect (a second admin must approve a pending install/update before it becomes active)
- Allowed publishers (one per line; a trailing
/*allows every package from that publisher, e.g.fortinet/*; empty allows every publisher, subject to the trust levels above)
An organization that only wants aethercert's own reviewed packages can disable every other trust level. An MSP managing many customer environments might allow only its own Verified by MSP endorsements plus Verified by aethercert.
Community targets are off by default. Community packages are still listed in the Target Store like every other package, so you can find and review them; the Target Registry shows a note with an Enable community targets button for admins. Turn them off again with "Allow community-trust targets" on the policy page.
The policy covers everything a package does, including its PowerShell scripts. It is checked when a package is installed and again before every deployment, so tightening it - turning community targets off, say - stops affected packages on their next deployment. Organizations that already used a community package before this default changed keep community targets enabled.
Rollback
A package can define a rollback - for example "bind the previous certificate again" after
an IIS deployment whose verification failed. A rollback runs only when a deployment fails
after at least one step succeeded, and it is best effort: it tries to restore the
previous state but guarantees nothing, and the deployment's original error always stays
the job's result. The event log shows the rollback outcome next to that error
(rollback: succeeded, partial or failed). Packages for targets without a reliable
previous state - NetScaler, Exchange - deliberately have none.
Publishing a package
Build a package under Store > Target Registry > New Registry Target. The editor walks you through identity, connection and login, parameters and operations, and the deployment flow (with an optional rollback). The permissions are not something you fill in: the editor derives exactly what your operations need, because publishing refuses a package that asks for less or for more. It publishes under your organization's own publisher. Every organization has exactly one, created the first time you open the editor. The authoring reference explains conditions, state, PowerShell and rollback in detail.
A package goes through three states:
| State | Who can see and install it | Can it change? |
|---|---|---|
| Draft | Your organization only. It cannot be installed. | Yes. Save draft keeps your work, one draft per package. |
| Test | Your organization, plus the pilot customers you pick if you are an MSP. | No. It is signed, like any version. |
| Published | Everyone the package is visible to: every organization, or only yours for a private package. | No. |
- Save draft while you work. Drafts are listed under In progress on the Target Registry page, where you can continue or discard them.
- Release for testing creates a signed test version. Install it in your own organization, and on pilot customers if you picked any, and try it on a real target. A test version never appears in the Target Store and never becomes the latest version. If something is wrong, change it and release a new test version, for example 1.0.1.
- Publish it from In progress or from the package's Versions tab. The same version, with the same number, content and signature, becomes available to everyone. What was tested is exactly what gets published. A published version cannot go back to test. Pilot customers keep access to the versions they piloted.
Each version is immutable once released for testing. A mistake needs a new, higher version, never an edit.
Getting Verified Publisher status (organizational identity confirmed) or Verified by aethercert status (a specific version technically reviewed) for a package you publish means contacting support.
A publisher can be banned
Publishing malicious, insecure, or otherwise policy-violating content can get a specific version removed or a publisher banned outright - every existing version from a banned publisher is withdrawn from the catalogue at the same time. See the Terms of Service for the specific grounds and process.