Skip to content

Set-DbaNetworkCertificate - Say why a private key is unsuitable - #10671

Open
andreasjordan wants to merge 2 commits into
developmentfrom
fix-setdbanetworkcertificate-key-reason
Open

Set-DbaNetworkCertificate - Say why a private key is unsuitable#10671
andreasjordan wants to merge 2 commits into
developmentfrom
fix-setdbanetworkcertificate-key-reason

Conversation

@andreasjordan

Copy link
Copy Markdown
Collaborator

Problem

A certificate whose private key lives in a Key Storage Provider - what New-SelfSignedCertificate creates by default - is refused by Set-DbaNetworkCertificate with Failed checks: PrivateKeyInvalid. That sends people looking at key permissions, which are not the problem.

Mechanism

SQL Server can only use a legacy CSP private key created with KeySpec AT_KEYEXCHANGE; CNG keys are not supported at all (Microsoft documentation). So the check was right - it just did not say why it failed. Test-DbaNetworkCertificate already knows the key type and key number, but the message did not use them.

What changed

The failed check now names the requirement and describes the key it found: the type plus KeyNumber when the key is accessible, otherwise "not accessible or a CNG (Key Storage Provider) key". The check itself is unchanged. The PrivateKeyValid description of Test-DbaNetworkCertificate says the same.

Tests

  • New test on InstanceRestart: a default New-SelfSignedCertificate on the target host is refused with the new message and nothing is configured; the certificate is tracked and removed again in AfterAll.
  • Lab: the command verified on PowerShell 7.6 and 5.1; Set-DbaNetworkCertificate.Tests.ps1 green through the testing-dbatools harness against a case sensitive SQL Server 2022 as InstanceRestart. The first harness run caught the test itself handing the command an Invoke-Command2 result without -Raw (an object with only a Length), fixed in the second commit.

created by Claude and reviewed by Andreas Jordan

🤖 Generated with Claude Code

andreasjordan and others added 2 commits August 31, 2026 16:57
A certificate whose private key lives in a Key Storage Provider - what New-SelfSignedCertificate creates by default - is refused with "Failed checks: PrivateKeyInvalid", which sends people looking at key permissions. The real reason is documented by Microsoft: SQL Server can only use a legacy CSP key created with KeySpec AT_KEYEXCHANGE, CNG keys are not supported at all. Test-DbaNetworkCertificate already knows the key type and key number, but the message did not use them.

The failed check now names the requirement and describes the key it found (type and KeyNumber when the key is accessible, otherwise "not accessible or a CNG (Key Storage Provider) key"). The check itself is unchanged - it was right. The PrivateKeyValid description of Test-DbaNetworkCertificate says the same.

Verified in the lab on PowerShell 7.6 and 5.1 with a default New-SelfSignedCertificate on the target host: the command refuses with the new message and configures nothing. The new test does the same against InstanceRestart and asserts the message.

(do *NetworkCertificate*)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…criptblock in the test

Invoke-Command2 wraps plain output in a PSCustomObject unless -Raw is used, so the CNG test
handed the command an object with a Length property instead of the thumbprint and failed on
the thumbprint format check.

(do *NetworkCertificate*)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant