Polling Tentacle using TLS 1.0 for Octopus Registration (on Server 2012r2 machine)


As part of a security requirement for using Octopus Deploy, we are going with the Polling option for our tentacles and are restricting network communication between the Tentacles and Octopus to 443 (Configured Binding) and the default port for tasks (10943).

The issue is that on our Octopus Server, we have disabled support for non-PCI complient protocols (TLS 1.0 included), whenever I attempt to validate my credentials it fails with the error you might expect, socket connection error:

System.Exception: Unable to connect to the Octopus Deploy server. See the inner exception for details. —> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. —> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. —> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)

I can connect to the Octopus Deploy website from these client machines (via telnet on 443 + IE), it’s not a firewall issue. If I remove the TLS enforced TLS restriction on my Octopus server and reboot, it’s able to register and validate itself fine.

When I inspect the network traffic, I see the Tentacle send the
Client Hello: Version: TLS 1.0
Cipher Suites: TLS_DHE_DSS…, (OMMITED, there’s a bunch)

From my readings, the newer version of Octopus/Tentacles are suppose to support TLS 1.1,1.2 with .NET 4.5 – as far as I can tell, the servers I’m working from have .NET 4.5 installed (default with Server 2012r2?)

Is there a known issue specifically with Tentacle setup and it’s inability to do credential validation over TLS 1.2?
Is there any way I can force a specific TLS version while doing the setup?

I can provide further details if needed.

I used Tentacle MSI version: Octopus.Tentacle.3.2.22-x64.msi
Operating System: Microsoft Windows Server 2012 r2
Connecting to Octopus Server version: 3.3.2



*Edit: corrected Octopus server version

Hi James,

Yes, this is an issue. I have raised a GitHub issue which you can track. We will get this resolved as soon as possible.

As you have already surmised, the registration commands sent by the Polling Tentacle to the Octopus Server are not using the appropriate TLS version. The only work-around for the meantime is to disable the TLS restriction during Tentacle registration.

We apologize for any inconvenience.


Ahh, glad I saw this. We were about to disable the older protocols in the next day or so.
Think I’ll put that CR on hold!


We still seem to be seeing this issue - I’ve tested Tentacle versions 3.3.4 through 3.3.9 and all exhibit the same error when attempting a command-line registration:

.\Tentacle.exe register-with --instance "Tentacle" --server "https://MyOctopusServer/" --name "MyServer" --username "MyUser" --password "MyPwd" --comms-style "TentacleActive" --server-comms-port "10943" --force --environment "MyEnv" --role "MyRole"

The underlying connection was closed: An unexpected error occurred on a send. System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IO Exception: Authentication failed because the remote party has closed the transport stream.

As a comparison I have run the above command with Fiddler running and have gotten it to work after setting Fiddler to only use TLS 1.2 (type prefs set fiddler.network.https.SupportedServerProtocolVersions tls1.2 into the QuickExec box).

One final bit of due diligence before posting here was to dotPeek into Tentacle.exe. he only potentially relevant thing I noticed in a very brief poke around was that whilst Octo.exe has an explicit reference to ServicePointManager.SecurityProtocol in its Progam class, Tentacle.exe doesn’t.

Do you have any other tests I could try?



Thank-you for reporting this, and for your investigation.
I believe your diagnosis is correct. I think the work done for this modified the Tentacle Manager (i.e. Tentacle.Manager.exe) to communicate over TLS 1.2, but not Tentacle.exe.
Which would explain why your register command is failing when you are invoking it explicitly via Tentacle.exe.
I will re-open the issue, and we will get this resolved as quickly as possible.

Thanks again, and apologies for any inconvenience.


OK, thanks for the confirmation Michael.


I’ve committed a fix for this. It will ship in our next release (3.3.11), which should be sometime next week.

Great stuff, thanks for the speedy turnaround.