Detent Point

SqlCertForge TLS certificate binding for SQL Server and Reporting Services

Invoke-SqlCertRenewalJob

Runs one renewal job — the entry point every scheduler calls. Renews only when the certificate is due (or -Force), and never takes a working server offline...

Domain: Scheduled renewal (SQL / SSRS / PBIRS) · Risk: Changes state (only when a renewal is due) · Runs on: Windows, PowerShell 5.1 or 7

This is the worker your scheduler triggers. Each time it runs, it checks whether the certificate is close to expiring. If it isn’t, it does nothing and exits — so running it daily is safe and cheap. When the certificate is due, it renews it, proves the new one works, and only then swaps it in. You rarely call this by hand; your scheduler does. But -Force gives you a “renew now” button when you need one.

Reads the spec, reads the live certificate’s expiry (via the free Test-* commands), and decides: NotDue → no-op (Success, idempotent); Unknown (a failed read) → Skipped, because a failed read is not a licence to act; DueNow (or -Force) → renew via the validated orchestrators, whose own Verify stage is the safety gate. Appends the outcome to the run log. Never throws.

Recipe 01 — What the scheduler runs (no arguments beyond the job)

Invoke-SqlCertRenewalJob -JobId sql01-engine

A no-op on most days; renews on the day the certificate enters the threshold window.

Recipe 02 — Renew right now, regardless of expiry

Invoke-SqlCertRenewalJob -JobId reports-pbirs -Force

Skips the due-date check and renews immediately — a manual “renew now”.

Recipe 03 — Preview what it would do (no change)

Invoke-SqlCertRenewalJob -JobId sql01-engine -WhatIf

Watchpoint — Unknown means skip, not fail. If the expiry can’t be read (a transient outage on the target), the run reports Skipped and changes nothing, leaving the next run to retry — deliberately, so a blind read never triggers a needless re-issue.

This is the part that actually does the renewal, and it’s smart about when. Most of the time it looks at the certificate, sees it’s not close to expiring, and stops — that’s why a daily schedule is fine. Only when the certificate is genuinely near its end does it renew.

And it’s careful: it builds the new certificate and checks it works before replacing the old one. If the new one fails, the old — still-working — certificate stays. Your server never goes dark because a renewal went wrong.

Question Answer
Outbound calls? None to the vendor. On a renewal, only your own CA (if used) and your servers.
What it changes Nothing on a no-op day; on a due day, it renews and re-binds a certificate.
Privileges Runs as the job’s scheduled identity (a gMSA is recommended).
Auditability Appends every run’s outcome to the job’s run log.
Dependency Why Required?
A registered renewal job (spec) Tells it what to renew. Yes
Read access to the target’s current cert To decide whether it’s due. Yes
The run-as identity’s renewal rights To act when due. On a due run
  • Acts only when a certificate is genuinely near expiry (or on an explicit -Force) — no unnecessary re-issues.
  • A failed expiry read yields Skipped, never a blind renewal.
  • The safe-swap invariant holds: the live certificate is replaced only after the new one verifies, so scheduled automation cannot cause a silent outage. Each run is logged for audit.