Optional Certificates

[jmccollum]

I know this is ultimately related to https://github.com/OctopusDeploy/Issues/issues/2709, but I’d like to see if there was a known workaround for this particular portion.

I would like to start using OD-managed certificates for my (tenanted) deployments, but want to do it in a ‘phased’ manner. To that end, I’ve updated my process to help accommodate this:

• Added a EnableOctopusHttpsEndpoint and OctopusCertificate Project template variables (checkbox and certificate types, respectively)
• Added a new binding to my Deploy to IIS step which uses effectively the same steps as my original (thumbprint-based) HTTPS binding. The difference is that it uses Certificate managed by Octopus (with a reference to the variable above), and is only enabled based on EnableOctopusHttpsEndpoint.

At this point, let’s say I have one tenant that has an OD managed certificate, and another that uses the thumbprint, both in the same environment. When I go to deploy the release to both of the tenants, I am unable to even start it due to an error

Unable to find certificate with thumbprint [guid]…

It looks like I can put any certificate I want into the tenant variable, but I don’t feel comfortable doing this, as it could potentially deployed when (or to where) it shouldn’t have been.

This doesn’t really happen for other variable types as far as I can tell. Ideally this would be covered by the optional variable template, but I don’t want to wait for that to start using managed certificates, and it’s impossible for me to obtain all the certificates we are currently using in our deployments (some of them are owned by our customers directly and they manage them, and some are Let’s Encrypt certificates that change on a short timeframe), so making the full switch is effectively impossible.

[Jayden_Platell]

Hi,

Thank you for your question. Unfortunately if you use a variable of the certificate type, Octopus is going to try to resolve that to an actual certificate, regardless of whether it is used in the deployment or not. There isn’t any way around that apart from providing a dummy value as you suggested.

There are ways you might mitigate the risk of that dummy certificate being deployed, such as using extended variable syntax to check that the supplied certificate isn’t the dummy one in the octopus-managed binding.

I did some testing to see if you could use a string variable with the certificate ID (as that is what we actually store in the database for a certificate variable), but during deployment Calamari depends on the resolved certificate to check the local certificate store for an installed certificate with a matching thumbprint, so that was a dead end.

Splitting your process into two separate projects (one for octopus-managed certificates and the other for thumbprints) would solve your issue, but assuming you don’t want to do that I can’t see any other workarounds. Sorry about that .

Regards,
Jayden