Hi, I’m just having some trouble with my deployments when we disable TLS 1.0 on our destination server. We need to disable this in order to remain PCI compliant. Specifically, I have been told that the following is taking place in order to disable TLS 1.0 -
To disable all instances of TLSv1.0, within the Windows 2012 R2 Registry Editor under:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client
The ENABLED key DWORD value set to 0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server
The ENABLED key DWORD value set to 0
Prior the key values were set to 1
As soon as this is done, our deployments fail. Specifically, it fails when trying to run a Powershell script that de-registers an EC2 instance from an ELB in our AWS environment. I was reading through this page and it says I will need to update the AWS Tools for Powershell. I have already tried installing the latest version on the machine that runs the Octopus Deploy server, with no luck. I’m not sure if this is something that is bundled with Octopus, or if it’s a totally different problem I need to solve, so any sort of guidance in this area on how I can fix these deployments would be greatly appreciated.
We do bundle the AWS CLI and Powershell modules and will be updating these to the following version:
Powershell Modules: 3.3.343.0
AWS CLI: 1.16.15
This should be released as part of 2018.8.9 very shortly. Unfortunately, there isn’t any way to change the versions of the dependencies that we use for our AWS script step at the moment. I have created this issue to rectify that. You can also use the issue itself to track the progress of the feature.
If you are on version 2018.8 then you can also potentially leverage multiplate step script packages. This would allow you to use a normal script step and additional package, such as the AWS cli of your choosing. The only caveat around this, is that you would have to manually use the AWS account details to login etc.
Please let me know if you have any questions or concerns.
Thanks for the info. Do you happen to have a rough ETA for 2018.8.9? If it’s coming out in the very near future, it may be easiest for us to just wait for its release.
What other info do I need to send through in order to help you help me? I’m sure you’ll need more than that, but I’m not entirely sure what I need to send .
I believe the .NET Framework defaults to TLS 1.0 when strong cryptography has been disabled which this blog post covers pretty well. It also provides an example on how to enable strong cryptography in versions 4.0 and later of the .NET framework:
# 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
I have tested this on my end and does have the desired effect which is to use the highest level of TLS currently available on the system and should get around this issue for you in the meantime.
Please let me know if that helps or if you run into any problems.
I tried making these changes on the server that has the Octopus Deploy server, and still have no luck. Is this correct, or is the Tentacle running the script from the destination server?
I was not aware you could control where each step is executed. Until very recently, I was using a very old version of Octopus Deploy, where I believe it must have been running everything from the tentacle? Anyway, updating to the latest version and finding this feature has been the perfect fix for me, thank you again!
.