A Private Cert is a certificate from Skyrsoft CertOps’s internal CA hierarchy where CertOps itself generates the key pair and the CSR, rather than the requester. That distinction is the one that matters: an agent, EST, SCEP or portal-CSR enrolment generates its own key on the requesting host, and that key never reaches the server, so there is nothing CertOps could push anywhere later. A Private Cert’s key is generated here and kept, encrypted, alongside the issued certificate — the same custody model an ACME/public certificate already has — and that custody is what makes it a valid source for a deployment target.
How it works
Creating a Private Cert generates the key and CSR on the server, then submits the request through the same pipeline every other enrolment origin uses: CA resolution, licence caps, Active Directory request validation where the template requires it, and the approval-rules engine. There is no separate or relaxed approval path for a Private Cert.
A template matched by an auto-approve rule issues the certificate immediately. A template that requires approval, or that no rule matches, queues the request in Manual Approvals exactly like any other pending enrolment, for an admin to approve or reject from there.
Auto-renewal and repointing
With auto-renew enabled, a background worker regenerates the key and CSR as the certificate approaches its template’s renewal window, and resubmits it through the same approval pipeline as the original request. Internal certificates are immutable per-issuance records rather than renewed in place, so a successful renewal produces a genuinely new certificate. Any deployment target that referenced the previous one is repointed at the new one automatically, so it does not go on serving a certificate that is about to expire.
Renewal is only truly unattended when the template auto-approves. A template that requires a human click still requires one on every renewal, not only on the first issuance — the repoint happens once that approval lands, and is tracked against the renewal request rather than the original one.
Deploying it
Once issued, a Private Cert appears in the certificate picker on a deployment target’s configuration form, alongside Public/ACME certificates — choose Private Cert as the source instead. Only certificates that have actually been issued are offered there; one still pending approval, or rejected, has no key to push yet, so it does not appear.
Limits
Deleting a Private Cert removes only the tracking entry. The underlying certificate is never hard-deleted — CertOps only ever revokes — so its issuance history stays intact. Deletion is refused while a deployment target still references the certificate; repoint or delete that target first.
A Private Cert goes through the same request validation and approval rules as every other enrolment origin, with no exception. If a template requires manual approval, a Private Cert issued from it requires manual approval too, and it does so on every renewal. A deployment that genuinely needs to run unattended needs a template whose approval rule matches it automatically.
Renewal does not revoke the certificate it replaces. Repointing moves deployment targets onto the new certificate, but the superseded one is left exactly as issued — valid and unrevoked — until it expires on its own schedule. Where a certificate needs to stop being trusted immediately, such as after a suspected key compromise, revoke it explicitly rather than relying on the next renewal to retire it.