Powershell Azure scripts failing due to TLS 1.2 issue

[digital1 (Simon)]

Hello,

As of two days ago, any step in our deployment process that uses an Azure Powershell Script will fail. The original error was:

You are using TLS version 1.0, 1.1 and/or 3DES cipher which are deprecated to improve the security posture of Azure AD.

We switched off all TLS client versions lower than 1.2 on the server (Windows Server 2016 Standard) and now the error is:

Service returned error. Check InnerException for more details

The inner exception refers to “Authenticating with Service Principal”.

This error can be replicated by using Powershell (5.1) itself, but can be mitigated by running this before any command:

[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12

But I don’t know the equivalent of doing that within Octopus i.e. how do we force Octopus to run Powershell using TLS 1.2?

We use Octopus Server 2019.12.0 LTS (we know it needs an upgrade).

Thanks
Simon

[paul.calvert]

Hi Simon,

Thanks for getting in touch!

We’ve had a couple of other users run into this issue since Azure made this change.
They could get this working by forcing .NET to use TLS 1.2 on the server itself.
One user advised that this guide was useful, specifically this part:

To enable code to use the latest version of TLS (e.g. 1.2) the following registry changes may need to be made:

Open Powershell and check for supported protocols by using [Net.ServicePointManager]::SecurityProtocol
Run the following 2 cmdlets to set .NET Framework strong cryptography registry keys:
set strong cryptography on 64 bit .Net Framework (version 4 and above)
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
set strong cryptography on 32 bit .Net Framework (version 4 and above)
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
Restart Powershell and check again for supported protocol by using [Net.ServicePointManager]::SecurityProtocol
It should now display Tls12 as well.

Regards,
Paul

[digital1 (Simon)]

Thanks Paul,

Amazingly our IT department just found the exact same two registry key changes and implemented them moments ago. I can confirm this resolved the issue for us.

It took a few hours of searching to get to this point so hopefully this thread will help others.

Cheers
Simon