How to Store Azure certificates in variables

We’ve got multiple installs of an application and based on the installation different certs are used.

Replacement of variables ion the cscfg files only seems to support the configuration variables and not the certificates.

We only want to replace the certificate at deploy time, not at package time (so creating different releases is not an option), i.e. we have the same release (version) deployed to multiple sites that use their own SSL Cert.

What would you recommend is the best way to do this?

I’ve tried putting variables in the cscfg files, but i get build errors because the syntax #{varible} is invalid for the xml specification of this type.

I’ve also looked at xml transforms, but these seem to only support .config files

Practical example from ServiceConfiguration.Cloud.cscfg


Where XXXXXXXXX is the value we need to replace.


This is also an issue for us. We deploy the same application to multiple regions and have different certificates in each. To be able to substitute the certificate thumbprints using the variables would mean that I don’t have to create a deployment package with a different cscfg file in it for each region.


Hi Phil & Joel,

Thanks for reaching us! On V 2.3 we added support for Variable Substitution on any kind of files. Here’s our post about it:

If any of you guys need a more detailed example, i’ll be glad to provide you with one. The post does a pretty good job explaining this feature though.

Let us know how it goes :slight_smile:


That doesn’t work mate. Please read my original post. The project won’t build. It says there is an xml error.


Sent from Samsung Mobile

Further to my last post, here is the error i get when trying to package a cscfg file with a thumbprint in format #{variable}

Error 122 The XML specification is not valid: The ‘thumbprint’ attribute is invalid - The value ‘#{varible}’ is invalid according to its datatype ‘’ - The Pattern constraint failed. D:\SOURCE\oztix\solCore\Oztix.TABS.OnlineOutlet.Azure\ServiceConfiguration.Cloud.cscfg 104 35 Oztix.TABS.OnlineOutlet.Azure

Below is the XML i used in the file

This does not work, do you have any other solutions?


Based on a conversation with Joel I’m pasting the answer here too.

If you take a copy of the DeployToAzure.ps1 from the tentacle scripts directory and add it to your nupkg you can modify it to suit.

Unfortunately we don’t bootstrap it with all the Octopus variables so for today you have two options.

  1. Use a dictionary of Cloud Service name and thumbprint and update the cscfg file before it’s pushed
  2. Actually package a transform or cscfg for each cloud service and transform / choose which config you want as part of your deployment.

We’ll be looking over the next week or so at how we can better support configuration for cloud services and how quickly we can get that on a roadmap.




Thank you for the response. We will look into the powershell script.
Please can you keep me in the loop on further suggestions / roadmap as I
would like to keep this as a configuration setting like the variables so
that non-technical staff can administer this.

Thanks -

Philip Cooper |

I accomplished this by using a pre-deploy script that loaded up the cscfg in an xml dom and edited all of the non standard settings I needed to based on variables (vm name, certs, etc). I don’t have the script handy at the moment, but if people are interested, I’d be happy to post it here.

Yea i’d love to look at that script Ed!

Can you please post?


Powershell script I use as my pre-deployment step can be found here:

Any chance this has been addressed in Octopus 3.0?

Hi Nick,

Yes, as of 3.0 if you run some powershell against an Azure target it will have the Azure context loaded. See here

This may change a little for 3.1 but we’ll let you run this method alongside for a while too.

Hope that helps


Have there been any improvements to this? I would prefer not to have to mess with my own powershell script, rather just have a way to replace this with something that passes build.


Thanks for getting in touch. I’ve commented on the other thread you opened with a similar question.

I think the correct answer is to use “Additional Configuration Transforms” as recommended by the other thread.

Hope that helps!

Thanks, I wasn’t sure if this question/thread was monitored.

Hi Everyone,

You should be able to use a combination of deployment features to achieve this:

  1. CloudService.cscfg has your development thumbprint
  2. CloudService.Environment.cscfg has the config transform, but where the value of the Thumbprint, use a Variable Substitution expression: xdt:Transform="SetAttributes(Thumbprint)" Thumbprint="#{MyThumbprint}"
  3. Enable the Substitute Variables in Files feature targeting the CloudService.Environment.cscfg file
  4. Enable the Additional Configuration Transforms feature targeting CloudService.Environment.cscfg=>CloudService.cscfg

Now when the deployment runs, Octopus will first perform the Substitute Variables in Files, updating your config transform file with the Thumbprints. Octopus will then run the Configuration Transform setting the attribute with the substituted thumbprint.

For more information on the ordering of these features take a look at our documentation.

Hope this helps!

I do not see a way to enable ServiceConfiguration config transforms. Is there a setting somewhere I’m missing? I can only find ways to manage the configurations (add, remove, etc.). None of the options I can find will allow the new schema (xmlns:xdt=“”) and attributes to build locally. This is in VS 2015 Enterprise.

Can someone help me figure out what I’m missing?

Hi @djansen,
I’ll answer this one on behalf of Mike as he’s currently away on leave.
I believe the transform he is referring to is the Additional Configuration Transforms feature in your Octopus deployment step, not in Visual Studio.
So the idea is that in your development machine where you are using and writing the app, you can just include your certificate information in the normal CloudService.cscfg file. This will be used when you are running and debugging locally.
The additional file CloudService.<MyEnvironment>.cscfg is what has all the transformations that need to take place and isn’t used in Visual Studio, but simply bundled up into your nupkg so that it can be used by Octopus.
At build time, when the package is extracted the variables in CloudService.<MyEnvironment>.cscfg are replaced with what you would expect given your MyEnvironment environment scoped variables, and then you also instruct Octopus to perform the Configuration transform logic with CloudService.<MyEnvironment>.cscfg=>CloudService.cscfg, in a similar manner to normal web.config transforms.
If that does not quite make sense perhaps have a read through the documentation links Mike included in his above post.
Let me know if you still require clarification on any of the specific steps outlined in this solution.

Okay - that makes a lot more sense. Thanks! I have this transforming the file now.

Is there a way to see the post-transformed file to make sure the transform is working as expected?

Hi @djensen,

Thanks for getting back! I had a chat to one of our devs and we are unable to find a solution to what you want here. The only thing you can do is deploy, browse to the deployed location and check that the files are being transformed.