Open SandeepKantamneni opened 2 years ago
Am too having this problem. Thanks for raising the issue.
Needs more context:
This looks to have sorted itself out.
Issue is back. I think it's the TLS deprecation.
Was able to fix it with registry edits on our build server and a reboot.
https://devblogs.microsoft.com/devops/deprecating-weak-cryptographic-standards-tls-1-0-and-1-1-in-azure-devops-services/#quick-check-of-tls-1-2-compatibility This contains a one-liner check, and a link to a ps1 file for more checks.
Issue is back. I think it's the TLS deprecation.
Was able to fix it with registry edits on our build server and a reboot.
https://devblogs.microsoft.com/devops/deprecating-weak-cryptographic-standards-tls-1-0-and-1-1-in-azure-devops-services/#quick-check-of-tls-1-2-compatibility This contains a one-liner check, and a link to a ps1 file for more checks.
Thanks David, I can confirm this was the solve for me too.
I had a quick scan of the scripts, they seem to be all PowerShell based. My build servers are PowerShell 5.1 using .NET 4.0. The mitigations specifically targets .NET 4.0, so this is probably what is going on.
I found the following useful to force TLS 1.2 for .Net frameworks, under section 'Configure for strong cryptography':
https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/security/enable-tls-1-2-client
Basically, its just adding two registry properties to whatever .Net framework packages you are using:
Since I am using docker build agents, it needed to be scripted.
These PowerShell commands did the trick - there were more versions than just the following two:
New-ItemProperty -Path Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\ -Name SystemDefaultTlsVersions -Value 0000001 -Type dword
New-ItemProperty -Path Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\ -Name SchUseStrongCrypto -Value 0000001 -Type dword
and so on...
You will need to customise the paths to the frameworks that you have installed on your build agent.
Also don't forget about any under the WOW6432Node nodes.
Hope this helps someone.
Does this task work with out TLS 1.0 and 1.1 ?
Exception System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm at System.Net.SSPIWrapper.AcquireCredentialsHandle(SSPIInterface SecModule, String package, CredentialUse intent, SecureCredential scc) at System.Net.Security.SecureChannel.AcquireCredentialsHandle(CredentialUse credUsage, SecureCredential& secureCredential) at System.Net.Security.SecureChannel.AcquireCredentialsHandle(CredentialUse credUsage, X509Certificate2 selectedCert, Flags flags) at System.Net.Security.SecureChannel.AcquireClientCredentials(Byte[]& thumbPrint) at System.Net.Security.SecureChannel.GenerateToken(Byte[] input, Int32 offset, Int32 count, Byte[]& output) at System.Net.Security.SecureChannel.NextMessage(Byte[] incoming, Int32 offset, Int32 count) at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)