Trouble getting JIRA integration to work - certificate error

(Chris) #1

Hi there,
after updating to the latest Octopus versions we are eager to try the JIRA integration. I’m facing some issues that I need assistance with.

TFS (16.131.27701.1 self hosted) with latest Octopus plugin
Octopus (2019.6.8 self hosted)

Octopus is currently http only, TFS is using https.

During the Push Package Metadata Step I receive the following error:

2019-09-18T09:06:42.4330076Z ##[section]Starting: Push Package Metadata to Octopus
2019-09-18T09:06:42.4334057Z ==============================================================================
2019-09-18T09:06:42.4334266Z Task : Push Package Metadata to Octopus
2019-09-18T09:06:42.4334500Z Description : Collect metadata related to the build, including work items from commit messages, and push to your Octopus Deploy Server.
2019-09-18T09:06:42.4334773Z Version : 4.0.387
2019-09-18T09:06:42.4335004Z Author : Octopus Deploy
2019-09-18T09:06:42.4335209Z Help : Version: 4.0.387. More Information
2019-09-18T09:06:42.4335413Z ==============================================================================
2019-09-18T09:06:43.1992297Z SystemVssConnection exists true
2019-09-18T09:06:43.2398321Z ##[error]Error: unable to get local issuer certificate
2019-09-18T09:06:43.2399998Z ##[error]Failed to push metadata. unable to get local issuer certificate
2019-09-18T09:06:43.2493376Z ##[section]Finishing: Push Package Metadata to Octopus

As mentioned, Octopus is not running https, so I am not sure why this error can occur.

To check general connectivity I tried the following: Pushing metadata directly to Octopus using Octo.exe from the build agent that is performing the above step.

This works fine:

Do you have any idea why the step in TFS could fail? It is worth nothing that the build step contains a NuGet push to the internal package feed using the same “http://octopus” URL and that works perfectly fine.
Looking for any hints here - I have no idea what is going on.

On a side note:
The manually pushed metadata seems to appear in Octopus. This was the metadata I tried sending:

{“Id”:“1”, “Comment”:“TPROG-1 first commit”},
{“Id”:“2”, “Comment”:“TPROG-2 second commit”}


However in Octopus I can see only rudimentary information in the package feed:

And nothing on the release page of a project:
Any ideas why? I was under the impression that the information should then be visible when creating/maintaining a release of the package.

Looking for any hints and ideas.

(Chris) #2

Okay I understand that I need to have a release notes template for displaying information there I guess, but I am missing the commits on the package info site, still.

(Chris) #3

Regarding the certificate error: it seems the metadata plugin is written in/with node.js and I assume that the certificate error is happening in the context of that.

TFS (agent + git) as well as Octopus are in a corporate environment, internet access only via proxy. I have no issues with accessing TFS from the agent.
So either the nodejs part of the extension needs to be made aware of our certificate somehow or some part of the extension cannot be verified by the agent as it cannot access the internet to verify some certificate.

Looking for any ideas on how to proceed.

(Shannon Lewis) #7

Hi Chris,

Thanks for getting in touch. I think that error you are seeing is coming from this code in the plugin.

It is trying to connect back to the TFS server to get the commit details and is finding a SSL certificate it doesn’t trust on that connection. So if you configure the build agent machine to trust the certificate then it should resolve the error.


(Chris) #8

Hi Shannon,

I don’t think it is that simple. The build agent is in the same domain and network as TFS, both having the company root certificate in the local Windows certificate store as trusted root ca (Certificates -> Local Computer -> Trusted Root CA -> Company Certifcate).

Consequently, connecting to TFS with a browser works fine and the the certificate of TFS is shown as trusted. So generally on a Windows level, the machines trust each other.

I believe it is a problem of what application is trying to connect to TFS and where it is getting its certificates from. For example when running an agent + TFS with a company certificate, you have to make that certificate known to git in order to access the sources via git. We did that with a cmd and it worked fine the past years.

The extension you build seems to use node.js and as a complete node.js ignorant I have no idea if node is using the built in cert store of Windows properly.
Seems like it didnt always do it and/or there are options to do that:

So I believe the only remedy is to either ignore all SSL errors within the plugin (I tried this which has no effect:
image ) or somehow point it to the right certificate. I do not believe it is using the windows cert store and I am looking for help on how to either ignore the error (not my preference) or point the plugin/the local node installation of the agent towards the right certificate.

As I have no experience with node I’m hoping you can shed some light on how that works/if it works.
Thanks a bunch,

(Shannon Lewis) #9

The --ignoreSslErrors is a switch to octo.exe, to tell it to ignore errors on the connection to Octopus. I wasn’t aware of this issue with the certificate authorities in Node.

I’ve discussed with the team and we agree this is something that we should address, I’ve created an issue that you can follow on GitHub.


(Chris) #10

Hi Shannon,

thanks for the update - I’ll follow it.

While I agree this would be nice to have and a potential remedy, I am sure that there must be a switch/option/setting within Node to tell it to use certain certificates/certificate stores (see the links in my last post). I assume others will face the same issue in a corporate network and not all may be allowed to switch off SSL errors.

I tried to google how to make node use specific certificates but with as little node knowledge as I have I didn’t get any usable results. I see there are switches for it but I dont know if that has to be done during build or can be adjusted after deployment. Can you guys maybe comment if there should be a way and maybe point me in the right direction?

Thanks a lot,

(Chris) #11

Hi Shannon,

any idea if there is any option currently to add specific certificates to the plugin? I don’t think a general exception is the only or the best solution.