SqlCertForge TLS certificate binding for SQL Server and Reporting Services

Copy-SqlCertificate

Migrates a master certificate — a TDE or backup-encryption certificate, with its private key — from a source SQL instance to a target, by escrowing on the...

Domain: Certificate migration · Risk: Changes state · Runs on: Windows, PowerShell 5.1 or 7

A DR replica or a new server can’t read another server’s TDE-encrypted data or encrypted backups until it holds the same certificate. This command moves that certificate — with its private key — from the source to the target.

It’s safe to re-run: if the target already has the certificate, it does nothing and reports Skipped. You can preview the whole move with -WhatIf before it touches anything, and the transfer password is never written to a log or into the result.

Orchestrates the module’s escrow and restore commands rather than re-implementing them: Backup-SqlTdeCertificate on the source, Restore-SqlTdeCertificate on the target, then a presence check on the target. The two escrow files travel over a transfer path you supply that both servers can reach (e.g. a UNC share). Idempotent — already on the target returns Skipped. A single -WhatIf gate covers the whole migration, so a preview performs no backup or restore. A failed escrow stops before any restore; a failed restore is surfaced as “escrowed but not restored,” never a silent half-migration. -Password is a SecureString, handed to the escrow/restore calls and never logged or placed in Data. Never throws.

Recipe 01 — Migrate a TDE certificate to a DR server

$pw = Read-Host -AsSecureString 'Transfer password'
Copy-SqlCertificate -Name 'TDE_Cert_2026' -SourceInstance sql01 -TargetInstance dr-sql `
    -CertificatePath '\\share\move\tde.cer' -PrivateKeyPath '\\share\move\tde.pvk' -Password $pw

After this, a TDE-encrypted backup from sql01 can be restored on dr-sql.

Recipe 02 — Preview without moving anything

Copy-SqlCertificate -Name 'TDE_Cert_2026' -SourceInstance sql01 -TargetInstance dr-sql `
    -CertificatePath '\\share\move\tde.cer' -PrivateKeyPath '\\share\move\tde.pvk' -Password $pw -WhatIf

Confirms the migration would run — no backup, no restore.

Recipe 03 — Grant the target’s service account read on the transfer files

Copy-SqlCertificate -Name 'TDE_Cert_2026' -SourceInstance sql01 -TargetInstance dr-sql `
    -CertificatePath '\\share\move\tde.cer' -PrivateKeyPath '\\share\move\tde.pvk' -Password $pw `
    -TargetServiceAccount 'DOMAIN\sqlsvc'

SQL Server writes the exported private-key file with a restrictive ACL — owner, local Administrators, and only the source instance’s service account. -TargetServiceAccount grants the target instance’s SQL service account Read on the escrowed files after the escrow and before the restore, so the restore can read them. Omit it when the transfer path’s own ACL already lets both service accounts read.

Watchpoint — the private-key file’s ACL. Without -TargetServiceAccount (and without a transfer path both service accounts can already read), the restore fails with “the private key file is not valid or does not exist; or you do not have permissions for it” — because SQL restricts the exported key file to the source service account. Supply the target instance’s SQL service account, or stage the files on a path whose ACL already covers both.

TDE and backup encryption protect data with a certificate that lives in the master database. To read that data — or restore those backups — on another server, that server needs the same certificate and its private key.

This command backs the certificate up on the source into two files, moves those files over a path you supply, restores the certificate on the target, and then confirms it’s really there. The private key is protected the whole way by the password you provide.

Question Answer
Outbound calls? Connects to the source and target SQL instances (the module’s SqlServer / dbatools provider); reads and writes the two transfer files on the path you supply; runs icacls on those files when -TargetServiceAccount is set. No other calls.
What it changes Creates the certificate on the target from the escrowed files; writes the two transfer files on the transfer path; optionally grants the target service account Read on those files.
Privileges Rights to back up and restore certificates on both instances; write access to the transfer path; when granting the ACL, rights to change it on the file’s host.
Reversibility The source is untouched. To reverse, drop the restored certificate on the target. The escrow files remain on the transfer path and contain the private key (protected by your password) — remove them per policy.
Dependency Why Required?
Windows + PowerShell 5.1 or 7 Runs the orchestration. Yes
Backup-SqlTdeCertificate / Restore-SqlTdeCertificate It orchestrates these; it does not re-implement them. Yes
A transfer path both servers can reach (e.g. a UNC share) The two escrow files travel over it. Yes
A database master key on the target Restore-SqlTdeCertificate needs one; a target that lacks it is surfaced as that result. Yes (target)
A SQL or Windows credential Only where Kerberos pass-through doesn’t apply (one credential for both servers, v1). No
  • One -WhatIf gate covers the whole migration — no backup or restore runs in a preview.
  • The password is a SecureString, never logged and never placed in the result Data.
  • A partial failure is surfaced explicitly (escrowed but not restored), never left as a silent half-migration.
  • Idempotent: a certificate already on the target returns Skipped, so a re-run doesn’t repeat the move.