Looking at the error in the Tentacle log it seems to be a different issue than your previous one. This one is directly related to TLS versions and it does look like they are not matching.
We actually have this error on our docs page for troubleshooting schannel for windows tentacles:
The solution is to match ciphers and TLS version using something like IIScrypto
Since you mentioned it was an older machine its likely running on an older TLS version.
Can you have a look at that page and see if you can resolve it with our troubleshooting guide?
I am really sorry you are still seeing this issue, thank you for posting the IIS Crypto values up, I can see TLS1.2 is enabled and that should be used by default, however, I can see you are using Microsoft Windows 6.3.9600 in your tentacle logs which is the version that Windows 8.1 (Update 1) uses.
That OS is quite old now as we established and I am wondering if TLS 1.2 is not being used as default on that OS, you may need to force .net to use that TLS 1.2 version as default, we had an issue awhile back where machines were throwing the error below even though their IIS Crypto was showing as it was ticked.
You are using TLS version 1.0, 1.1 and/or 3DES cipher which are deprecated to improve the security posture of Azure AD.
You are not getting that error but I am wondering if forcing .net to use TLS 1.2 will help here, to do this you need to run the below from this guide:
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 if that fixes the issue, hopefully it will but if not we can dig a bit deeper, you will probably need to reboot the target machine once you have changed those registry keys. I will add though, that will force .net framework on that machine to use TLS 1.2 as default so if you have any old software on your target that requires 1.1 or 1.0 let us know as you might run into issues with that software if you change those keys to use 1.2 as default. You can of course, set them back to 1.1 or 1.0 if you need to.
Thanks for looking into this again - when i enter the command [Net.ServicePointManager]::SecurityProtocol i got
SSL3, TLS. in both QA (working) and Preprod (notworking) still i ran the command and rebooted the server. Tried the command to check and it shows same SSL3, TLS . Is there a way to compare my working Target VM non working Target VM to isolate the issue ?
Are you able to run that on your Non working tentacle, your working one and your Octopus server please and compare the results, they should all be the same, if one is different let me know and we can see where we need to go from there.
One other thing to note, I noticed in that article I posted up that the ‘SystemDefault’ value is displayed with older versions of Windows and .net installed. Can you check your working VM and non-working VM and make sure they have the same .net installed on them as that might also be a potential issue.
You should be able to use this document to check what versions are installed. You should also be able to see it from the Server Manager if running Windows Server:
Just following up on what the engineers had to say about this as I asked them if they had anything else we could try to get this working, they do not know what the issue is off the tops of their heads but they did have these things to check:
Is there any chance of you are using a more modern operating system, so upgrading to Windows 10 or 11 and see if you get the same issues?
From your logs I can see you are running Microsoft Windows 6.3.9600 which is Windows 8.1 (Update 1) as I mentioned in a previous comment so you will be hitting the issue where you are unable to install .net 4.8 separately. Since it looks like you are running tentacle 6.2.277 you should not need .net 4.8 (you will need it to upgrade to tentacle 6.3 in the future though so watch out for that!).
Do you have .net 4.8 installed on that machine though (it will either be in control panel > programs or it will be a feature in ‘Turn Windows Features On or Off’ in control panel > programs?
Is there a firewall, proxy or Azure Network Security Group between the tentacle and the Octopus Server?
Have you tried running it as a polling tentacle?
It is not clear to the engineers if the error is occurring due to the registration part of the setup or when the tentacle establishes its halibut connection over port 10944? DSC supports debugging which might help.
There is a fallback, if all of this fails the engineer said you could script it yourself by running the tentacle manager once and grabbing all the setup commands and then dump that in a PowerShell script step in the DSC. I believe this is what you have done though from our previous conversation.
The debugging might be a good thing to check out and also the .net version if you are able to, I hope those suggestions help, we are stuck a bit on this one I am afraid and we want to get this working for you so let us know what you find.
One other thing sorry, when looking through your logs the engineer noticed you have an API key written in plain text and this is a public forum so someone might have spotted that (I did not but I did not dig through your logs that deep). Also I noticed its on a really long line and my text editor VS Code does not word wrap the text unless I tell it to so I did not spot in unless I searched for ‘API’ in the log.
I have set this post to private so our public customers cannot see it, the API key in question is in the Server Tasks-255308 log. I will DM you with a screenshot of that key but it has been on here since Feb14th so I highly recommend you revoke that key and change it.
I will keep this post private so others cannot see it,
Kind Regards,
Clare
I wanted to reply again as one of our other customers put a ticket in for a semi-related issue yesterday, they were getting algorithm error messages on their polling tentacles (6.2.277) and they had all of their IIS Crypto settings the same as their Octopus server.
I basically took them on the same journey we have been on, checking .net for the TLS settings etc.
In the end they manually uninstalled their polling tentacle but on the re-install they upgraded to the newest tentacle 6.3.417 - on doing so they needed to install .net 4.8 (due to the new 6.3 tentacles needing 4.8) and that fixed the issue!
I think installing .net 4.8 on their tentacles possibly reset their protocols and ciphers and that is why it worked but we are not sure of the exact reason it did work.
Are you able to try that on this machine please if you are able to?
You do not need to manually uninstall the current tentacle but you will need to install .net framework 4.8 and then upgrade the tentacle to 6.3.417 and see if that fixes this issue. It is a long shot but since it helped the other customer I am willing to bet it may help us here.
Let me know if you are able to try that out!
Kind Regards,
Clare
Thank you very much Clare for all your efforts you have been putting on resolving this.
Sorry I was not able to reply due to a long leave and as we wanted to push the code to production we had to manually copy paste the code config to proceed further with the deployments.
I will remove the key as you suggested asap.
I tried [enum]::GetValues(‘Net.SecurityProtocolType’)
Results as follows :
Working evironment : System Default, SSL3, TLS, TLS11,TLS12
Non working environment: System Default, SSL3, TLS, TLS11,TLS12
Octoups server : System Default, SSL3, TLS, TLS11,TLS12 and TLS13
Thanks for the lovely feedback and for the screenshots, everything is the same across working and non-working machines so I do not see why one machine works and one does not, very bizzare!
I am really hoping the upgrade will solve this because honestly we have now tried everything in the toolbox to get this to work barring actually spinning up a new VM (or physical server) and putting a tentacle on that. Which if this upgrade does not work would be the next thing I would suggest, though that is really not ideal and I would rather not suggest scrapping a VM and building a new one just to make one program work!
Let me know how you get on with the upgrade, if that does not work it may be trying to spin up a new VM and seeing if that will work with a tentacle will be the way forward here.
I look forward to hearing from you,
Kind Regards,
Clare
