Octo.cmd failed with return code: 4294967295

Hi There,
I am getting the below error whilst creating the release step in TFS. It is only happening for this project other one is looking good[No issue in the create release step]

Hi Krishna,

Thanks for reaching out and helping us improve Octopus.

It looks like the build failure is caused by the Octopus server’s SSL certificate being rejected by the TFS extension during a direct API request. Although your Octo.exe command line has --ignoreSslErrors added already, direct API requests would only do the same if the Service Connection to Octopus had “Ignore SSL Errors” checked, so please review that setting.

Of course, another option is to solve the SSL errors by using a current and matching certificate, with its Certificate Authority added to the Windows certificate store on the agent machine if necessary. One way to test this would be to run Chrome or Edge on the agent machine and browse to the Octopus server, and confirm that no certificate warnings are displayed.

It’s interesting that the succeeding build isn’t attempting to make the fatal request. This might be due to something like the build configuration YAML containing a project name instead of an id, so it isn’t needing to look it up.

As a side note, it also appears that some API requests to the TFS server are failing due to its SSL certificate, as well. As far as I know this isn’t fatal, but it will interfere with features like release notes, and I don’t think there is any ignore switch for that connection.

Please let me know if you run into any more issues. We will look into revising the way our extension responds to those errors, at least to make the logs a bit clearer.

David Young.

Hi David,
Thanks for the info. We have fixed the https certificate issue but, we still get the same error. Please check the attached “create octopus release” step from successful and failed projects.

I tried to run the Octo.cmd from the command line with necessary params. It worked without any issues.

Success Proj


In the failed, it is not fetching the project name. Check the highlighted.

Hi Krishna,

Thanks for the update.

That message still indicates some kind of HTTPS certificate issue persists. If the certificate is working elsewhere, the problem might be specific to the TFS extension node scripts. I think we should try to narrow it down:

(1) Windows client certificate store

You mentioned success running octo.exe by itself. Is that working without --ignoreSslErrors?

If not, please run certlm.msc and make sure the Certificate Authority that signed your Octopus Server certificate has an entry under “Trusted Root Certification Authorities”.

If that seems right but it’s still not working, could you visit the Octopus Server in Chrome or Edge and check whether there’s an address bar warning with a more detailed error message?

(2) Node certificate store

If the above are working but the TFS extension continues to report the certificate error message, it might be using node’s certificate store rather than Windows’ store, which can happen in some versions.

If that store is being used, and it doesn’t trust your signing Certificate Authority, you might need to export its certificate to a file, and feed it to node using the NODE_EXTRA_CA_CERTS system environment variable or the NODE.EXTRA.CA.CERTS pipeline variable. This is described in more detail here and here.

I hope those steps can help narrow it down. If you are still having problems, please let me know the outcomes of these steps, and attach the current build log and both build configuration YAMLs from TFS.

David Young.

Hi David
Thanks for the support.
finally it worked. --ignoreSslErrors command was not working through Octo.exe in the create release package step but it worked after configuring the ignoresslerrors in the service endpoint configuration in VSTS as shown in the pic below.

Hi Krishna.

Glad to hear you’re up and running again. Please reach out if you run into any more problems.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.