I hope someone could help us try to identify the issue here.
Basically our stand alone Octopus Server now stops connecting to our eternal DevOp feed.
The server version is v2021.1 (Build 7236) running off a Window Server 2012 R2 with .Net 4.8 installed and we have TLS 1.2 enabled.
When we try to connect to our external feed on DevOps we get the following error:-
“The SSL connection could not be established, see inner exception. Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host… An existing connection was forcibly closed by the remote host.”
We are not sure what could be causing this all of a sudden as this has been working.
I can confirm that the Access Token we using is correct and had not expired.
Our technical team assures us that all ports are open and we can browse to our DevOp instance directly on the server itself.
I have attached a log entry from the log file if that helps. OD_Log.txt (17.4 KB)
I’m sorry you are having trouble with this particular feed connection from Octopus Deploy, but I’d be happy to help take a closer look at the issue.
As an initial troubleshooting step, could you try running IISCrypto on your Octopus Deploy instance to make sure all of your underlying protocols are set as expected? I’ll include our documentation on using this software, but let me know if you have any questions.
If reapplying the proper protocols via IISCrypto and rebooting doesn’t seem to help, we do have some additional guidance for setting TLS 1.2 a little more granularly for .NET itself, which may help here:
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.
Let me know how it goes, and feel free to reach back out if you are still having trouble.
Thanks for the response. I can confirmed that these steps did not resolved the issue.
However in doing these steps especially using IISCrypto we found out that the server was missing 2 cypher suites. Once we enabled them using IISCrypto the connection was re-established.
It’s seems there is a GPO that is removing them whenever the server is rebooted. So we are looking into resolving this at this time.