Octopus Server Trust Certificate Rotation

#1

Our Octopus servers use certificates for web and tentacle trust that are issued by a CA and have expiry dates that will require rotation (as opposed to self-signed 100 year certificates as suggested). It however isn’t feasible to manually update every tentacle for the new Octopus Server certificate when that time comes, so we have been attempting to automate this process.

We created a project to deploy to tentacles that will run the tentacle.exe with the command-line
‘configure --instance “Tentacle” --trust --console’
followed by a tentacle.exe call with command-line
‘server-comms --instance "Tentacle --thumbprint --style "TentacleActive --host --port --console’

Those 2 commands will create 2 new entries in the Tentacle.config file, one to get the thumbprint in as trusted (from configure --trust) and another with full thumbprint/address/communication style. The issue is that the server-comms command also creates a new subscriptionId that the Octopus Server does not recognize.

Although Octopus recommends using the 100 year self-signed certificates, I was hoping there would be a straight-forward way to add a new thumbprint to the tentacle trust for a server the tentacle is already connected to.

(Jim Burger) #4

Hi there @hardKOrr

Thanks for this question, and you’re correct in that we use self signed certificates by default, (I’ll link to this blog post to flesh out the reasoning there for others)

That said I can totally understand wanting to practice good certificate hygiene and rotating these certs on a regular basis would go a long way towards that.

You’re also not the first person to ask for this, so we recently built a command line feature for updating the trust of a tentacle.

I’ll make some updates to our documentation here to ensure that this is a more visible feature for others.

I do hope this helps you automate your certificate changeover - please do let us know if there are still issues here!

All the best,

#5

I had seen and considered the update-trust call from Tentacle, but that approach seems potentially very fragile. Tentacle update-trust will replace the current certificate thumbprint, which means that it can only be ran in a process that is immediately updating the octopus server certificate as it replaces the old thumbprint. The goal I had was to be able to trust the old and the new certificate at the same time, and after the new certificate was in place we can remove the old certificate.

Using update-trust means that the deployment to machines has to be 100% the first time, any machine left behind will not trust the octopus server once its certificate has changed… or if the certificate on the server did not rotate any machine that did receive the deployment won’t trust the server. The automated goal is to get as many machines as possible on the new certificate thumbprint as possible, while retaining trust for the older certificate, and then make the swap to the new certificate. This would reduce the manual load a great deal.

#6

Is there any additional information I can provide?
Generally speaking i need to be able to just add a new thumbprint for an existing server AND retain its SubscriptionId… since neither the client/tentacle nor the server are changing anything but the certificate.

There currently isnt a way I can use the tentacle to duplicate a trusted server connection and just update the thumbprint. I can either replace the thumbprint entirely or create a new trusted server connection with a SubscriptionId the server doesn’t recognize (causing a disconnected tentacle).

#7

So, is this issue just moot and the answer ‘just use octopus self-signed certificates to last 100 years’ ?