SSL authentication errors when using with On-Prem TFS

[andyfisher100]

This tool has the same issue as the cross platform build agent when it comes to authenticating correctly to an on-prem TFS server using SSL.

As we know you can only authenticate to on-prem TFS using basic authentication but as a result you MUST enable SSL so that all traffic is encrypted. Obviously to enable SSL you need to get a certificate for the TFS App-Tier in IIS and these can be either from a vendor such as Symantec or you could create one using something like Microsoft Active directory certificate services (which is what we did).

We set everything up and can access the TFS via all common web browsers without any issues, as long as the root and intermediate certificates have been installed correctly, for example in the trusted roots folder in windows cert manager.

However when you try to authenticate using "--autht-type basic", the application will not accept the certificate handshake because it cant read from the certificate store so there is no reason as to why the certificate should be accepted as it could theoretically be from anywhere. However, we don't have any way to tell the application that the root or intermediates certificates should be trusted.

This has been raised multiple time on the xplat agent github page and on this issue Bryan Macfarlane suggested making use of a NPM package called "ssl-root-cas"

As a result of these SSL issues, we cant use either the xplat agent or the TFS CLI.

[bryanmacfarlane]

We should fix this.

[borland]

Encoutering this too.

We have an on-premise TFS server, and have set it up to use HTTPS so we can safely use basic auth. We have an organization Root CA which is trusted by all the workstations on our domain (the Root CA is pushed out by group policy)

We set it up explicitly this way because those are the Microsoft guidelines as recommended for using Basic auth with TFS, and also what the tfs-cli and xplat agents recommend. It was quite disheartening to see that the recommended solution doesn't actually work due to this error.

The TFS CLI (and xplat agent) don't trust our cert because of Node's ridiculous hardcoded CA list ( nodejs/node#4175 )

The specific error that comes up when you run TFX is "Message: Unable to verify the first certificate"

To work around it, I used the 'ssl-root-cas' node module. Unfortunately this was not easy. I needed to do the following:

1. Export the organization CA as a base64 encoded x509 cert - I put it in the tfs-cli module itself at %APPDATA%\npm\node_modules\tfx-cli_build\app\organization_ca.cer
2. npm install --global the 'ssl-root-cas' module
3. Edit the app.js under %APPDATA%\npm\node_modules\tfx-cli_build\app and insert the following:

// hack to enable custom certs
require('ssl-root-cas')
.inject();
.addFile(__dirname + '/organization_ca.cer');

This works, but having to manually hack up the tfs cli packages (and xplat agent) on every machine that needs it is a terrible idea.

If tfx and the xplat agent could have some kind of config option - either environment variable or command line based - to add additional trusted certificates (either a CA or the direct cert itself) that would solve the issue.

[brettjacobson]

@bryanmacfarlane any update on this issue? I think its existed since December
#63

[mkopinsky]

Not sure if this will solve your problem, but node >=6.6 should use the system CAs rather than bundled ones. nodejs/node#8334

[tbolon]

Hello,

We have switch our onprem devops server to only allow https, with a certificate installed in our system CAs.

We used pat, but now that we only allow HTTPS, the tfx client fail with a certificate error.

@mkopinsky If I read your link well, it seems node still use bundled CAs until you compile node with a special argument, or use the parameter --use-openssl-ca at runtime. Did tfx ever added this parameter?

[borland]

There’s a NODE_EXTRA_CA_CERTS environment variable that you can set to the path of a cert file for your custom on-prem azure devops server cert, it should let TFX talk to your server without having to touch anything else. It also works for configuring Azure DevOps build agents