Deprecating weak cryptographic standards (TLS 1.0 and 1.1) in Azure DevOps Services
Update (October 2022): Deprecation of weak cryptographic protocols has completed.
Deprecation of TLS 1.0 and 1.1 has completed for the dev.azure.com and *.visualstudio.com domains – all HTTPS connections to Azure DevOps for these domains now use TLS 1.2.
Azure DevOps team needed to partially rollback the previous release of TLS 1.0/1.1 deprecation that was run on Jan 31st, 2022. This was due to unexpected issues caused by the change. Here’s a link to the previous blog post related to that release.
TLS 1.0/1.1 deprecation applies to all HTTPS connections to Azure DevOps Services including web API, and git connections to https://dev.azure.com/orgname and https://orgname.visualstudio.com. This does not apply and will not impact the Self-Hosted product: Azure DevOps Server.
Currently, connections to IPv6 endpoints of our services are already on enforced TLS 1.2 so the deprecation is targeting IPv4 endpoints only.
We anticipate minimal impacts to our customers as more than 99.5% of connections made to Azure DevOps Services already use TLS 1.2. Clients have TLS 1.2-compatibility issues because of obsolete OS version or if available updates are not applied (applies for all Windows, macOS and Linux) or legacy .NET Framework installation or OS configuration prohibiting certain TLS cipher suites.
Important Dates
To help our customers identify Azure DevOps-facing TLS 1.2-incompatible software in their systems, we will temporarily disable support for TLS 1.0/1.1 for 12 hours on:
-
March 22, 2022 09:00 to 21:00 UTC for https://orgname.visualstudio.com. TLS 1.0/1.1 connections to Azure DevOps Services using https://orgname.visualstudio.com will temporarily fail to connect. Connections using https://dev.azure.com on TLS 1.0/1.1 will not be impacted.
-
March 24, 2022 09:00 to 21:00 UTC for https://dev.azure.com/orgname. TLS 1.0/1.1 connections to Azure DevOps Services using https://dev.azure.com/orgname will temporarily fail to connect. Connections using https://orgname.visualstudio.com on TLS 1.0/1.1 will not be impacted.
We will be starting permanent rollout from March 31, 2022
How to enable TLS 1.2?
As a key area of focus we recommend Self-Hosted Agents and tooling that calls Azure DevOps Services APIs.
Check these red flags first when looking for TLS 1.2-incompatible flows: – Windows Server 2012 R2 or lower used – .NET Framework 4.7+ not installed on computer where PowerShell or .NET applications call Azure DevOps API
It is key that on the OS one of the four TLS 1.2 cipher suites below is enabled:
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (*)
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (*)
NOTE: (*) Cipher suites supported by Windows Server 2012 R2
Quick check of TLS 1.2 compatibility
Following checks are based on querying site status.dev.azure.com. For this domain, the TLS 1.0/1.1 protocols have already been deprecated. Note that checking accessibility of this domain by browser instead of PowerShell is not equivalent. Browsers often use crypto libraries (such as OpenSSL) and thus circumvent the classic HTTP/TLS stack that other software uses.
Manual PowerShell
Run this code in PowerShell console:
(Invoke-WebRequest -Uri status.dev.azure.com -UseBasicParsing).StatusDescription
You have the problem if the above fails with “The underlying connection was closed: An unexpected error occurred on a send.”
YAML
To check your pipeline agents: create testing pipeline OR add this step to existing pipelines:
steps:
- task: AzurePowerShell@5
inputs:
ScriptType: 'InlineScript'
Inline: '"TLS 1.2 readiness check:"; (Invoke-WebRequest -Uri status.dev.azure.com -UseBasicParsing).StatusDescription'
FailOnStandardError: true
Pipeline task
This shows a release pipeline task that can be added to perform a check for TLS 1.2 readiness on your Self-Hosted Agents. If the check fails, the task will throw an error that can be actioned.
Troubleshooting
For Windows OS, TLS 1.2 is natively supported by all versions from Windows 7 / Windows Server 2008 SP2. However, even at TLS 1.2-compatible OS, issues may be caused by misconfigurations such as when all cipher suites accepted by Azure DevOps are disabled. This may be set up locally or via domain Group Policies.
At application level, capabilities provided by the OS may be narrowed down making the app to use less secure TLS setting. For example, .NET apps which are built against legacy .NET Framework versions may require certain measures to be taken to ensure that TLS 1.2 is favoured.
Based on learnings from supporting our customers, we’ve put together a troubleshooting script which performs TLS 1.2 probe, identifies most common misconfigurations and provides mitigation advice.
You can find the script on GitHub:
https://github.com/microsoft/azure-devops-tls12
The project is work in progress; feel free to contribute with PR or open an issue.
Conclusion
We apologize for any disruption this may cause and appreciate your support to improve our security posture. As always, if you have any questions or concerns related to this announcement, please do not hesitate to reach out to us on Developer Community or by posting your comments below.
Light
Dark
87 comments
Unable to connect today with https://dev.azure.com/orgname
Please clarify what kind of software cannot connect.
As an example: some auth, licensing and account management flows of Visual Studio have API calls against visualstudio.com. So today’s temporary change may cause an impact even if your org uses dev.azure.com.
Please run the readiness checker script on the affected computer. Hope it helps!
Our tests are failing with following error today.
_tasks\VSTest_ef087383-ee5e-42c7-9a53-ab56c98420f9\2.198.0\Modules\DTAExecutionHost.exe’ failed with exit code 3762504530
TestExecution encountered unexpected failures System.Net.Http.HttpRequestException: An error occurred while sending the request. —> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. —> System.IO.IOException: Authentication failed because the remote party has closed the transport stream.
Task details:
VSTest Task version 2*
Agent running on Windows server 2012 R2. Cipher suites are already updated.
Hello
We have windows 2008 r2 server and the connection works on one 2008 server but not on the 2008 server.
Our tests are failing with following error today.
An error occurred while sending the request. —> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send.
We also installed .NET framework 4.8 but still it does not work.
Hi Chirag & MK,
could you please run TLS 1.2 readiness checker script at the affected servers/agents (directly or as a powershell task within a pipeline) and see if it helps with localisation of the issue?
Windows Server 2012 R2 and older are especially vulnerable to cipher suite incompatibilities. Out of four TLS 1.2 cipher suites that Azure DevOps supports, only two are supported by these versions of OS. So it is good to check if the OS does not have cipher-suite disablements on those two (locally-enforced or by group policy). This is one of things that the readiness checker looks on.
Re We also installed .NET framework 4.8 but still it does not work.: please keep in mind that for applications targetting legacy .NET versions it is not neccessarilly sufficient to install new .NET Framework version. Certain registry changes are needed. Please refer in these docs.
Additional links that can be of value here:
– https://support.microsoft.com/en-us/topic/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-winhttp-in-windows-c4bd73d2-31d7-761e-0178-11268bb10392
– https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-tls-enforcement
here is the result for readiness checker
Windows PowerShell
Copyright (C) 2012 Microsoft Corporation. All rights reserved.
PS C:\Users\cshah_master> cd C:\Tlschanges1.2March2022\azure-devops-tls12-main
PS C:\Tlschanges1.2March2022\azure-devops-tls12-main> ./AzureDevOpsTls12Analysis.ps1
| Probing Azure DevOps sites |
Probing: status.dev.azure.com
ISSUE FOUND: This may be TLS compatibility issue!
Probe failed when TLS-negotiating to Error: Unable to read data from the transport connection: An exis
ting connection was forcibly closed by the remote host.
| Analysis of TLS 1.2 compatibility: OS |
PS Version: 3.0
PS Edition:
Win Build Version: 6.1.7601.65536
CLR Version: 4.0.30319.42000
Skipping Get-TlsCipherSuite due to version of OS lower than WS 2016
TLS 1.2 client usage enabled.
Allowed required cipher suites per local: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Missing required cipher suites per local: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Allowed required cipher suites per GP:
Disabled required cipher suites per GP:
At least one of the TLS 1.2 cipher suites required by Azure DevOps enabled on the machine (by registry check).
Enabled cipher suites: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
| Analysis of TLS 1.2 compatibility: .NET Framework |
.NET Framework release is 4.7+ (release 528049)
If you do not use legacy .NET applications you can ignore below warnings (if any detected). Always fix issues found in t
he above OS-based analysis first.
TLS 1.2 enforced for applications targetting .NET Framework 4.0/4.5.x
TLS 1.2 enforced for applications targetting .NET Framework 4.0/4.5.x (32bit app on 64bit OS)
Warning: TLS 1.2 not enforced for applications targetting .NET Framework 3.5
Warning: TLS 1.2 not enforced for applications targetting .NET Framework 3.5 (32bit app on 64bit OS)
MITIGATIONS: per https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/security/enable-tls-1-2-client
[HKLM:\SOFTWARE\Microsoft.NETFramework\v2.0.50727] ‘SchUseStrongCrypto’=dword:1, ‘SystemDefaultTlsVersions’=dword:1
ons’=dword:1
PS C:\Tlschanges1.2March2022\azure-devops-tls12-main>
now i am getting this errir
System.AggregateException: One or more errors occurred. —> System.Net.Http.Htt
pRequestException: An error occurred while sending the request. —> System.Net.
WebException: The underlying connection was closed: An unexpected error occurred
on a send. —> System.IO.IOException: Authentication failed because the remote
party has closed the transport stream.
at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult)
at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar)
— End of inner exception stack trace —
at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar)
— End of inner exception stack trace —
— End of inner exception stack trace —
at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotifica
tion)
at TestTLSAzure.Program.d__0.MoveNext()
—> (Inner Exception #0) System.Net.Http.HttpRequestException: An error occurre
d while sending the request. —> System.Net.WebException: The underlying connec
tion was closed: An unexpected error occurred on a send. —> System.IO.IOExcept
ion: Authentication failed because the remote party has closed the transport str
eam.
at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult)
at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar)
— End of inner exception stack trace —
at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar)
— End of inner exception stack trace —<—
Thanks for posting here the output. Can you please re-run the new version of the readiness checker script?
With community on github we discovered a bug in the script that was fixed. It seems it covers your case.
i also getting the same error
TestExecution encountered unexpected failures System.Net.Http.HttpRequestException: An error occurred while sending the request. —> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. —> System.IO.IOException: Authentication failed because the remote party has closed the transport stream.
Cipher suites already updated
Hi,
The error “Check-in Rejected” has been getting from yesterday
Below is the log file and I believe it is out of time from the note: “Communication over TLS 1.0 and TLS 1.1 will be disabled for Azure DevOps Services for 12 hours on March 22, 2022 and March 24, 2022 from 09:00 UTC to 21:00 UTC.”
What could be the reason?
This is the first time I see this error:
2022-03-23T06:02:51.8217671Z ##[section]Starting: Build database projects **/.sqlproj
2022-03-23T06:02:51.8230093Z ==============================================================================
2022-03-23T06:02:51.8230715Z Task : MSBuild
2022-03-23T06:02:51.8230916Z Description : Build with MSBuild
2022-03-23T06:02:51.8231107Z Version : 1.199.0
2022-03-23T06:02:51.8231333Z Author : Microsoft Corporation
2022-03-23T06:02:51.8231654Z Help : https://docs.microsoft.com/azure/devops/pipelines/tasks/build/msbuild
2022-03-23T06:02:51.8232040Z ==============================================================================
2022-03-23T06:02:53.6931407Z [command]/usr/bin/msbuild /version /nologo
2022-03-23T06:02:54.1228850Z [command]/usr/bin/msbuild /home/vsts/work/8/s/odl.datawarehouse/DW_DM_PowderProduction/DW_DM_PowderProduction.sqlproj
2022-03-23T06:02:54.2138994Z Microsoft (R) Build Engine version 16.6.0 for Mono
2022-03-23T06:02:54.2139523Z Copyright (C) Microsoft Corporation. All rights reserved.
2022-03-23T06:02:54.2140007Z
2022-03-23T06:02:54.6233077Z Build started 03/23/2022 06:02:54.
2022-03-23T06:02:55.0672163Z Project “/home/vsts/work/8/s/odl.datawarehouse/DW_DM_PowderProduction/DW_DM_PowderProduction.sqlproj” on node 1 (default targets).
2022-03-23T06:02:55.0692357Z /home/vsts/work/8/s/odl.datawarehouse/DW_DM_PowderProduction/DW_DM_PowderProduction.sqlproj(62,3): error MSB4019: The imported project “/usr/lib/mono/xbuild/Microsoft/VisualStudio/v11.0/SSDT/Microsoft.Data.Tools.Schema.SqlTasks.targets” was not found. Confirm that the expression in the Import declaration “/usr/lib/mono/xbuild/Microsoft/VisualStudio/v11.0/SSDT/Microsoft.Data.Tools.Schema.SqlTasks.targets” is correct, and that the file exists on disk.
2022-03-23T06:02:55.0722604Z Done Building Project “/home/vsts/work/8/s/odl.datawarehouse/DW_DM_PowderProduction/DW_DM_PowderProduction.sqlproj” (default targets) — FAILED.
2022-03-23T06:02:55.1021234Z
2022-03-23T06:02:55.1023592Z Build FAILED.
2022-03-23T06:02:55.1043138Z
2022-03-23T06:02:55.1053579Z “/home/vsts/work/8/s/odl.datawarehouse/DW_DM_PowderProduction/DW_DM_PowderProduction.sqlproj” (default target) (1) ->
2022-03-23T06:02:55.1055674Z /home/vsts/work/8/s/odl.datawarehouse/DW_DM_PowderProduction/DW_DM_PowderProduction.sqlproj(62,3): error MSB4019: The imported project “/usr/lib/mono/xbuild/Microsoft/VisualStudio/v11.0/SSDT/Microsoft.Data.Tools.Schema.SqlTasks.targets” was not found. Confirm that the expression in the Import declaration “/usr/lib/mono/xbuild/Microsoft/VisualStudio/v11.0/SSDT/Microsoft.Data.Tools.Schema.SqlTasks.targets” is correct, and that the file exists on disk.
2022-03-23T06:02:55.1056860Z
2022-03-23T06:02:55.1057264Z 0 Warning(s)
2022-03-23T06:02:55.1057743Z 1 Error(s)
2022-03-23T06:02:55.1058300Z
2022-03-23T06:02:55.1062652Z Time Elapsed 00:00:00.48
2022-03-23T06:02:55.1382311Z ##[error]Error: The process ‘/usr/bin/msbuild’ failed with exit code 1
2022-03-23T06:02:55.1927740Z ##[section]Finishing: Build database projects **/.sqlproj
Hi Peter
It looks like you’re running on a Linux Self-Hosted or Hosted Agent, so I’d expect you to not have networking issues with TLS 1.2. This might relate to another problem you’re facing.
When I look at your error message above it looks like “/usr/lib/mono/xbuild/Microsoft/VisualStudio/v11.0/SSDT/Microsoft.Data.Tools.Schema.SqlTasks.targets” is missing on the agent. You might need to install the missing component on the agent to help resolve the problem. I think it relates to installing the SQL Server Data Tools on the build agent. Also, have a try at using MSBuild@1 if you’re using yaml pipelines.
Let us know how you get on.
Was visualstudio down today also? not accepting TLS 1 connections?
Hi Chirag, all visualstudio.com endpoints for IPv4 are switched back to TLS 1.0+ mode, can you retry your scenario? Today we’re enforcing TLS 1.2 on dev.azure.com/org only.
Visual Studio 2022 can no longer establish a connection to my organization’s DevOps environment, thus causing a complete work stoppage.
Can you please try again and check that it is using visualstudio.com? Just to note dev.azure.com is currently forcing TLS 1.2 as part of the above mentioned window.
Might be worth checking compatibility of TLS 1.2 using the script here: https://github.com/microsoft/azure-devops-tls12
please help on this issue
System.AggregateException: One or more errors occurred. —> System.Net.Http.Htt
pRequestException: An error occurred while sending the request. —> System.Net.
WebException: The underlying connection was closed: An unexpected error occurred
on a send. —> System.IO.IOException: Authentication failed because the remote
party has closed the transport stream.
at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult)
at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar)
— End of inner exception stack trace —
at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar)
— End of inner exception stack trace —
— End of inner exception stack trace —
at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotifica
tion)
at TestTLSAzure.Program.d__0.MoveNext()
—> (Inner Exception #0) System.Net.Http.HttpRequestException: An error occurre
d while sending the request. —> System.Net.WebException: The underlying connec
tion was closed: An unexpected error occurred on a send. —> System.IO.IOExcept
ion: Authentication failed because the remote party has closed the transport str
eam.
at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult)
at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar)
— End of inner exception stack trace —
at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar)
— End of inner exception stack trace —<—
Not enough info to help here. It is not clear what software throws this error, at what time, which URL is called.
Its working fine on one 2008 server.See the fiddler output
A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.
Version: 3.3 (TLS/1.2)
Random: 62 3C 95 6A 40 75 AB 62 0A 35 F0 FE AC 0F 10 A0 AA 44 1E 45 14 39 78 25 9F 2D 04 C2 9F 82 4F 1A
“Time”: 8/31/2026 4:33:38 AM
SessionID: empty
Extensions:
renegotiation_info 00
server_name dev.azure.com
supported_groups secp256r1 [0x17], secp384r1 [0x18], secp521r1 [0x19]
ec_point_formats uncompressed [0x0]
signature_algs rsa_pkcs1_sha512, ecdsa_secp521r1_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha1, ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_sha1, dsa_sha1
Ciphers:
[C028] TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
[C027] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
[C014] TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
[C013] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
[009F] TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
[009E] TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
[009D] TLS_RSA_WITH_AES_256_GCM_SHA384
[009C] TLS_RSA_WITH_AES_128_GCM_SHA256
[C02C] TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
[C02B] TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
[C024] TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
[C023] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
[C00A] TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[C009] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[003D] TLS_RSA_WITH_AES_256_CBC_SHA256
[003C] TLS_RSA_WITH_AES_128_CBC_SHA256
[0035] TLS_RSA_WITH_AES_256_CBC_SHA
[002F] TLS_RSA_WITH_AES_128_CBC_SHA
[006A] TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
[0040] TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
[0038] TLS_DHE_DSS_WITH_AES_256_CBC_SHA
[0032] TLS_DHE_DSS_WITH_AES_128_CBC_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
Compression:
[00] NO_COMPRESSION
Yes, I can confirm this looks like Client Hello from client which has required cipher suites TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256.
Chirag, could you please keep your posts in a single thread? It is not clear which message reacts to which so it is harder for us to help you.
ok sure
I tried everything and this is what i see now: I am tired now.Please help since we will loose customers
Windows PowerShell
Copyright (C) 2012 Microsoft Corporation. All rights reserved.
PS C:\Users\BizTalkDevelopersbx> Get-ChildItem -Path “HKLM:\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\”
-Recurse >> tlsRegistry.txt
PS C:\Users\BizTalkDevelopersbx> Get-ChildItem -Path “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\
” -Recurse >> tlsRegistry.txt
PS C:\Users\BizTalkDevelopersbx> Get-ChildItem -Path “HKLM:\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\
Domain” -Recurse >> tlsRegistry.txt
PS C:\Users\BizTalkDevelopersbx> Get-ChildItem -Path “HKLM:\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\
Local\Default\00010002\” -Recurse >> tlsRegistry.txt
PS C:\Users\BizTalkDevelopersbx> Get-ChildItem -Path “HKLM:\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\
Local\SSL\” -Recurse >> tlsRegistry.txt
PS C:\Users\BizTalkDevelopersbx> Get-ChildItem -Path “HKLM:\SYSTEM\CurrentControlSet\Control\Cryptography\Providers\Micr
osoft SSL Protocol Provider\” -Recurse >> tlsRegistry.txt
PS C:\Users\BizTalkDevelopersbx> Get-ChildItem -Path “HKLM:\SOFTWARE\Microsoft.NETFramework\v4.0.30319\” >> tlsRegistry
.txt
PS C:\Users\BizTalkDevelopersbx> Get-ChildItem -Path “HKLM:\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v4.0.30319” >>
tlsRegistry.txt
PS C:\Users\BizTalkDevelopersbx> Get-ChildItem -Path “HKLM:\SOFTWARE\Microsoft.NETFramework\v2.0.50727\” >> tlsRegistry
.txt
PS C:\Users\BizTalkDevelopersbx> Get-ChildItem -Path “HKLM:\SOFTWARE\Wow6432Node\Microsoft.NETFramework\v2.0.50727\” >>
tlsRegistry.txt
PS C:\Users\BizTalkDevelopersbx> cd B:\azure-devops-tls12-main
PS B:\azure-devops-tls12-main> Get-ChildItem -Path “HKLM:\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\” –
Recurse >> tlsRegistry.txt
PS B:\azure-devops-tls12-main> Get-ChildItem -Path “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\”
-Recurse >> tlsRegistry.txt
PS B:\azure-devops-tls12-main> Get-ChildItem -Path “HKLM:\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Do
main” -Recurse >> tlsRegistry.txt
PS B:\azure-devops-tls12-main> Get-ChildItem -Path “HKLM:\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Lo
cal\Default\00010002\” -Recurse >> tlsRegistry.txt
PS B:\azure-devops-tls12-main> Get-ChildItem -Path “HKLM:\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Lo
cal\SSL\” -Recurse >> tlsRegistry.txt
PS B:\azure-devops-tls12-main> Get-ChildItem -Path “HKLM:\SYSTEM\CurrentControlSet\Control\Cryptography\Providers\Micros
oft SSL Protocol Provider\” -Recurse >> tlsRegistry.txt
PS B:\azure-devops-tls12-main> Get-ChildItem -Path “HKLM:\SOFTWARE\Microsoft.NETFramework\v4.0.30319\” >> tlsRegistry.t
xt
PS B:\azure-devops-tls12-main> Get-ChildItem -Path “HKLM:\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v4.0.30319” >> tl
sRegistry.txt
PS B:\azure-devops-tls12-main> Get-ChildItem -Path “HKLM:\SOFTWARE\Microsoft.NETFramework\v2.0.50727\” >> tlsRegistry.t
xt
PS B:\azure-devops-tls12-main> Get-ChildItem -Path “HKLM:\SOFTWARE\Wow6432Node\Microsoft.NETFramework\v2.0.50727\” >> t
lsRegistry.txt
PS B:\azure-devops-tls12-main> cd B:\azure-devops-tls12-main
PS B:\azure-devops-tls12-main> ./AzureDevOpsTls12Analysis.ps1
Azure DevOps TLS 1.2 transition readiness checker v. 2022-03-24.1
| Probing Azure DevOps sites |
Probing: status.dev.azure.com
ISSUE FOUND: This may be TLS compatibility issue!
Probe failed when TLS-negotiating to 13.107.6.183:443. Error: Unable to read data from the transport connection: An exis
ting connection was forcibly closed by the remote host.
********************************************************************************
| Analysis of TLS 1.2 compatibility: OS |
PS Version: 3.0
PS Edition:
Win Build Version: 6.1.7601.65536
CLR Version: 4.0.30319.42000
Skipping Get-TlsCipherSuite due to version of OS lower than WS 2016
TLS 1.2 client usage enabled.
Allowed required cipher suites per local: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Missing required cipher suites per local: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Allowed required cipher suites per GP: not defined
Disabled required cipher suites per GP:
At least one of the TLS 1.2 cipher suites required by Azure DevOps enabled on the machine (by registry check).
Enabled cipher suites: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
| Analysis of TLS 1.2 compatibility: .NET Framework |
.NET Framework release is 4.7+ (release 461814)
If you do not use legacy .NET applications you can ignore below warnings (if any detected). Always fix issues found in t
he above OS-based analysis first.
TLS 1.2 enforced for applications targetting .NET Framework 4.0/4.5.x
TLS 1.2 enforced for applications targetting .NET Framework 4.0/4.5.x (32bit app on 64bit OS)
TLS 1.2 enforced for applications targetting .NET Framework 3.5
TLS 1.2 enforced for applications targetting .NET Framework 3.5 (32bit app on 64bit OS)
PS B:\azure-devops-tls12-main> ./AzureDevOpsTls12Analysis.ps1
Azure DevOps TLS 1.2 transition readiness checker v. 2022-03-24.1
| Probing Azure DevOps sites |
Probing: status.dev.azure.com
ISSUE FOUND: This may be TLS compatibility issue!
Probe failed when TLS-negotiating to 13.107.6.183:443. Error: Unable to read data from the transport connection: An exis
ting connection was forcibly closed by the remote host.
********************************************************************************
| Analysis of TLS 1.2 compatibility: OS |
PS Version: 3.0
PS Edition:
Win Build Version: 6.1.7601.65536
CLR Version: 4.0.30319.42000
Skipping Get-TlsCipherSuite due to version of OS lower than WS 2016
TLS 1.2 client usage enabled.
Allowed required cipher suites per local: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Missing required cipher suites per local: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Allowed required cipher suites per GP: not defined
Disabled required cipher suites per GP:
At least one of the TLS 1.2 cipher suites required by Azure DevOps enabled on the machine (by registry check).
Enabled cipher suites: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
| Analysis of TLS 1.2 compatibility: .NET Framework |
.NET Framework release is 4.7+ (release 461814)
If you do not use legacy .NET applications you can ignore below warnings (if any detected). Always fix issues found in t
he above OS-based analysis first.
TLS 1.2 enforced for applications targetting .NET Framework 4.0/4.5.x
TLS 1.2 enforced for applications targetting .NET Framework 4.0/4.5.x (32bit app on 64bit OS)
TLS 1.2 enforced for applications targetting .NET Framework 3.5
TLS 1.2 enforced for applications targetting .NET Framework 3.5 (32bit app on 64bit OS)
PS B:\azure-devops-tls12-main>
see this result not working
A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.
Version: 3.3 (TLS/1.2)
Random: 62 3C CA 71 4D 78 3C 65 8A 0F C6 59 36 06 BC 57 9B 09 E5 AF 8B 9B FF DA CE F9 23 47 A6 12 79 9F
“Time”: 6/30/2030 3:45:38 PM
SessionID: empty
Extensions:
renegotiation_info 00
server_name dev.azure.com
supported_groups secp256r1 [0x17], secp384r1 [0x18], secp521r1 [0x19]
ec_point_formats uncompressed [0x0]
signature_algs rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha1, ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_sha1, dsa_sha1
Ciphers:
[C028] TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
[C027] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
[C014] TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
[C013] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
[C02C] TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
[C02B] TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
[C024] TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
[C023] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
[C00A] TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[C009] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[003D] TLS_RSA_WITH_AES_256_CBC_SHA256
[003C] TLS_RSA_WITH_AES_128_CBC_SHA256
[0035] TLS_RSA_WITH_AES_256_CBC_SHA
[002F] TLS_RSA_WITH_AES_128_CBC_SHA
[006A] TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
[0040] TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
[0038] TLS_DHE_DSS_WITH_AES_256_CBC_SHA
[0032] TLS_DHE_DSS_WITH_AES_128_CBC_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
Compression:
[00] NO_COMPRESSION
Today’s temporary TLS 1.2 enforcement switch just ended.
IPv4 endpoints of dev.azure.com and org.visualstudio.com will remain on TLS 1.0+ until we execute the deprecation as stated in the blog above. During this period the probe in the readiness checker script will still provide reliable indication whether the computer is TLS 1.2-ready.
Regarding the provided console outputs: seems that although the problematic 2008 R2 instance has TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 listed in registry, it is not advertising them in TLS handshakes.
Since you have one working and one non-working WS 2008 R2 instance, I suggest to compare their Windows updates and KBs applied. Also what can be suggested is to compare side-by-side full subtrees of following registry keys:
You can consider opening new issue under https://github.com/microsoft/azure-devops-tls12/issues to get help further help on this by community.
Here is the error
Windows PowerShell
Copyright (C) 2012 Microsoft Corporation. All rights reserved.
PS C:\Users\cshah_master> cd C:\Tlschanges1.2March2022\azure-devops-tls12-main
PS C:\Tlschanges1.2March2022\azure-devops-tls12-main> ./AzureDevOpsTls12Analysis.ps1
| Probing Azure DevOps sites |
Probing: status.dev.azure.com
ISSUE FOUND: This may be TLS compatibility issue!
Probe failed when TLS-negotiating to . Error: Unable to read data from the transport connection: An exis
ting connection was forcibly closed by the remote host.
********************************************************************************
| Analysis of TLS 1.2 compatibility: OS |
PS Version: 3.0
PS Edition:
Win Build Version: 6.1.7601.65536
CLR Version: 4.0.30319.42000
Skipping Get-TlsCipherSuite due to version of OS lower than WS 2016
TLS 1.2 client usage enabled.
Allowed required cipher suites per local: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Missing required cipher suites per local: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Allowed required cipher suites per GP:
Disabled required cipher suites per GP:
At least one of the TLS 1.2 cipher suites required by Azure DevOps enabled on the machine (by registry check).
Enabled cipher suites: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
| Analysis of TLS 1.2 compatibility: .NET Framework |
.NET Framework release is 4.7+ (release 528049)
If you do not use legacy .NET applications you can ignore below warnings (if any detected). Always fix issues found in t
he above OS-based analysis first.
TLS 1.2 enforced for applications targetting .NET Framework 4.0/4.5.x
TLS 1.2 enforced for applications targetting .NET Framework 4.0/4.5.x (32bit app on 64bit OS)
Warning: TLS 1.2 not enforced for applications targetting .NET Framework 3.5
Warning: TLS 1.2 not enforced for applications targetting .NET Framework 3.5 (32bit app on 64bit OS)
MITIGATIONS: per https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/security/enable-tls-1-2-client
[HKLM:\SOFTWARE\Microsoft.NETFramework\v2.0.50727] ‘SchUseStrongCrypto’=dword:1, ‘SystemDefaultTlsVersions’=dword:1
ons’=dword:1
PS C:\Tlschanges1.2March2022\azure-devops-tls12-main>
getting this now
Windows PowerShell
Copyright (C) 2012 Microsoft Corporation. All rights reserved.
PS C:\Users\BizTalkDevelopersbx> cd B:\azure-devops-tls12-main
PS B:\azure-devops-tls12-main> ./AzureDevOpsTls12Analysis.ps1
| Probing Azure DevOps sites |
Probing: status.dev.azure.com
ISSUE FOUND: This may be TLS compatibility issue!
Probe failed when TLS-negotiating to . Error: Unable to read data from the transport connection: An exis
ting connection was forcibly closed by the remote host.
********************************************************************************
| Analysis of TLS 1.2 compatibility: OS |
PS Version: 3.0
PS Edition:
Win Build Version: 6.1.7601.65536
CLR Version: 4.0.30319.42000
Skipping Get-TlsCipherSuite due to version of OS lower than WS 2016
TLS 1.2 client usage enabled.
Allowed required cipher suites per local: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Missing required cipher suites per local: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Allowed required cipher suites per GP:
Disabled required cipher suites per GP:
At least one of the TLS 1.2 cipher suites required by Azure DevOps enabled on the machine (by registry check).
Enabled cipher suites: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
| Analysis of TLS 1.2 compatibility: .NET Framework |
.NET Framework release is 4.7+ (release 461814)
If you do not use legacy .NET applications you can ignore below warnings (if any detected). Always fix issues found in t
he above OS-based analysis first.
TLS 1.2 enforced for applications targetting .NET Framework 4.0/4.5.x
TLS 1.2 enforced for applications targetting .NET Framework 4.0/4.5.x (32bit app on 64bit OS)
TLS 1.2 enforced for applications targetting .NET Framework 3.5
TLS 1.2 enforced for applications targetting .NET Framework 3.5 (32bit app on 64bit OS)
PS B:\azure-devops-tls12-main>
I ran the latest version of the script. All seems to check out, but still won’t connect.
Azure DevOps TLS 1.2 transition readiness checker v. 2022-03-25
| Probing Azure DevOps sites |
Probing: status.dev.azure.com
ISSUE FOUND: This may be TLS compatibility issue!
Probe failed when TLS-negotiating to 13.107.6.183:443. Error: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
********************************************************************************
| Analysis of TLS 1.2 compatibility: OS |
PS Version: 5.1.14409.1018
PS Edition: Desktop
Win Build Version: 6.3.9600.0
CLR Version: 4.0.30319.42000
TLS 1.2 client usage enabled.
Running BCrypt check…
At least one of the TLS 1.2 cipher suites required by Azure DevOps enabled on the machine.
Matching cipher suites: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Running registry check…
Allowed required cipher suites per local: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Missing required cipher suites per local: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Allowed required cipher suites per GP: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Disabled required cipher suites per GP:
At least one of the TLS 1.2 cipher suites required by Azure DevOps enabled on the machine (by registry check).
Enabled cipher suites: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
| Analysis of TLS 1.2 compatibility: .NET Framework |
.NET Framework release is 4.7+ (release 528049)
If you do not use legacy .NET applications you can ignore below warnings (if any detected). Always fix issues found in the above OS-based analysis first.
TLS 1.2 enforced for applications targetting .NET Framework 4.0/4.5.x
TLS 1.2 enforced for applications targetting .NET Framework 4.0/4.5.x (32bit app on 64bit OS)
TLS 1.2 enforced for applications targetting .NET Framework 3.5
TLS 1.2 enforced for applications targetting .NET Framework 3.5 (32bit app on 64bit OS)
Hi Geoff, I see WinServer 2012 R2 or Windows 8.1 is used
Are you getting the consistent results when running via PowerShell 7? (This way we circumvent .NET Framework since PS 7 is on Core). Please run both the readiness checker script and the simple script from the blog above (
(Invoke-WebRequest -Uri status.dev.azure.com).StatusDescription)You also could look at this article https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-8-1 (applies to both W8.1 and WS2012R2). On top of other advice in the article, there is a link to KB that has to be applied: https://support.microsoft.com/kb/2919355.
Additionally, you may need to do some packet capture (Wireshark / Fiddler) to see if the client doing the probe advertises support for TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher suites in the ClientHello packets. This could narrow down source of the issue here to SCHANNEL.
Why is this next one a red flag?
“.NET Framework 4.7+ not installed on computer where PowerShell or .NET applications call Azure DevOps API”
because NET Framework 4.6.2 and later supports TLS 1.1 and TLS 1.2.
Source: https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/security/enable-tls-1-2-client#install-net-updates
What am I missing here?
Arien, thank you, I understand confusion in this territory.
We followed advisory from this article by .NET team. There is mentioned a case where upgrading to 4.7+ is suggested for apps targeting specific legacy versions of .NET Framework to work properly with TLS 1.2.
Hi Mark, We have been working an MS Premier support case since last Thursday and only today have a POSSIBLE fix for our environment. Is there any way we can get a 30 day extension so that we can properly test and apply our fix?
We also had a Github Issue going at the same time and I’ll be posting our fix details there.
Essentially, for us it came down to a Domain level group policy that was explicitly disabling Diffie-Hellman. Once we removed that group policy, the recommended Ciphers started working and we were able to connect to status.dev.azure.com. While we THINK this will fix us, we’d rather not have to test during deprecation tomorrow (unless it’s temporary).
Hi Andrew
The process of deprecation has started, but it is not atomic and will take time. We’re happy to hear that together with Premier support you identified the fix. We are interested in further challenges you face and we’re to continue helping you via Premium support. We will pass this feedback to them.
Ondrej has added more detail in a reply below: link
Can you tell us if this activity has started. Last time on 24th March we were not able to connect. Now we have made some cipher related changes. We are running windows 2012 R2. We want to check if our changes is working.
So we were wondering if you can tell us when this blocking will begin again. While we are trying to migrate to new servers, it will take some time.
Hi Anup. The start of the deprecation process was set to yesterday but we’re not switching all our endpoints at once. Take it that TLS 1.0/1.1 support guarantee ended with the end of March. The process is phased to take several weeks, we’ll update here when important milestones are achieved.
If you need to check anytime what is the momentarily state of TLS setup for the Azure DevOps Services domain of your choice, you can use ssllabs for example (“A” = TLS 1.2, “B” = TLS 1.0+):
https://www.ssllabs.com/ssltest/analyze.html?d=yourorg.visualstudio.com
https://www.ssllabs.com/ssltest/analyze.html?d=dev.azure.com
If you need to check if your fixes worked out and computer is TLS-ready, the approaches described above in the blog should be sufficient (PowerShell probe to status.dev.azure.com, YAML pipeline calling the proble code etc.)