I’ve just started to migrate some custom Step Templates that use base64 strings for certificate variables to use the Certificate Library feature instead. I’ve read the documentation at https://octopus.com/docs/deploying-applications/variables/certificate-variables but I think I’m missing something about how the Expanded Properties work.
In short, I’ve got a custom step template which has a certificate parameter called “MyCertParameter”, and the step is used in a project which has multiple certificate variables called “MyCertVariable” scoped to different environments which all reference Certificate Library entries (.e.g “MyCert-DEV”, “MyCert-TST”, etc). The project sets the parameter in the step to a custom expression “#{MyCertVariable}” so deployments use the correct certificate for the environment we’re deploying to.
When the script in the step executes, the $OctopusParameters[“MyCertParameter”] entry contains the name of the certificate library object - e.g. “certificates-mycert-dev”, but there are no expanded properties like $OctopusParameters[“MyCertParameter.Thumbprint”]. I can see the variables have been expanded - e.g. $OctopusParameters[“MyCertVariable.Thumbprint”], just not the step parameter.
Thanks for contacting us. The certificates object is available in all the scripting languages, and not all of them allow for complex objects like PowerShell. So when setting the variable in a custom expression Octopus Deploy only sets the value as a string, which is the name of the certificate.
I think in your scenario you can use #{MyCertVariable.Certificate} to get the base64 encoded version of the certificate.
I’ll try your suggestion, but I was kind of hoping that when the Step Template’s script gets executed the certificate Parameter would be automatically expanded into multiple strings inside $OctopusParameters in the same way that the Project’s certificate Variables are. E.g. if a Step Template has a certificate parameter called “MyCertParameter” I’d be able to access the expanded properties inside the Step Template script using the parameter name (not the variable name, as the variable name could vary between different projects):
Project Variables
MyCertVariable = (certificate library object)
Project Step Definition
MyCertParameter = "#{MyCertVariable}"
Current $OctopusParameters in running Step Template script
That way, the Step Template script doesn’t need to know the name of the Variable in the Project, just the name of the Parameter that the Step Template defines.
I’ll let you know how I get on with the “#{MyCertVariable.Certificate}” route you’ve suggested, although I suspect I might also need another Parameter in the Step Template for “#{MyCertVariable.Password}” as well.
I think I found the problem. There was a bug to do with certificate step templates that was fixed in 3.13.4. https://github.com/OctopusDeploy/Issues/issues/3357 This bug also meant that step templates were not copying the extra certificate variables like thumbprint across properly.
What version of Octopus Deploy are you running? Could you try upgrading to the latest and see if that fixes the issue for you. I managed to get a project with a custom template and a certificate parameter working in 3.15.4.
Ah, yes. That link described the issue much more succinctly than I did :-). We’re using version 3.12.4, so I’ll speak to the server admins about upgrading to the latest version.
In the meantime, I’ve modified my step template so that MyCertParameter take a string containing the name of the variable that references the certificate and then the code in the step template uses the technique in the link, i.e
It means I don’t get the nice pretty certificate selector dialog when using the step template, but I can go back and refactor things once our server has been upgraded.