Connect-DbaInstance does not support HostNameInCertificate

[ArnoldLieberman-CoT]

Summarize Functionality

The standard for connecting to servers in my company is to use mandatory encryption with our own wildcard certificate rather than trust the server certificate. Connect-DbaInstance does not support this mode of connection, so we have to use the trusting mode.
Would it be possible to add the new encryption flags - Optional, mandatory and Strict, along with the ability to use wildcard certificates?

Is there a command that is similiar or close to what you are looking for?

Yes

Technical Details

No response

[andreasjordan]

@claude please look at this feature request. Do we need any additional information? What changes would be needed to the command Connect-dbaInstance? Are there any downsides or risks?

[claude]

Claude finished @andreasjordan's task in 1m 42s —— View job

---

Analysis of Feature Request: HostNameInCertificate for Connect-DbaInstance

Tasks

• Read issue and understand the request
• Read Connect-DbaInstance source code
• Research current encryption parameter support
• Analyze SMO API for HostNameInCertificate
• Formulate response on required changes and risks

---

Do we need additional information?

A few clarifications from the reporter would help scope the work:

1. SQL Server version — Strict encryption (TDS 8.0) only works with SQL Server 2022+. Knowing the target version helps decide which encryption modes to prioritize.
2. Exact scenario — Is the wildcard cert issue a hostname mismatch (e.g., server cert is *.mycompany.com but connecting to sqlserver01.mycompany.com)? That clarifies whether HostNameInCertificate alone is sufficient or if encryption mode changes are also needed.
3. Current workaround — The reporter might not be aware that -AppendConnectionString "HostNameInCertificate=*.mycompany.com;" already works today as a workaround via the existing AppendConnectionString parameter. Worth confirming if that meets their immediate need.

---

What changes would be needed?

Reading the source at public/Connect-DbaInstance.ps1, the connection path for a new string connection goes through Microsoft.SqlServer.Management.Common.SqlConnectionInfo, which gets built up and passed as a ServerConnection to the SMO Server object.

Change 1: Add -HostNameInCertificate parameter (straightforward)

SqlConnectionInfo does not expose HostNameInCertificate directly, but the code already uses AdditionalParameters for unsupported properties (lines 820–834 handle MultiSubnetFailover, FailoverPartner, AlwaysEncrypted this way). A new parameter would follow the same pattern:

[string]$HostNameInCertificate

And in the process block (after the AlwaysEncrypted block around line 831):

if ($HostNameInCertificate) {
    $sqlConnectionInfo.AdditionalParameters += "HostNameInCertificate=$HostNameInCertificate;"
}

It would also need to be added to:

• The ignoredParameters list (line 623) so a warning fires when it's passed to a reused Server object
• The .PARAMETER help section and .OUTPUTS docs

Change 2: Improve encryption mode support (more complex)

Currently, EncryptConnection is a [switch] that maps to a boolean SqlConnectionInfo.EncryptConnection. The modern Microsoft.Data.SqlClient connection string supports three string values: Optional, Mandatory (= old True), and Strict (TDS 8.0, SQL 2022+ only).

The cleanest approach that preserves backward compatibility would be a new -Encrypt string parameter with a ValidateSet:

[ValidateSet('Optional', 'Mandatory', 'Strict')]
[string]$Encrypt

The existing -EncryptConnection switch would remain for compatibility, and -Encrypt would take precedence if specified. Internally, Optional maps to Encrypt=Optional, Mandatory to Encrypt=True (existing behavior), and Strict to Encrypt=Strict passed via AdditionalParameters (since SqlConnectionInfo.EncryptConnection is a bool and can't express Strict).

Change 3: AccessToken / SqlConnection path

When AccessToken is used (lines 971–1013), the code builds a SqlConnection directly from a connection string. HostNameInCertificate and Strict encryption would need to be injected there too, since SqlConnectionStringBuilder does support HostNameInCertificate and Encrypt as a string value.

---

Downsides and risks

Risk	Detail
Strict encryption requires SQL 2022+	Connecting with Encrypt=Strict to older SQL Server versions will fail at the driver level, not gracefully. The code would benefit from a version check or at least a clear error message.
Driver version dependency	Strict mode and HostNameInCertificate require Microsoft.Data.SqlClient 4.0+. dbatools bundles its own copy of this library; the version shipped needs to support these features.
SqlConnectionInfo does not expose HostNameInCertificate	The property must go through AdditionalParameters (a raw string appended to the connection string). This is already the established pattern for several other params, so not a blocker — but it means no type safety or intellisense for the value.
Backward compatibility for EncryptConnection	Changing EncryptConnection from a switch to an enum/string would be a breaking change. Adding a new -Encrypt parameter alongside the existing switch avoids this but creates two ways to express the same thing.
Connection string path inconsistency	The RegisteredServer / ConnectionString input paths (lines 725–774) handle TrustServerCertificate specially. Any new encryption parameters would need the same treatment. The SqlConnection (AccessToken) path at lines 1008–1011 also needs updating.
HostNameInCertificate + no encryption	The parameter is only meaningful when encryption is active. Setting it without encryption silently does nothing, which could confuse users. Adding a Write-Message -Level Warning when HostNameInCertificate is set but EncryptConnection/Encrypt is not would help.

---

Summary

The most impactful and lowest-risk change is adding -HostNameInCertificate — it directly solves the wildcard cert use case, follows an established pattern in the codebase, and carries minimal risk. The encryption mode changes (Optional/Mandatory/Strict) are more involved due to the boolean nature of SqlConnectionInfo.EncryptConnection and the need to keep backward compatibility with the existing -EncryptConnection switch.

In the meantime, the reporter can use the existing workaround:

Connect-DbaInstance -SqlInstance sql01 -EncryptConnection -AppendConnectionString "HostNameInCertificate=*.mycompany.com;"

[andreasjordan]

@ArnoldLieberman-CoT does the answer from claude helps you? What part of the proposed changes do you need to solve your issue?

[ArnoldLieberman-CoT]

@andreasjordan AppendConnectionString looks like an excellent workaround - don't know why I didn't think of it before, as we're already using it for MultiSubnetFailover.
-HostNameInCertificate would be number 1, as our servers will not accept unencrypted connections anyway.

[andreasjordan]

Thanks for the feedback. As we try not to add too many parameters to the command, let's try and see if using AppendConnectionString is a good solution for you.