TFS On Premise Build Agent - Could not establish trust relationship for the SSL/TLS secure channel

1
votes

I have setup one TFS On-Premise Build Agent as a service using the instructions listed here. I setup the accompanying Agent pool, permissions, build controller, etc.. and worked through most of the setup challenges around getting the agent to connect and run. I now have a agent that is connected and able to run builds:

enter image description here enter image description here

My configuration looks something like this:

"settings.json" - "ServerURL": http://tfs.XXXXXXXXX.com:80/tfs

"Listen for Build Agent communication on:" http://XXXXXXXXXXX.com:9191/Build/v5.0/Services

But when I try to run any build using my newly configured Agent Pool it always fails when an entry in the Agent's log:

System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

The Agent failed to start this job. Error: An error occurred while sending the request.

This is very confusing to me because nowhere in my TFS configuration am I using SSL. How would it fail on a bad certificate(in this case self-signed) if I'm not using port 443 to connect to it. When I connect through a web browser(firefox) to that location I'm not automatically redirected to "https". Is the agent somehow being redirected? Again, I'm able to connect without issue(or failing certificate) to the listed URLs, but It seems for some reasons the agent is not.

I'm not sure if I'm the only one who's got this issue. I think this is related, but not the same version of software. There's a million other references to this error message, but I don't see a single one with the same context or configuration. Has anyone ever seen this issue before?

1
.netxamlssltfstfsbuild
What is the TFS Server's Notification Uri in the administrative panel of the server? If it's set to the https location, the Build agent will be redirected there after initial connection. Adding the self signed server certificate to the trusted root certificate's store in Windows should allow the Build Agent to authenticate. – jessehouwing
Ah yes, you are correct, it is "https". Also on the second suggestion I think your broadly correct, but the details of that change where substantially more complicated than it first seemed. Though that really lies outside of the scope of this questions. I think changing that "Notification URL" is likely the easiest solution for anyone else. – David Rogers

1 Answers

2
votes

The Team Foundation Server itself has a setting called the Notification Uri, whenever anything asks where it can find stuff it will use this Uri to send back the location.

In you case the build server wants to know all kinds of things, download source code, the build process template, upload test results etc. When asking where to grab these from or send these to, TFS will respond with that Notification Uri.

Your server is configured to use a self-signed SSL certificate, the server is configured to send back the secure location through it's notification Uri property, thus your client needs to build a trust relation to establish the communication.

There are three solutions:

  1. install a trusted certificate on the TFS server (in case you're in an active dircetory setup, this may not be as hard as it seems).
  2. install the self-signed certificate in the trusted root certificate store of each windows computer connecting to the TFS server
  3. Turn of SSL on your TFS server by removing the cert from the IIS binding and reconfiguring the server and notification URI.

Note: disabling SSL may introduce holes in your security setup depending on how authentication is configured. If you server accepts basic auth, or when you upgrade to TFS2017 and activate support for Personal Access Tokens, your authentication token may be sent over the wire in clear text.