Comments
4 comments
-
This was caused by a change in the behavior of Microsoft.Data.SqlClient which now enforces certificate checks, currently we are trusting the certificate on the connection string if we detect that the connection target in the LAN. If that's not the case, you can work around this by using Powershell directly (rather than an addon and adding TrustServerCertificate=True to the connection string).
I am checking if there's a way to also add this on the addons and will post my findings here. -
I have created an enhancement request to add the option to Trust Server Certificate to the Azure DevOps addon (ref # SCA-2745).
Please keep an eye on the release notes at https://documentation.red-gate.com/sca/release-notes-and-other-versions/add-on-release-notes to check whether this has been implemented or not.
-
Sergio,
I am trying to follow your advice and implement PowerShell components instead of addons in Build and Release. And having the same issue - cannot find the way to provide parameter TrustServerCertificate=True to the New-DatabaseConnection cmdlet. Is it any way to do it using PowerShell?
Thank you,
Nikolai
-
nfp1 said:
Sergio,
I am trying to follow your advice and implement PowerShell components instead of addons in Build and Release. And having the same issue - cannot find the way to provide parameter TrustServerCertificate=True to the New-DatabaseConnection cmdlet. Is it any way to do it using PowerShell?
Thank you,
Nikolai
Answering myself. Found an option to use cmdlet Test_DatabaseConnection instead which can consume explicit connection string.
Add comment
Please sign in to leave a comment.
I am using Redgate addins in TFS for build and release. Lately security settings in target SQL server are changed and default Windows authentication started to fail. I need to modify some Connection string properties to be able to connect server. How it can be made?
Thanks,