plugin sdk certificates

About plugin certificates

All plugin roles require an SDK certificate to connect to Security Center. The Plugin SDK automatically locates and validates the certificate using a specific file naming convention and folder structure.

Unlike Platform SDK applications where you can set the ApplicationId programmatically, plugins rely on file-based certificate discovery.

Certificate file naming

The certificate file must be named after the fully qualified class name of the plugin, followed by .cert:

{Namespace}.{ClassName}.cert

Example

Given the plugin class:

namespace Genetec.Dap.CodeSamples
{
    [PluginProperty(typeof(MyPluginDescriptor))]
    public class MyPlugin : Plugin
    {
        // Plugin implementation
    }
}

The certificate file must be named:

Genetec.Dap.CodeSamples.MyPlugin.cert

Certificate location

The certificate file must be placed in a Certificates folder located in the same directory as the plugin DLL:

YourPlugin.dll
└── Certificates/
    └── Genetec.Dap.CodeSamples.MyPlugin.cert

How the Plugin SDK locates certificates

When a plugin role initializes, the Plugin SDK:

1. Determines the plugin's fully qualified type name (Namespace.ClassName)
2. Looks for a file named {Namespace}.{ClassName}.cert
3. Searches in the Certificates subfolder relative to the plugin DLL location
4. Loads and validates the certificate
5. Uses the certificate to authenticate with Security Center

License consumption

Each active plugin role instance consumes one connection from the Security Center license:

• Plugin roles are not listed under System Status > Applications in Config Tool.
• Instead, view plugin roles under System Status > Roles.
• Each online and initialized plugin role represents an active SDK certificate connection.
• Even if multiple plugin roles use the same ApplicationId, each role instance counts as one connection.

License activation

A plugin role connection is counted when:

• The plugin role is activated and online

The connection is released when:

• The plugin role is deactivated or offline

Multiple plugin instances

If you have multiple plugin roles that share the same base plugin class, each instance requires:

1. Same certificate content (can copy the .cert file)
2. Same certificate filename (based on the class name)
3. Separate connections to the license pool

For example, if you create two instances of MyPlugin role:

• Both use Genetec.Dap.CodeSamples.MyPlugin.cert.
• Each instance consumes one separate connection.

ApplicationId property in PluginDescriptor

In addition to the certificate file, you can specify allowed ApplicationIds directly in your PluginDescriptor class using the ApplicationId property:

public class MyPluginDescriptor : PluginDescriptor
{
    public override Guid PluginGuid => new Guid("{12345678-1234-1234-1234-123456789012}");
    public override string Name => "My Plugin";
    public override string Description => "My plugin description";
    public override string SpecificDefaultConfig => null;

    public override List<string> ApplicationId => new List<string>
    {
        "KxsD11z743Hf5Gq9mv3+5ekxzemlCiUXkTFY5ba1NOGcLCmGstt2n0zYE9NsNimv"
    };
}

How it works

When the plugin initializes, Security Center extracts the ApplicationId from the .cert file and compares it against the entries in this list. If no match is found, the plugin fails with IllegitimateCertificate error.

If the ApplicationId list is empty (the default), this check is skipped for backward compatibility.

Note

For information about the development certificate ApplicationId, see Development vs production certificates.

Accessing the ApplicationId at runtime

The Plugin base class provides a protected property to access the certificate's ApplicationId:

protected override void OnPluginLoaded()
{
    // Get the ApplicationId from the certificate file
    string applicationId = SdkClientCertificate;
    Logger.TraceInformation($"Running with ApplicationId: {applicationId}");
}

See also

• Plugin SDK overview: Plugin architecture, lifecycle, and components.
• Deploying plugins: Plugin packaging, registration, and deployment.
• About SDK certificates: SDK certificate fundamentals shared across all SDK families.
• Workspace SDK certificates: Certificate requirements for workspace components.