Detent Point

SqlCertForge TLS certificate binding for SQL Server and Reporting Services

Test-SqlCertClientTrust

Reports whether a client machine trusts a SQL Server (or Reporting Services) TLS issuer certificate — whether the issuer/root certificate you supply is pre...

Domain: Client trust · Risk: Read-only · Runs on: Windows, PowerShell 5.1 or 7

A client will only accept an encrypted connection to SQL Server if it trusts the certificate’s issuer. This command checks that, one machine at a time: you give it the issuer or root certificate, and it reports whether that machine already trusts it. It reads and changes nothing.

Use it before rolling out encryption to find the clients that would reject the connection, so you can fix trust on those machines first.

Loads the issuer/root certificate file you supply (.cer) and reports whether its thumbprint is present in the target machine’s LocalMachine\Root store — locally, or on a remote machine via -ComputerName. Reports the thumbprint, subject, expiry (NotAfter), and Trusted true/false. Read-only (no -WhatIf); never throws; returns a SqlCert.Result. To distribute the trust it checks for, use Add-SqlCertClientTrust.

Recipe 01 — Check whether one client trusts a CA

Test-SqlCertClientTrust -CertificatePath \\fileshare\ca\CorpRootCA.cer -ComputerName app07

Reports whether app07 would accept an encrypted connection to a SQL server whose certificate that CA issued.

Recipe 02 — Filter a list of clients to those that do not yet trust the CA

$clients | Where-Object { -not (Test-SqlCertClientTrust -CertificatePath .\CorpRootCA.cer -ComputerName $_).Data.Trusted }

The machines returned are the ones that need Add-SqlCertClientTrust.

Watchpoint — it checks LocalMachineonly. Trust is reported from the machine-level trusted-root store, not a per-user store. A remote check reads the target named by -ComputerName, so run it against each client whose connection you need to confirm.

TLS trust works by chains: a server’s certificate is signed by an issuer, and a client accepts the server only if it trusts that issuer. On Windows, machine-wide trusted issuers live in the LocalMachine\Root store. This command asks a simple question of one machine — is this issuer certificate in that store?

It takes the issuer or root certificate as a file, reads it for its thumbprint, then looks for that thumbprint in the target’s trusted-root store and reports true or false. It never installs anything; distributing trust is a separate command, Add-SqlCertClientTrust.

Question Answer
Outbound calls? Reads the certificate store of the target machine — the local machine, or a remote one via -ComputerName (WinRM). Also reads the .cer file at the path you give (which may be a file share). No other outbound calls.
What it changes Nothing — read-only.
Privileges Read access to LocalMachine\Root on the target; WinRM for a remote -ComputerName.
Licence Free. Read-only audit commands need no licence.
Dependency Why Required?
Windows + PowerShell 5.1 or 7 Loads the certificate and reads the trust store. Yes
The issuer/root certificate file (.cer) It is the certificate whose presence is checked. Yes
WinRM to the target Only for a remote -ComputerName read. No (local)
  • Read-only — it reports trust without distributing or changing it.
  • Reports the issuer’s thumbprint, subject, and expiry alongside the trust result, so the record identifies exactly which certificate was checked.
  • Reads the machine-level LocalMachine\Root store, the store SQL Server TLS trust actually depends on.
  • Returns a structured result (Thumbprint, Subject, NotAfter, Trusted, ComputerName, CertificatePath) — per-machine evidence for an audit sweep.