Referencing certificate variables

[Aleksandras]

Hi,

I got a challenge with certificate variables, when I wanted to add some additional logic to select needed certificate dynamically.

Normally when you add certificate variable (e.g. #{PrimaryCertificate}), you can access all its’ properties - like #{PrimaryCertificate.Thumbprint}, #{PrimaryCertificate.Password}, etc.
However if I reference certificate variable in another variable - all these additional properties are lost. E.g. if there is #{RerefencedCertificate} = #{PrimaryCertificate} - you cannot use #{RerefencedCertificate.Thumbprint}.

I understand it’s a bit too complex and probably not without a reason, but I can describe why it’s needed (maybe you will be able to give any other suggestion how to achieve similar thing).

Imagine we have a case (Service Fabric deployment) and need to switch primary and secondary certificate from time to time. So I added a variable saying which certificate is main one at the moment.

That’s how it looks like:

I just want to change only one variable (#{Certificate_Active}) to be able to switch certificates.
#{Certificate_ServiceFabric_Primary} returns same name as real certificate variable #{Certificate_ServiceFabric_1}, which means variables logic itself is working.
However in this case I cannot use #{Certificate_ServiceFabric_Primary.Thumbprint}.

I need three certificates properties (Thumprint, Pfx and Password), because I need to upload certificates to Azure Keyvault. So solution might be to replicate all above logic for all these properties separately, but it would be a bit too complicated to maintain, I strive to keep it more simple.

One of the options would be just rename #{Certificate_ServiceFabric_1} variable to #{Certificate_ServiceFabric_2} and vice versus, when you need to switch, but the problem that usually we need to switch only for one environment (we have 3). So in this case we would need to set certificate variable value to different certificate only for needed environment, but it would need much more steps - i.e. more space for mistakes.

Any ideas or other suggestions? Can it be workarounded somehow? Maybe it’s just should be referenced in a slightly different way?

[Michael_Compton]

Hi,

Thanks for getting in touch with such a detailed and thought out question.

I think the two options if you want to do this are to either have a single variable and switch the value depending on the deployment you are doing, or to scope the variable to some part of the deployment that changes. It seems like that can’t be environments (because I take it from what you said that you want the two certificates in the one environment), but you could set up tenants to represent your two cases. Or maybe if the actual targets are different in each case, you could scope the value depending on the target.

If those suggestions aren’t quite enough, feel free to get back to me with more of a description of the setup and why you want to switch certificates and maybe I can come up with something further (feel free to mark the thread as private if you don’t want any details public).

Michael

[Aleksandras]

Thanks, Michael, for the response!

Actually for now I also ended with something completely different (well, not ended, but going to try it and implement proof of concept). However you didn’t addressed my original question - about “chaining” certificate variables. Does it suppose to work like I mentioned (#{Certificate_ServiceFabric_Primary.Thumbprint})? Is it a known limitation, or used in a wrong way, or can it be considered as oversight from Octopus team?

Regarding why I need to switch certificates - it’s something known as recommended practice to update secure Service Fabric certificates when they expire. Service Fabric can “own” two certificates, but only one is used as an active one. When you want to update active certificate - you replace inactive one, and then swap it with the active one. More details are here - https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-security-update-certs-azure

If this practice might be “known”, then how I’m trying to solve it using Octopus - might be less “known”. So if you have any better suggestions - would be fun to hear.
Currently I’m going to move all certificates handling logic to a separate deployment project, which will handle all such swapping, etc. While main project will have only needed certificate variable(s).

Update:
It seems there are some quite new changes in Service Fabric tooling/SDK - seems like you don’t need to switch certificates any more, the one which expires the latest will be used automatically as default one. I’m going to try it now and if it’s so - it will simplify a lot of things.

[Michael_Compton]

Hi,

I’m glad you’ve found a solution to try.

In answer to your question, no it’s not possible to chain certificates. It’s by design as Octopus expands the variable set to include all it’s properties on the server when it’s building up the variable set - it doesn’t resolve those dynamically as it does when evaluating some other variable expressions.

I’ve also discussed this with our Cloud team and their advice is that yes, in the new tooling you don’t need to switch certificates in the same way. Also, they mentioned that if you did have to swap certificates that the best method is probably just to update in SF and then update the variable in Octopus - you’d have to update one of the certificate variables anyway every time you swapped, so there wouldn’t be much of a saving even it was possible to chain certificates.

Hope that all helps.

Michael

[Aleksandras]

Ok, thanks, answer to my original question about chaining certificates is clear. I agree, some of the cases might be still not solved with what I wanted, but it was just proof of concept. However I guess it could be mentioned somewhere in Octopus documentation, that certificate variables has such limitations, because in Octopus it’s kind of natural to chain/reuse variables.

Unfortunately I’m still struggling with certificates update for Service Fabric, but I need to admit, that it’s probably totally not Octopus related. There were some changes in Service Fabric tooling, and some things don’t fully work as documented (or documentation part is not updated yet following implementation changes)…

Thanks for your help!