Trouble getting JIRA integration to work - certificate error

Legacy Execution
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.

Environment:
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.

Issue
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:
image

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:

{
“BuildEnvironment”:“development”,
“CommentParser”:“Jira”,
“BuildNumber”:“1.0.19”,
“BuildUrl”:“test”,
“VcsType”:"",
“VcsRoot”:"",
“VcsCommitNumber”:"",
“Commits”:
[
{“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:
image

And nothing on the release page of a project:
image
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.
Thanks,
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.

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.
Thanks

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.

Regards
Shannon

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,
Chris

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.

Regards
Shannon

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.

Thanks,
Chris

12

Hi Shannon,

I’d be happy to hear back on this. We are really wanting to have the data within Octopus and are fully blocked with this.
Thanks and enjoy the weekend,
Chris

13

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

15

Hi Chris,

My apologies for the very late reply. Neither TFS nor Node make it very obvious how to solve a case like this, and as we’re using the Microsoft TFS client library, we don’t fully control those requests. So we typically recommend either using a globally recognized certificate, or if necessary using HTTP within a limited secured network.

However, I’ve now had some success configuring Node certificates with an environment variable, so I think this approach is worth trying at your end:

  1. Get a copy of the corporate CA certificate (or self-signed certificate if it’s one of those) in PEM format (starting with -----BEGIN CERTIFICATE-----) and put the file on the agent machine.
  2. Edit the system environment variables, and add one called NODE_EXTRA_CA_CERTS with its value set to the PEM file path (which needs to be accessible to the Windows user your agent is running under). The option should work on any Node since v7.3.0; I was trying it on v10.
  3. Open a new command prompt, and use the one-liner below to test if node clients are still rejecting the certificate. Fix the URL at the end of the line to refer to your TFS instance. The end of the URL doesn’t matter much because this won’t get past authentication - we consider this a success if it doesn’t fail on a certificate-related error, and you get a response from the server.
  4. If those requests are getting further than the certificate, restart the agent machine, and it should now be configured and working.

One-liner for testing

> node -e "require('https').get(process.argv[1], resp => { let d = ''; resp.on('data', ch => d += ch); resp.on('end', () => console.log(d)); });" "https://MYHOST/DefaultCollection/MYPROJECT/_apis"

Example output from a certificate error

events.js:174
      throw er; // Unhandled 'error' event
      ^

Error: unable to verify the first certificate
    at TLSSocket.onConnectSecure (_tls_wrap.js:1058:34)
    at TLSSocket.emit (events.js:198:13)
    at TLSSocket._finishInit (_tls_wrap.js:636:8)

Example output if the certificate succeeded (leading to authentication redirect)

The specifics here depend on the authentication configuration, but ours looks like this.


<!DOCTYPE html>
<html>
    <head>
        <title>TF400813: Resource not available for anonymous access. Client authentication required. - Azure DevOps Server</title>
...
[Big HTML page]
...
    </body>
</html>

I hope the above helps to work through this in a more controlled and visible way. Please let me know if the examples don’t make sense, or if there’s anything further I can assist with.

Regards,

David.

1 Like
17

David,

just a quick note: Thank you so much. With your instructions I could get past the SSL error in TFS.
I have not yet had time to verify if everything else works, but the connection is established successfully and something is being pushed. I have not seen it in the GUI yet but I believe that’s just my lack of knowledge and configuration.

Again, thanks a bunch for providing such detailed instructions. Very helpful!
A hint for anyone trying the same: The system variable needs to point to the exact file e.g. “C:\yourfolder\yourCert.cer”. The folder alone did not work for me.

Best,
Chris

1 Like