We use Teamcity to push packages to Octopus server for a long time and we are now testing our newly created pipeline in Octopus cloud using the same Teamcity.
We used “https://xxxxx.octopus.app/Spaces-1/nuget/packages” as NuGet packages feed URL and a Service account API Key. We are getting " *The request was aborted: Could not create SSL/TLS secure channel." build error in Teamcity Push package step to Octopus. Do we need to add any port to the url?
Thanks in advance.
Good afternoon @subadhra.raja,
Welcome to the Octopus community and thankyou for reaching out. I am sorry to hear you are having trouble connecting your TeamCity server to your Octopus Cloud instance.
You should just be able to use the URL of your instance along with an API key, you should not need to specify the space and where the packages are.
So you would need these values in the project build settings (replacing URL with https://xxxxx.octopus.app/ and you can specify the API key and space name below):
Does that help at all?
Let me know if it doesn’t but it seems you just want to use the default space (Spaces-1) so you would just need the URL of your instance ( https://xxxxx.octopus.app/ and a valid API key in the boxes I have highlighted.
I look forward to hearing if this works for you, reach out in the meantime if you need anything else,
Thanks for the quick support @clare.martin
we are using the NuGet Publish Runner type in Teamcity and we don’t have the option to specify the Space name in this step.
But I did try using the https://xxxxx.octopus.app/ and a valid API key
Still getting the same build error
Thanks for giving that a try and I’m sorry to see you’re still running into that error. If I understand your scenario correctly, you have a locally hosted Teamcity server that is trying to connect to a new Octopus Cloud instance?
If that’s the case it could be that the machine running Teamcity is not currently using TLS1.2 to communicate with the cloud. My thinking is that this is a very generic SSL/TLS error and ciphers could be missing for the API communication.
In Windows, you could run something like
[Net.ServicePointManager]::SecurityProtocol from PowerShell and it should return at least all 3 of these:
Tls, Tls11, Tls12
Looking forward to hearing back.
Yes you are right, we have our locally hosted Teamcity in a Widows Server 2012 R2 server trying to connect to our new Octopus cloud instance.
I got Ssl3, Tls as response to the
[Net.ServicePointManager]::SecurityProtocol from PowerShell.
Does that mean we need to enable Tls1.1 and Tls1.2 in the Server registry something like this How to Enable TLS 1.2 as the Default Security Protocol on Windows Servers | IT Nota?
Thanks for confirming that.
That article looks pretty good as a guide. You will need to do something like that to get TLS1.1 and TLS1.2 on the Windows 2012 machine. You might additionally need to upgrade/update your .NET depending on what your machine currently has.
We also have a bit more information about TLS and troubleshooting here (it’s not an exact use case match but should be helpful):
I apologize I cannot be a bit more helpful on the server configuration, as every environment is different I cannot make any concrete recommendations.
Please let us know if those updates help get you unstuck.