A device is a machine running the Skyrsoft CertOps agent — a service that registers the machine, requests certificates on its behalf under an assigned device group, and renews them automatically ahead of expiry. The agent authenticates to the server with its own mTLS identity certificate, which CertOps issues and rotates without an administrator ever handling it directly. Every device belongs to exactly one device group, and the group’s assignment rules decide which certificate templates that device is entitled to.
How it works
Onboarding is the same four steps whichever way the agent gets installed: it presents an enrolment token to the bootstrap port and receives its mTLS identity and the CA trust bundle, then checks in periodically — reporting status and picking up config (intervals, thresholds, subject and SAN templates) along with any pending command — and finally requests and renews certificates according to its group’s assignment rules. There are three ways to get an agent onto a machine, all from Settings → Downloads:
| Method | What it’s for |
|---|---|
| Personalised installer | A ZIP with the installer plus a ready-made config; nothing to type. Its own enrolment token expires, is capped to a number of installs, and can be revoked independently of every other pending install. |
| Generic installer + config XML | The installer downloaded once, with the config file managed separately — useful where the config needs to be versioned or edited on its own. |
Generic installer + msiexec properties |
APIBASEURL, SITEID and ENROLMENTTOKEN passed on the command line, for Intune, SCCM or Group Policy, which want one immutable, versioned package. A token passed this way lands in verbose install logs, so prefer a config file where the deployment tooling allows it. |
Device groups
A group’s membership rules — edited and saved together on the group’s own form — decide which devices join it, and its template assignment rules decide what those devices enrol for. Putting machines with the same certificate needs into one group keeps the template decision out of any individual device’s configuration. A device group can also deliver a Wi-Fi profile to its Macs, which a local administrator approves on each Mac; see Certificate-based Wi-Fi for Macs.
WinRM over HTTPS
A device group can switch on Enable WinRM HTTPS, which is off by default. On every Windows agent in the group, the agent then configures the WinRM HTTPS listener on port 5986 to use the machine certificate it enrolled, enables the inbound firewall rule for it, and re-binds the listener to the new certificate each time that certificate renews. Remote PowerShell over HTTPS keeps working through renewals without anyone re-binding the listener by hand. On Windows client editions, where WinRM isn’t running by default, the agent starts it first and leaves only the HTTPS listener in place. The certificate needs the Server Authentication EKU, which WinRM requires for an HTTPS listener; the agent reports it if the certificate doesn’t have one.
Remote agent rollout
Push Install, under the Devices navigation group, installs the agent itself onto a machine that does not have one yet — a different job from deploying a certificate to a target that is already agented. Targets can be picked by browsing an Active Directory OU tree, by typing hostnames directly, or a mix of both in the same job, so a machine outside AD or unreachable over LDAP can still be included by name. The transport is SMB copy plus WMI process creation rather than WinRM, deliberately: an expired WinRM listener certificate on a drifted fleet would otherwise block the very install that could go on to fix it. A job runs in the background against a few hosts at a time, so a large host list neither blocks the request that created it nor ties up a browser tab, and it is restricted to administrators — the installer runs across whatever estate is targeted, which is the widest blast radius of any action in the console.
Automatic cleanup
Under Settings → Agent Settings → Device Cleanup, a device that has been offline for a configurable number of days — 30 by default — can be deleted automatically, with every certificate it held revoked at the same time. This keeps the active device count, and the licence seats it consumes, from accumulating decommissioned hardware that nobody removed by hand. It is off by default, and a device that has never checked in at all is only removed once it is older than the threshold, not immediately.
Limits
DeviceHeartbeatExpired is a separate, always-on rule, and it cannot be turned off, lengthened or softened. Independently of whatever Device Cleanup is configured to do, any device that has not sent a heartbeat in a fixed 30 days has every active certificate it holds revoked outright — not suspended, not merely alerted on. The window matches the length of the licensing grace period deliberately, and neither an administrator through the console nor a direct database edit can change it: the engine ignores the stored rule’s enabled flag, its configured window and its configured action for this one rule type. Treat 30 days offline as the real ceiling on how long a device can be out of contact before its certificates stop being usable, regardless of any other setting on the Devices or Agent Settings pages.
Revocation here only ever covers what CertOps itself can see. A certificate already deployed onto some other system that never checks CRL or OCSP status keeps working after CertOps revokes it. Publishing a revocation is as far as any X.509 authority reaches; whether a relying party acts on it is that system’s own configuration.
A Free licence caps the install at 10 devices. Pro removes the device count as a licensed dimension entirely; see the pricing page for what each edition includes.