Certificate deployment to servers and appliances

Issuing a certificate is the easy half. The work is getting it onto the load balancer, the firewall, the federation server and the four IIS sites that actually serve it, and doing that again at every renewal. Skyrsoft CertOps defines a deployment target for each of those places, pushes the certificate to it automatically after issuance and renewal, then verifies on the wire what the target is really serving. Nineteen built-in target types ship today, plus three generic ones (PowerShell, SSH script and webhook) for anything they don’t cover.

How it works

A target records where to go, how to get in, and what to do on arrival. Renewal compares thumbprints, so a target is only deployed to when the certificate it points at has actually changed. Each type reaches its host over the transport the vendor gives it, and the third column is the one to read before you configure anything: several types cannot pick up a certificate without restarting a production service.

Generic targets

Reusable credentials

Rather than storing a username and password on every target, create a credential once and reference it from as many targets as you like. Credentials are typed — Windows/WinRM, SSH by key or password, API token, or TLS client certificate — and their secrets are encrypted at rest. At deploy time the credential’s values are merged over the target’s config, so a secret is rotated in one place. A target left on “inline” keeps its own fields.

Reading configuration off the target

Most target types can be asked what is actually on the host before you deploy, instead of having you type a value that only fails later. Every one of these reads is read-only, and each uses the same channel and credential the deployment itself will use, so a successful read also proves the connection works. There are two shapes. Some targets offer a selection pulled off the appliance — IIS site bindings, Kemp Virtual Services, FortiGate certificate consumers, FortiADC certificate groups, Ivanti interfaces, Splunk’s per-surface certificate paths — and you tick what should rotate. Others simply report state: SQL Server’s instances with each one’s service account and current thumbprint, AD FS’s federation service name and every http.sys SSL binding on the host, the RDS roles installed and what certificate each holds today.

The AD FS read is worth doing even when you know the answer. It is host-wide rather than AD FS only, and it shows :49443 — device registration — which a deployment that rebinds :443 alone would leave sitting on the expiring certificate.

Deployment windows

Renewals are unattended, so by default a restart lands whenever the CA happens to issue. Give a target a deployment window and the automatic post-renewal deployment waits for it. The window is dynamic rather than calendar-fixed: it is measured from the moment the certificate renewed, so a certificate renewed at 09:00 on Monday goes that same evening against a Monday 22:00 window, while one renewed on Tuesday morning waits a week. Each target carries its own timezone, defaulting to the server’s, and daylight-saving transitions are handled — a window falling in the skipped hour each spring runs at the first valid time instead of being missed.

A window only ever delays a deployment. Nothing is deployed because a window opened; a failed deployment stays due and is retried in the next one. If a window is missed entirely — CertOps was down, or the target was created mid-week — the deployment still runs when it comes back, but only within a catch-up allowance that defaults to six hours. Clicking Deploy by hand ignores the window, because that is an explicit decision to accept the impact now.

Deploy and verify answer different questions

Deploy reports what the write did. Verify answers what the target is actually serving, and it is the number to trust. Where a target has a reachable endpoint, Verify probes it on the wire and compares the certificate being served; where it does not, it reads the certificate back from the target’s own configuration. Verify checks what the target is currently pointed at, not what was last deployed to it, so a re-pointed target reports failed and flags a deployment as pending. The alternative would be a green row on an appliance months out of date.

Limits

Only certificates whose private key CertOps holds can be pushed. That means ACME and public certificates, and Private Certs, both of which carry an encrypted PFX on the server. A certificate issued to an agent, or over EST, SCEP or a portal CSR, was generated by a keypair that never left the requesting host, so there is no key here to deploy and those certificates are renewed in place by the agent instead. The restriction is enforced both at the point you save a target and again before any executor runs.

Every Windows target type needs WinRM reachability, and effectively needs HTTPS on 5986. IIS, the Windows certificate store, PowerShell, AD FS, the Web Application Proxy, all four Remote Desktop types and SQL Server go over WinRM, and the account has to be a local administrator on the target host. Port 5985 cannot work against a default Windows configuration: WinRM’s AllowUnencrypted=false rejects the request with a bare 401 and no explanatory fault, which is easy to misread as a credential problem. Choosing HTTP rather than HTTPS on a target also adds that host to this server’s WinRM TrustedHosts list automatically, because a Windows WinRM client refuses to send credentials over plain HTTP to a host it does not already trust.

The Linux and SSH-script types, and Splunk on Linux, need SSH reachability (Splunk on Windows uses WinRM, like the other Windows types), and the Fortinet, FortiGate, FortiADC, Kemp, Sophos, Ivanti and Autologon Manager types need their management API reachable from this server. A management port firewalled off from CertOps produces a check that is reported as skipped rather than counted as a success.

Several target types restart a production service. AD FS restarts adfssrv; the Web Application Proxy restarts appproxysvc; RD Gateway restarts TSGateway; SQL Server restarts the instance and everything depending on it; Splunk stops indexing and searching until it returns. Ivanti restarts its own web service on any device-certificate change, and the Windows certificate store type restarts a service only when you name one. The target form says so in red before you configure it, and a deployment window is the control.

A window can delay a renewal reaching its target. The certificate renews on its own schedule and the window governs only the deployment, so with a weekly window a target can serve the previous certificate for up to a week after renewal. That is comfortable given ACME renews around thirty days out, but do not set a window so infrequent that it cannot fire before the old certificate expires. Targets waiting on one are marked windowed in the list, with the next window in the tooltip.

SSH script and Webhook targets cannot be verified. An arbitrary script or receiver has no endpoint whose certificate can be inspected, so those report “not supported — check manually” instead of passing. Sophos Firewall is deliberately excluded from discovery: its certificate listing operation returns an archive containing private keys in cleartext, and CertOps never calls it.