"unable to verify the first certificate" on first run - Linux - Ubuntu

[rusergeev]

I am trying to install the agent on Ubuntu got an issue:
when running ./run.sh it give me "unable to verify the first certificate"

somebuild@somevm:~$ ./run.sh
Enter alternate username > some user
Enter alternate password >
Enter server url > https://tfs.some.url.com/tfs/
Enter agent name (enter sets somevm)  >
Enter agent pool name (enter sets default)  > some pool
Enter force basic (enter is false)  > true
Error starting the agent
**unable to verify the first certificate**

However my Linux talks SSL with the TFS server: root certificate is in ca-sertificates and the issuing and TFS server certificates are trusted.

somebuild@somevm:~$ openssl s_client -connect tfs.some.url.com:443
CONNECTED(00000003)
...
Secure Renegotiation IS supported
SSL-Session:
    Protocol  : TLSv1
...
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

Any suggestion for troubleshooting?
What exactly could not verify the first certificate?
And what is the first certificate?

I cannot register the agent because of this.

[bryanmacfarlane]

That output is coming out of node.js. A quick search revealed: http://stackoverflow.com/questions/31673587/error-unable-to-verify-the-first-certificate-in-nodejs

[bryanmacfarlane]

Perhaps we need to do the inject call? Will look into it.

[rusergeev]

I cannot install the package ssl-roo-cas to try to inject

someuser@somevm:~/agent/node_modules$ ../runtime/node/bin/npm i ssl-root-cas --save
npm ERR! Linux 4.4.0-21-generic
npm ERR! argv "/home/someuser/agent/runtime/node/bin/node" "/home/someuser/agent/runtime/node/bin/npm" "i" "ssl-root-cas" "--save"
npm ERR! node v5.6.0
npm ERR! npm  v3.6.0

npm ERR! Cannot read property 'target' of null
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>

npm ERR! Please include the following file with any support request:
npm ERR!     /home/someuser/agent/node_modules/npm-debug.log

[andyfisher100]

I'd like to "upvote" the option of adding the inject if this will fix the issue and happy to help with some testing.
We have two TFS app tiers that are load balanced using a Citrix Netscaler and we have put in the work to make this SSL only in order to turn on basic authentication in IIS, for the benefit of cross platform build agents.

We have now added the full chain to the netscaler so that when we make a request to the server the full certificate chain is supplied but we now get the issue of "Message: self signed certificate in certificate chain" when trying to connect to TFS when configuring the build agent.

We used Microsoft active directory certificate services to create a root and intermediate certificate and then created the server certificate afterwards.
There is no reason why the cross platform build agent or TFS CLI (Happens on windows with this app too) would trust these certificates when connecting which is as expected, but there is no way to tell the applications to trust these certificates.

It basically means if you configure SSL with a self signed certificate chain, you cannot use the cross platform build agent or the TFS command line to upload custom build tasks. This is a huge blocker for us.

[bryanmacfarlane]

Can you try the new agent that is replacing this one? https://github.com/Microsoft/vsts-agent

[rusergeev]

Yes, I tried two previews.
I will do the new 2.101 as well. Thanks for letting me know.

[andyfisher100]

Tried this on a Mac running OS X Yosemite and v2.101.0 Preview

I hit a problem running the agent as a service. The failure was that the Library directory for my user account does not have a sub directory called LaunchAgents. The LaunchAgent folder is a sub directory of the root Library folder.

Enter run agent as service? (Y/N) (press enter for N) > y
Creating launch agent in /Users/Andy/Library/LaunchAgents/vsts.agent.livetfs.apwasu34.plist
Failed: /Users/Andy/Library/LaunchAgents does not exist. OSX system dir expected

As a workaround i created a LaunchAgents directory in /Users/Andy/Library/ and the service started, successfully authenticating using negotiate over HTTPS.

I created a new build definition for a TFSGit repo to run a hello world shell script which queued and ran without any issues. My only comment here would be that some lines of the build output log, in TFS web access, are impossible to read as they are in an aqua colour. Example of two lines below that where in aqua colour.

2016-05-26T15:46:04.9091290Z ##[command]git config gc.auto 0
2016-05-26T15:46:05.0241920Z ##[command]git -c http.extraheader="AUTHORIZATION: bearer ********" fetch --tags --prune --progress origin

Finally, I just noticed what looks like a hardcoded value in the build log:

2016-05-26T15:46:04.6943450Z warning: templates not found /Users/stiliev/projects/gitwinout//share/git-core/templates

I will raise these issues on the github page for thew new agent. Keep up the good work!

[rusergeev]

I tried the new agent Preview 5 v2.101.0 on Ubuntu.(https://github.com/Microsoft/vsts-agent)

Enter run agent as service? (Y/N) (press enter for N) > y
Never worked

However my problem persists: when schedule a build:

Starting: Build
API resource location 60aac929-f0cd-4bc8-9ce4-6b30e8f1b1bd is not registered on https://tfs.company.com/tfs/COLLECTION1/.
Finishing: Build

[bryanmacfarlane]

You'll have to provide more info then Y.

1. I need all your answers during config. After that, we can look at the trace log @ _diag.
2. Run interactive first to troubleshoot, then as a service
3. Log an issue at vsts-agent, not here

[ericsciple]

@rusergeev make sure you configured the agent against the server url https://tfs.company.com/tfs, and not the collection url https://tfs.company.com/tfs/COLLECTION1

[rusergeev]

@ericsciple, I registered against http://tfs.company.com/tfs, that is an error message, which also display COLLECTION1.

My projects in this COLLECTION1, which is out of my control.
My company.com dictates that.

[rusergeev]

Anyway, we got the first sertificate solved by adding full certificate chain to trusted certificates.