Kari_OTS_logs_20734.zip (12.3 KB)
Hi Kari,
Thanks for meeting with me today, just a quick summary of the conversation and proposed next steps.
- You demonstrated your TFS build definition setup and Octopus Project configuration.
- We attempted a build using the non-Legacy method and version 4 but received an SSL error: Error: unable to get local issuer certificate.
- You then showed a working example using the Legacy method and version 2 which succeeded.
- Finally we attempted a build with the Legacy method and version 4 which passed but failed to show the correct information in Octopus.
Next Steps:
- I’ll investigate the certificate issue and the recommended steps to resolve this. It appears most likely to be caused by the Intermediate CA but I will confirm.
- I will review the logs of the failed build and reach out to the engineers for input.
Apologies for not requesting this during the call, would you be able to please also send through the build logs for that successful run? (using the Legacy method with version 2).
I’ll keep you posted with any updates or suggestions, feel free to let me know if you have any questions or any of the above isn’t correct.
Best Regards,
Hi Kari,
Thanks for sending that through, confirming that I have received it ok. Hope you had a nice dinner with your son!
I’ve requested assistance from the devs regarding the issue that is appearing for version 4:
An exception was thrown while building the release notes.
{ Error: unable to get local issuer certificate
at Error (native)
at TLSSocket.<anonymous> (_tls_wrap.js:1092:38)
at emitNone (events.js:86:13)
at TLSSocket.emit (events.js:185:7)
at TLSSocket._finishInit (_tls_wrap.js:609:8)
at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:439:38) code: 'UNABLE_TO_GET_ISSUER_CERT_LOCALLY' }
See "https://github.com/OctopusDeploy/OctoTFS/issues/107 for more details."
I’ll keep you posted with any updates or suggested actions, looking forward to getting this resolved!
Best Regards,
Hi Kari,
Just an update. The devs are looking into this and would like to rule out any potential TLS issues, as both the warning: Use Cipheriv for counter mode of aes-256-ctr as well as the error Error: unable to get local issuer certificate indicate TLS.
Also the issue mentioned in the logs doesn’t seem to match the error you are seeing and so we think this is misleading, rather than indicative of what’s going on.
Our recommended next steps:
- Run this Azure script for confirming TLS readiness along with IISCrypto to make any required changes to be TLS ready (this comes into effect permanently on the 30th March).
- Update the Octopus TFS plugin to version 5. This version comes with a bunch of improvements and deprecates the Octopus Pack task and so it will require some reconfiguration of the Package build steps to use another library for packaging the files.
Let me know how you get on or if you have any questions!
Best Regards,
Thanks, Finnian. I will need to get a test environment set up to run the script. We are currently moving to a high-availability mode and our test env is in a bit of flux at the moment.
For the Octopus plug-in to version 5, I don’t think that is high risk and can probably be installed directly in our prod env. I’ll work on getting that done tonight.
Thanks!
Regarding this… it looks to be an Azure DevOps update. We are TFS2018 - is the version 5 available with TFS 2018?
Hi Kari,
No problem at all, let me know if you have any questions setting up your test env!
The Azure Devops plugin version 5 is available for TFS 2018, you should be able to navigate to it in the marketplace to install it but let me know if that doesn’t work. It does come with some significant changes, most important is that it is no longer bundled with the OctoCLI and so any ‘Octo Pack’ steps will need to be changed to another package ‘packing’ step, such as npm pack. I’ll test the upgrade path on my local reproduction to confirm what changes will be required!
I actually believe I have reproduced the issue! It seems that when I launch a build using a specific commit message as you were doing during the call, I wasn’t able to get my release notes to be present.
Are you able to please test queuing a new build using the git cli and confirming if you have any issues? (presuming you have your builds triggered from a commit)
e.g. git commit -m "Fixes #7 test commit"
I’ll keep exploring this and let you know if I have any updates!
Best Regards,
Thank Finnegan. Our test environment is working now. I will get the newest plugins installed. I will aslo need to get git installed. Pun intended.
2 Likes
Hi Finnegan,
Wow, this has gone on for months now. Perhaps we are close.
I will not be installing git as our developers do not use cli git but visual studio. They do commits by pushing into TFS which is a git repository. As a DevOps engineer, i can commit directly in TFS.
We do not use any OctoPack steps but we do use “Package Application for Octopus”. I am hoping we can get this to work without using npm pack which requires a package.json for each step. Creating package.json for all our projects would take longer than having our project managers identify work items manually.
I download the updated plugins and changed steps to Version 5. This version required a new TFS build Agent version of 2.1.44 which I downloaded and installed. Now get an error that TFS Build Agents needs to have a capability of octo Please let me know where to download this module to our build agents.
Please advise. Let’s set up another meeting and see if we can bring this to resolution please.
Hi Kari,
I really appreciate your patience, I feel we are very close to resolving this and one more call should do it!
I’m sorry for all the headaches and confusion with these latest changes, it’s definitely outlined areas we need to improve, such as listing any major changes publicly which can now be found at: https://github.com/OctopusDeploy/OctoTFS/releases.
I have just met with the developers, going over the entire process and we have raised an issue with the Plugin, which will prevent you from using the new “Push Package Build Information” step for your Build Information as we were suggesting. They are looking into resolving this and I’ll let you know when it’s fixed.
In the meantime, you will need to use the Legacy method, where the work items are included in the Release.
I’d be happy to run through your configuration and make sure it’s all correct and the right info is coming through, you should be able to use the same link to schedule a call: GoodTime - Let's find a good time to meet!
Let me know if the times aren’t suitable or there are any issues with it at all. Looking forward to meeting again and getting this resolved!
Best Regards,
Hi Kari,
I just noticed while checking the logs that “Ignore SSL: false”. Could you please double check if this i enabled and whether changing it resolves the issue?
I’ll keep exploring and keep you posted with any more findings.
Best Regards,
Hi Kari,
I found this issue which I believe describes what’s going on with node:
TLDR: Corporate Firewall/Proxy - Most likely a TLS certificate in the chain is signed by an unknown CA, likely the cert your proxy uses.
Secure Options to Resolve:
export NODE_EXTRA_CA_CERTS=/path/to/your/CA/cert.pem (This can just be a Pipeline variable)
npm config set cafile=/path/to/your/CA/cert.pem
Another option for resolving this is covered in this blog, where they suggest using git config --global http.sslCAInfo C:/Users/username/ca-bundle.crt
Another option could be to force node to use the openssl config with the node runtime option --use-openssl-ca although I’m not sure if this is considered secure or not.
Insecure Options for testing only:
npm config set strict-ssl false
export NODE_TLS_REJECT_UNAUTHORIZED=0
git config --global http.sslVerify false
Looking forward to the meeting tomorrow and getting this resolved!
Best Regards,
Hi Kari,
Just a quick update with a reply from the developers.
They have said that the error appears to be indicating that the build agent is trying to communicate to the TFS server, however the required certificate to do this isn’t trusted for some reason.
We can tell that the SSL connection to Octopus is working ok as the logs are showing it connecting successfully and only reason for the error from Octopus is the wrong package name due to the node error received:
Handshaking with Octopus Server: https://ots-corp-oct18.open-techs.local/
GET https://ots-corp-oct18.open-techs.local/api
Handshake successful. Octopus version: 2021.3.8275; API version: 3.0.0
GET https://ots-corp-oct18.open-techs.local/api/Spaces-1
GET https://ots-corp-oct18.open-techs.local/api/users/me
Authenticated as: SRVTFSBLD (a service account)
Found environments:
This Octopus Server supports channels
GET https://ots-corp-oct18.open-techs.local/api/Spaces-1/projects?name=Error%3A unable to get local issuer certificate
While there is an issue for us to look into with the release not being created, that won’t resolve the issue for the work items not being included.
I noticed your initial request mentioned that version 2 of the ‘Create Octopus a Release’ build step was working, could you please test that version with the current configuration and sending through the build logs?
Best Regards,
Hi Kari,
Just an update from the Developers who have confirmed what’s changed between versions 2 & 3 of this plugin that could be causing this error.
Essentially the changes in version 3 include a transition from Powershell to TypeScript for each of the Build Steps and this is likely causing you to experience the NodeJS issue I linked earlier.
To try to resolve this issue, could you please try the following:
-
Confirm the TFS server certificate is installed on the build agent. I would suggest adding another line in the build agent configuration similar to how the Octopus certificate is configured.
-
Try running
npm config set strict-ssl falseorexport NODE_TLS_REJECT_UNAUTHORIZED=0(or both) to try to bypass any SSL errors. This is similar togit config --global http.sslVerify falsewhich is already configured.
I’d be happy to jump into another call to try get this working again now that I am confident in the issue and the use of Node. Let me know how you get on or if you have any questions!
Best Regards,
Hi Finn,
Did this ever get put into an actual bug that will get deployed soon?
Thanks,
Kari
Hi Kari,
The engineers confirmed that the change between version 2 of the plugin and versions 3+ was a transition from Powershell to Typescript for each of the build steps and so Node is now being used.
They don’t believe there is a bug to raise with the Octopus Plugin but rather that the issue preventing you from acquiring your local issuer certificate is the Node issue I linked previously which outlines problems with corporate proxies. I found a StackOverflow post which has a bunch of interest points and discussion around users getting node install working behind a proxy.
Are you able to run node commands that should use the proxy such as node install ok?
I would recommend you try the following to resolve the issue:
-
Confirm the TFS server certificate is installed on the build agent - I would suggest adding another line in the build agent configuration similar to how I saw the Octopus certificate was configured. I believe this comment on the issue outlines how to do so.
-
Run the command
npm config set strict-ssl falseorexport NODE_TLS_REJECT_UNAUTHORIZED=0(or both) to try to bypass any SSL errors. These commands are similar togit config --global http.sslVerify falsewhich I noticed was already configured.
Feel free to let me know if you have any questions!
Best Regards,
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.