Partager via

VSTS/TFS Continuous Deployment to App Service Environment (ASE) after Disabling TLS 1.0

  • Article

If you are a regular reader of my blog, you will have noticed that I have been spending some time working with Azure App Service Environment (ASE). It is available in Azure Government and should be the technology of choice for Government Web Apps. In a previous blog post, I have described how to do CI/CD with ASE, but I have also described and recommended that you disable TLS 1.0 for your ASE. If you have tried to do a Web App Deployment from Visual Studio Team Services (VSTS) or Team Foundation Server (TFS) into an ASE after disabling TLS 1.0, you may have noticed that it fails. The problem is that MSDeploy (running on your build agent) will try to use TLS 1.0 to deploy your application and it will fail. In this blog, I will describe this problem so that you can recognize it and I will also show you how to fix it.

If you deploy an ASE in to a virtual network along with a build agent, you can use that build agent from VSTS or TFS to deploy into a Web App in an ASE. The local build agent is needed since the ASE cannot be seen from the hosted build agents in VSTS. The configuration is described here and it would look something like this:

The JumpBox in the diagram above is only needed to test the setup if you have no other VMs or on-premises machines with access to the virtual network (through VPN or Express Route). If you try to use the agent to deploy without making any modifications to it, you will get an error that looks something like this:

 

 

The specific error text is repeated here:

[plain]
2018-03-23T17:39:21.4813236Z [command]"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:package='C:\agent\_work\r1\a\dotnetcore-example-ASP.NET Core-CI\drop\s.zip' -dest:contentPath='ase-site',ComputerName='https://ase-site.scm.cloudynerd.us:443/msdeploy.axd?site=ase-site',UserName='$ase-site',Password='********',AuthType='Basic' -enableRule:AppOffline -enableRule:DoNotDeleteRule -userAgent:VSTS_94a19df8-3720-4cbc-8661-facce05aa290_release_1_1_1_1
2018-03-23T17:39:21.9926944Z Info: Using ID 'e97b4322-ee2a-4c6c-9777-04582963a0fe' for connections to the remote server.
2018-03-23T17:39:23.2433126Z ##[error]Failed to deploy web package to App Service.
2018-03-23T17:39:23.2435199Z ##[error]Error: Could not complete the request to remote agent URL 'https://ase-site.scm.cloudynerd.us/msdeploy.axd?site=ase-site'.
Error: The underlying connection was closed: An unexpected error occurred on a send.
Error: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
Error: An existing connection was forcibly closed by the remote host
Error count: 1.
[/plain]

The problem is, as indicated above, that msdeploy.exe is trying to use TLS 1.0. You can fix that by forcing the .NET Framework used by msdeploy.exe to use the "Strong Crypto" option. To do this, create a file, e.g. called strong-crypto.reg with the following content:

[plain]
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
[/plain]

Then right-click the file and choose "merge". This modify the registry accordingly. If you then repeat the deployment, you should see a successful completion:

I have published a template for DevOps with ASE, which includes a build agent template. Since the ASE deployed in this scenario has TLS 1.0 disabled, I have modified the configuration of the build agent such that the registry edits are made automatically. This is accomplished in the ConfigureASEBuildAgent.ps1 script. Specifically the lines:

[ps]
Registry StrongCrypto1
{
Ensure = "Present"
Key = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319"
ValueName = "SchUseStrongCrypto"
ValueType = "Dword"
ValueData = "00000001"
}

Registry StrongCrypto2
{
Ensure = "Present"
Key = "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319"
ValueName = "SchUseStrongCrypto"
ValueType = "Dword"
ValueData = "00000001"
}
[/ps]

In conclusion, disabling TLS 1.0 on an ASE will cause automated deployments with msbuild.exe to fail. The solution is to enforce the "Strong Crypto" option and we can achieve that with some registry edits. Let me know if you have questions/comments/suggestions.