Best practices for disabling older SSL/TLS protocols on Octopus Server

Hello,

We would like some assistance on the best practices for disabling older SSL/TLS protocols on Octopus Server. We’ve found the document about hardening Octopus (Hardening Octopus - Octopus Deploy), however, when we use the script in there to disable SSL 3.0, TLS 1.0, and TLS 1.1 and reboot the Octopus server, the initial health check that runs at startup fails for our deployment targets. We have both client on-premise and hosted (by us) targets, ranging from Windows Server 2012 to 2019. All of them are polling based. All of them are running version 4 or newer as I know that in version 3, you made TLS 1.2 the default communication type. The Octopus server is running Windows Server 2019.

We were wondering in addition to the script we ran in the document above, is there anything else that needs to be updated, like anything on the deployment target end, like turning off the same protocols on those servers? Is there anything else on the Octopus server that we need to enable/disable? After disabling the old protocols on the Octopus server, we could access the web site, but the health checks were failing.

Any assistance would be appreciated.

Thanks,
Matt

Hi Matt,

Thanks for reaching out! I’m sorry that you are having trouble disabling older SSL/TLS protocols on your Octopus Server, but I’m happy to help take a look at the issue.

From what you’ve described it sounds like there may be a protocol/cipher mismatch between your Octopus instance and connected tentacles, so as a first step I’ll link our documentation on how you can check these settings on each side to confirm that they match using IISCrypto.

If everything looks good after reviewing the above, if you happen to have those failing health check task logs from when you tried to disable those older protocols before it would be good to review those to see if they shed any additional light on the problem - feel free to upload a sample of those to this secure link (if they are still accessible).

In mentioning the failing task logs I’m wondering if you are running into this particular issue from our documentation where there is a problem with the length of the RSA key used by Octopus when locking communication down to TLS 1.2 only, which we could confirm by reviewing the task log output.

Looking forward to hearing back from you!

Best regards,

Britton