Tentacle at Ubuntu Server 20.04 LTS

When I try to add machine to the Octopus Server I get: “Unable to receive the remote identity; the identity line was empty.”

The procedure for installing Octopus Tentacle at Linux is the same as we used to install it at CentOS/Debian - there were no issues with adding machines to the server’s infrastructure.

Any advice?

Edit:
I’ve tried generating new client certificate (Tentacle new-certificate --instance “Tentacle”) and re-adding server as trusted (Tentacle configure --instance “Tentacle” --trust THUMBPRINT) but problem persist.

Edit:
Log from Tentacle service status:
“A client at [::ffff:x.x.x.x]:xxxxx connected, and attempted a message exchange, but did not present a client certificate”

Edit:
Removing instance and re-adding it once again also doesn’t help

Edit:
This seems like the exact same issue: https://github.com/OctopusDeploy/Issues/issues/6262
But we’re not using Octopus Server 2020.1.4, for now. Currently we have 2019.13.7 installed

Edit:
After generating new client (Tentacle) certificate Octopus Server correctly detects its change with an error: “We expected the server to present a certificate with the thumbprint ‘xxx’. Instead, it presented a certificate with a thumbprint of ‘xxx’”.
But when I change machine thumbprint to the new one, the original issue is back: “Unable to receive the remote identity; the identity line was empty”

Hi @rafal.gapski!

This is an interesting one - we’ve seen this error previously when tentacles running on modern versions of their respective OS, such as Server 2019, are attempting to connect to an Octopus server that might still use a SHA1-encoded certificate (this was the default encryption used for certificates before Octopus version 3.14) - If you have had your Octopus server active since before then, this is likely the case, and the SHA1 negotiation is being blocked by newer versions of OpenSSL.

You can check what encryption your certificate uses by navigating to Configuration -> Thumbprint, and you should see a line that reads The server certificate uses the sha1RSA algorithm. or similar. If this is the case, this is what’s happening. We now use sha256RSA encryption.

There’s some minor manual work involved in getting this fixed up, basically generating a new server certificate and then updating the trust on your Tentacles to trust the new thumbprint (which is looks like you have done already, just with the old thumbprint)

I hope this helps.

1 Like

You got this right, Configuration -> Thumbprint reports sha1RSA algorithm.
But if I’ll generate new server certificate (sha256RSA) as I understand ALL tentacles will stop trust our server? And I’ll have to manually update server certificate (update-trust) at ALL tentacle machines? It’s 100 servers in our case. Is there any other way?

Edit:
The best I might think about is this scenario, based on https://octopus.com/docs/security/octopus-tentacle-communication/custom-certificates-with-octopus-server-and-tentacle

  1. export current server certificate (Octopus.Server.exe export-certificate) to .pfx file
  2. generate and import new certificate (Octopus.Server.exe new-certificate --export-pfx) - this will break Tentacles’ trust
  3. import back old certificate (Octopus.Server.exe import-certificate) to maintain already trusted Tentacles
  4. execute Octopus Task for ALL Tentacles to add second, new, exported certificate’s thumbprint (Tentacle.exe configure --trust) - all Tentacles will trust both old and new certificate
  5. import new, already generated certificate to Octopus Server (Octopus.Server.exe import-certificate)

Can you confirm that this scenario will actually work and we’ll not lost Tentacle’s trust, which will save us from manually adding new thumbprint at all 100 machines?

That should work, yes, assuming they’re listening tentacles. One potential issue here would be that the tentacle service will need to be restarted for this to go into effect. If you’re doing this from inside Octopus, attempting to restart the service will likely cause the task to fail (since the stream goes away), but the expected outcome should occur, with the additional trust reliationship being established. So when the next healthcheck/deployment happens, it should work as anticipated, using the new certificate.

1 Like

One more thing - does re-importing old pfx certificate will generate the server thumbprint in the very same way as before (sha1 instead sha256)? Because as I think about it, even if certificate will remain the same, the thumbprint of it will be different for different SHA methods.

I’ve imported private certificate at my computer just to see its details. As I might see, the SHA-type algorithm is included in the pfx itself, so I guess re-importing this certificate to Octopus should still result in the very same SHA1, and not different SHA256 server thumbprint.
But I need you to confirm that for me.

Edit:
One more question - can I trust 2 servers (I mean, same server, but 2 thumbprints) at the same time?
As I understand I may achieve this with tentacle configure --trust NEW_THUMBPRINT instead of tentacle update-trust, and tentacles will trust both new and old thumbprints?

Edit:
Another question - does changing thumbprint will result in any other problems that we might have? F.ex. lost secure variables in projects?

Hi @rafal.gapski

You’re correct that the encoding is on the certificate itself.

As a side-note, while server-side certificate regeneration and push isn’t currently supported (but it’s on our list for when time permits, I did find this Docs PR that goes over this process as well as having a few code snippets and API calls that you can use here - https://github.com/OctopusDeploy/docs/blob/a07f630c683f0bb026bb1218bb24f788cda0a67f/docs/how-to/how-to-regenerate-certificates-with-octopus-server-and-tentacle.md

Re edit1: You can trust multiple thumbprints this way, yes.
Re edit2: No, all of your in-octopus data will remain through this process, this is a different encryption system, controlled by your Master key.

I hope this helps!

1 Like

This documentation looks like exactly what I need, but step 3 (calling API from Powershell) gives me 400 HTTP Error Code.

It doesn’t matter - I’ll handle this with Octopus Tasks, in UI :slight_smile: Thank you for your help.

1 Like