Added Ability to encrypt variables with RSA Certificate.

[erothFEI]

Was curious to see if this feature was a viable option to consider adding?

We do this type of thing manually right now with variables that store the encrypted text and it is a pain when updating certificates.

I can flush out the .Net Framework 4.5.2 tests plus additional test cases if needed.

[droyad]

The certificate is not disposed. Also we should think what key set to use and which store. Ephemeral seems to be a good choice in this, but I'm not sure of that.

[erothFEI]

Looks like the Ephemeral key store is not natively availabe in .Net Standard 1.3 or .Net Framework 4.0. It seems to work if I use:new X509Certificate2(Convert.FromBase64String(arguments[0]), (string)null, (X509KeyStorageFlags)32) but I am not confident it would work on a machine that does not have a later version of .Net installed.

[droyad]

This should be inside the catch statement

[erothFEI]

I was just using the FormatFunction as an example for this. Would it be preferable for me to just allow the exception to bubble up?

[CLAassistant]

All committers have signed the CLA.

[NickJosevski]

Thanks for this, and apologies it sat so long without a reply — you answered the review feedback back in 2020 and never heard back, which is not a good experience.

Having gone through it properly now: the problem you described is real, and hand-encrypting values then redoing them on every certificate rotation is genuinely painful. But a template filter turns out to be an awkward vehicle for encryption. Filters fail quietly — a failure leaves the raw #{...} in the output rather than ciphertext — direct RSA caps out at a couple of hundred bytes, and OAEP's randomised output means the result changes on every evaluation, so substituted config files would show a diff on every deployment.

The approach we'd suggest today is doing the encryption in a script step or a step template. That gives you real error handling, lets you use hybrid encryption for anything longer than a short secret, and you can still read the certificate straight out of an Octopus certificate variable — so you keep the rotation benefit you were after.

We are following up on two threads from this: droyad's suggestion in #39 about working from a public key rather than a full certificate, and separately whether this belongs in Octopus Server rather than in Octostache. I will link both here once they are up.