I’ve just updated with a new Certificate in my Library. I’ve modified the Variables to use the new Certificate.
When pushing a new release I’m getting:
OperationStopped: Could not find certificate under Cert:\LocalMachine with thumbprint XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX. Make sure that the certificate is installed to the Local Machine context and that the private key is available.
I don’t recall having to pre-install the Certificate on the target machine before, did I miss a setting? I do have the Bindings step selected for “Certificate managed by Octopus”, which I thought meant it would install a new Certificate, so why is it searching for the new Cert on the target machine at all?
First, welcome to the Octopus community and thanks for posting your issue!
That’s strange the deployment process seems to be looking for the cert locally but can’t seem to find it. I’m not sure what might cause this yet, but I was wondering if you’d be willing to send me the Task Log from your last failed deployment with the above error, as well as a JSON export of your process? You can use the following link to upload these to me securely: Support - Octopus Deploy
Once I have the above, I should be able to get a better idea on what might be causing this.
Thanks for the prompt response! I’ve uploaded both requested files.
To be more clear - the cert in question is new because the original cert is expiring. I just thought the new cert would automatically get installed on the target machine rather than Octopus looking for it. There’s no mystery why it’s not finding it - the new cert hasn’t been deployed yet. I just didn’t think I had to run around to all my target machines and manually load a new cert. I could have sworn Octopus does the installing during deployment.
Thanks for sending through the deployment task log and the JSON process.
It looks like Octopus determines that during the deployment the certificate already exists in the store. I’ve redacted the information from your actual certificate, but you’ll see on lines 461 and 462 of the task log something that looks like the following:
17:09:04 Info | Adding certificate '[redacted cert details]' into Cert:\LocalMachine\My
17:09:04 Info | Certificate '[redacted cert details]' already exists in store 'My'.
We’ve seen this occurring in the past when the Octopus doesn’t have enough permissions to see/manage the existing certificate within that store. Most commonly, this is caused by a certificate being installed manually and not managed by Octopus.
I see that you currently have your Deploy to IIS step configured to use a certificate managed by Octopus for the https binding, but is it possible the ‘Certificate managed externally’ option under the https binding for the site in the IIS step was used in the past?
Regardless, you might need to try moving the old/expiring certificate to a different store or removing it from the machine if you have it backed up elsewhere, and then retry the deployment to see if that allows it to work. If it does, this process should start working as expected in that you won’t need to do any certificate manipulation on the target machine since it will be managed by Octopus.
When you refer to moving the cert to a different store/removing it from the machine - are you referring to the target machine or the Octopus Library where I currently have both certs?
I went onto one of the target machines (I have quite a few, which is why I’m trying to manage this from the Octopus server side) and I can see the new cert in the Personal Certificate store on the target machine!
That just makes me more mystified now.
One important difference - the original cert has a private key associated with it. This new cert does not. Could that be making a difference?
Thanks for getting back to me with those details, and I’m sorry I wasn’t clear on which machine to remove the old cert from.
I believe Octopus may be trying to remove the old cert from the target machine store since the deployment process tells Octopus the old certificate is managed by it. I’m not quite sure on this process, but it’s possible Octopus first installs the new certificate and fails when it goes to remove the old one.
When Octopus goes to bind the certificate later in the process, it’s looking for the cert details (redacted above) and finding the old one with a different thumbprint. You might try just removing the old cert from just one target to see if it works as a test.
I don’t think the private key should matter here, but that’s helpful to know in case it’s still not working.
Let me know if that helps clear things up, otherwise I’ll continue troubleshooting with you to get this working as expected.
For the sake of completing this issue, I was able to get it to work by exporting the key with its private key, password protected, and then importing that into the Octopus Library as the cert to use. That did the trick and now it’s successfully installing on the target machine.
It’s very helpful to know the private key was the culprit here. Thanks for sharing the fix, and in case anyone else runs into this issue they’ll be able to see the solution.