]> Azure DevOps Server, nuget and internal certificate authorities 🌐:aligrant.com

Azure DevOps Server, nuget and internal certificate authorities

Alastair Grant | Tue 12 Mar 2019

Azure DevOps Server 2019 is the new catchy name for Team Foundation Server (TFS).  I'm not sure what acronym can be used as ADS is clearly Active Directory Services.  I'm hearing project managers referring it to simply as Azure, which makes me wince as it's very much on-prem and very much nothing to do with the rest of Azure offerings.  How about DOS...?

Updated TFS installations brings updated bugs.  The latest is the out-of-box NuGet Restore task in Build Pipelines no longer works if you're connecting to an internal TFS feed - well that's where it started out, but it turns out more convoluted than that.

I'm not sure if it's a regression or something that I have only encountered since aDOS has ventured onto the scene.

If you, correctly, use HTTPS for your installation and have your own internal corporate Certificate Authority then the Azure Pipeline Agent program will fail when connecting back with a helpful error:

##[error]Error: Error: unable to verify the first certificate

After much rummaging and playing about this seems to come down to Node.JS, which appears to be running the NuGet tasks.  Specifically Node uses a hard-coded list of Certificate Authorities.  It is worrying that any framework expects to take themselves seriously with this sort of oversight, and the project team's approach of "submit a pull request" is an all-too-common appalling attitude by self-important developers:  If you're releasing a product and want it to be adopted - paid-for or otherwise - you cannot expect sysadmins to start programming patches for your platform, especially in areas such as cryptography and security.

What's the answer to this problem?  The quickest routes are:

  1. Disable SSL and connect in the clear over HTTP
  2. Use a certificate authority that is trusted by Node

Number 1 is hardly best practice, but in an internal corporate network, possible, and potentially catered for by securing the transport by other mechanisms (IPSec etc).

I suspect Number 2 could be approached with a Let's Encrypt certificate, which keeps the costs down, although I haven't verified their CA is trusted.

Neither options are particularly attractive to corporate users.

I have logged this issue with the Azure DevOps Server team, but as the issue is with Node.JS, I don't have high expectations.  I will update this article if I hear anything more on the subject.

Breaking from the voyeuristic norms of the Internet, any comments can be made in private by contacting me.