microsoft / azure-devops-tls12

Azure DevOps TLS 1.2 transition readiness checker

Azure DevOps TLS 1.2 transition readiness checker

Azure DevOps Services (as many other Microsoft services) is undergoing transition to deprecate transport protocols TLS 1.0, TLS 1.1 and some TLS 1.2 cipher suites which are considered weak.

See announcement from Azure DevOps team here: https://devblogs.microsoft.com/devops/deprecating-weak-cryptographic-standards-tls-1-0-and-1-1-in-azure-devops-services/

The purpose of this project is to simplify the task of preparation for the transition. We gathered most frequently seen TLS-compatibility issues reported by our customers and made a script which detects them and points the user towards the mitigation.

Run the script:

AzureDevOpsTls12Analysis.ps1

Run in Powershell version 4 or higher. Windows-only, the script has been tested on Windows Server 2012 R2 and above.

What the script does:

• performs a probe by opening a test secure connection to https://status.dev.azure.com. This site requires TLS 1.2 & strong cipher suites as will all Azure DevOps sites after the deprecation of TLS 1.0 and 1.1 protocols takes place.
  • The probe recognizes when the issue is network connectivity or DNS resolving problem vs. when it is caused by TLS incompatibility.
  • Successfull probe is a proof that the OS allows TLS 1.2 and at least one of the required cipher suites is available. This does not guarantee that all other software connecting to Azure DevOps from this computer will work without TLS issues.
• performs an analysis of OS-level issues by looking at the selected Windows registry keys which enable/disable TLS 1.2 protocol and influence the set of usable cipher suites. OS-level configuration is shared by all the software which uses HTTPS/TLS stack provided by OS.
• performs an analysis of .NET Framework: checks version of .NET framework installed and configuration in Windows registry.
  • Looks for presence of registry changes which enable .NET apps built against .NET Framework versions prior to 4.7 to leverage TLS capabilities suported by OS. Without these changes, old .NET apps will default to usage of TLS 1.0 even when TLS 1.2 is enabled by the OS.
  • If you don't intend to use legacy .NET programs that communicate over network on the computer, no need to apply these.

What the script does not:

• The script does not execute any mitigations itself. It only prints mitigation advice which consists of URL of docs article and steps to be executed (either cmdlets to call or registry changes to make).
• The script does not need elevated permissions to run.
• The script cannot say if specific app will have TLS issues. There are apps which have TLS/SSL version of choice hard-code or configured.

Examples

Case 1

Case 2

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

Trademarks

This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft's Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party's policies.

azure-devops-tls12's Issues

Updated $null tests and switch docs to learn links

          Updated $null tests and switch docs to learn links

Originally posted by @AlanFlorance in #15 (comment)

Tasks

Beta Give feedback

No tasks being tracked yet.

Error: The underlying connection was closed during Invoke-webRequest. Mitigation scripts shows everything is fine

Team,

We are running self hosted agents on Windows Server 2012 R2

While I was validating the TLS 1.2 compatibility, we have got the below results.

PS> (Invoke-WebRequest -Uri status.dev.azure.com).StatusDescription

> Invoke-WebRequest : The underlying connection was closed: An unexpected error occurred on a send.
> At line:1 char:2
> + (Invoke-WebRequest -Uri status.dev.azure.com).StatusDescription
> +  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
>    eption
>     + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

I have executed the powershell mitigation scripts and it shows all the mitigations are in place.

Azure DevOps TLS 1.2 transition readiness checker v. 2022-04-14

| Probing Azure DevOps sites |

Probing: status.dev.azure.com
Probe succeeded. Connection negotiated successfully to 13.107.6.183:443

---

=========================================
| Analysis of TLS 1.2 compatibility: OS |

PS Version: 5.1.14409.1027
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 DHE check...
Diffie-Helman key exchange allowed.

---

Running Group Policy check...
No Group Policy cipher suites override defined. No need to create the GP override since cipher suites required by Azure
DevOps are already enabled.

| Analysis of TLS 1.2 compatibility: .NET Framework |

.NET Framework release is 4.7+ (release 528049)
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)
All mitigations required to ensure TLS 1.2-compatibility of legacy .NET applications are in place.

Kindly assist on this.

Unexpected token 'EccEnable" $script

I have the following issue, running the script

.\AzureDevOpsTls12Analysis.ps1

At C:\users\harry\Desktop\AzureDevOpsTls12Analysis.ps1:624 char:50
+             $scriptFile = OutputMitigationToPs1 "EccEnable" $script
+                                                  ~~~~~~~~~~~~~~~~~~
Unexpected token 'EccEnable" $script
            Write-nonOK "MITIGATION' in expression or statement.
At C:\users\harry\Desktop\AzureDevOpsTls12Analysis.ps1:640 char:41
+             Write-nonOK "    - Press 'OK' button"
+                                         ~~~~~~~~~
The string is missing the terminator: '.
At C:\users\harry\Desktop\AzureDevOpsTls12Analysis.ps1:736 char:1
+
Missing closing ')' in expression.
At C:\users\harry\Desktop\AzureDevOpsTls12Analysis.ps1:584 char:1
+ {
+ ~
Missing closing '}' in statement block or type definition.
    + CategoryInfo          : ParserError: (:) [], ParseException
    + FullyQualifiedErrorId : UnexpectedToken

Any ideas? Thankx!

Error - Mitigation script not created

This line:
$filePathAbsolute = $fileName | Resolve-Path
causes error:
Resolve-Path : Cannot find path
'C:...\azure-devops-tls12-main\azure-devops-tls12-main\Mitigation-RegFunctionsDEL.ps1' because it
does not exist.

and $filePathAbsolute is null,
followed by error:
Out-File : Cannot bind argument to parameter 'FilePath' because it is null.
At C:...\azure-devops-tls12-main\azure-devops-tls12-main\AzureDevOpsTls12Analysis.ps1:133 char:33

• $lines | Out-File -FilePath $filePathAbsolute -Force
  

Happened on Powershell version 7.3.0 and on version 5.1.22621.608

To mitigate I created an empty ps1 file to be written into

Proxy support

Probing tests fails if proxy is required. Would be nice to have proxy support as command line parameter, for example ./AzureDevOpsTls12Analysis.ps1 -Proxy "myproxy:myport".

Probing not ok but all others steps ok (windows 7)

Hello, this is the result of the script, don't know what to do..

PowerShell 7.2.3
Copyright (c) Microsoft Corporation.

https://aka.ms/powershell
Type 'help' to get help.

PS C:> (Invoke-WebRequest -Uri dev.azure.com).StatusDescription
Invoke-WebRequest: Unable to read data from the transport connection: An existin
g connection was forcibly closed by the remote host..
PS C:> (Invoke-WebRequest -Uri status.dev.azure.com).StatusDescription
Invoke-WebRequest: Unable to read data from the transport connection: An existin
g connection was forcibly closed by the remote host..

PS C:> .\AzureDevOpsTls12Analysis.ps1
Azure DevOps TLS 1.2 transition readiness checker v. 2022-05-09

| Probing Azure DevOps sites |

Probing: status.dev.azure.com
ISSUE FOUND: This may be TLS compatibility issue!
Probe failed when TLS-negotiating to [::ffff:13.107.6.183]:443. Error: Unable to
read data from the transport connection: An existing connection was forcibly cl
osed by the remote host..

---

=========================================
| Analysis of TLS 1.2 compatibility: OS |

PS Version: 7.2.3
PS Edition: Core
Win Build Version: 6.1.7601.0
CLR Version:

---

For old Windows versions (WS 2012, Windows 7 and older) TLS 1.2 must be explicit
ly enabled...
TLS 1.2 client usage enabled.

---

Running Cipher Suite check (BCrypt)...
At least one of the TLS 1.2 cipher suites supported by Azure DevOps enabled on t
he machine.
Matching cipher suites: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES
_128_GCM_SHA256

---

Running Group Policy check...
Group Policy cipher suites override defined: TLS_RSA_WITH_AES_128_CBC_SHA256 TLS
_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_C
BC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH
AES_128_CBC_SHA256_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_RS
A_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384 TLS_DHE_RSA
WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_A
ES_256_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_ECDSA_WITH
AES_128_GCM_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE
ECDSA_WITH_AES_256_GCM_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P
384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_S
HA_P384 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS
_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WI
TH_3DES_EDE_CBC_SHA
Missing cipher suites:
No need to change the GP override since cipher suites required by Azure DevOps a
re already enabled.

---

Running Key Exchange check...
Diffie-Hellman key exchange allowed.
Key Exchange check passed.

---

Running Elliptic Curve check...
Skipping elliptic curve check due to OS version...

| Analysis of TLS 1.2 compatibility: .NET Framework |

.NET Framework release is 4.7+ (release 461814)
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 64
bit OS)
All mitigations required to ensure TLS 1.2-compatibility of legacy .NET applicat
ions are in place.

When enabling Diffie-Hellman KeyExchangeAlgorithm, should also set ServerMinKeyBitLength to avoid logjam

Per https://weakdh.org/ the ServerMinKeyBitLength on reg path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman should be set to 2048 (0x800) when enabling Diffie-Hellman.

I discovered this workaround by this post https://developercommunity.visualstudio.com/t/azure-devops-agent-installed-on-windows-server-201/1651426#T-N1651596 . Adding this reg dword, the check script returns success and testssl.sh --logjam passes.

This mitigation is helpful for agents deployed to web servers where tighter security is required.

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.

Hi,

After executing the powershell script. I am getting below error :

Azure DevOps TLS 1.2 transition readiness checker v. 2022-06-16

| 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 |

Getting environment info...
PS Version: 5.1.14409.1005
PS Edition: Desktop
CLR Version: 4.0.30319.42000
OS Version: system.environment: 6.2.9200.0, systeminfo: 6.2.9200 --> 6.2.9200.0

---

Running Hot Fix check...
Checking KB3140245...
Hotfix KB3140245 found: \TCOSVM-T0052\root\cimv2:Win32_QuickFixEngineering.HotFixID="KB3140245",ServicePackInEffect=""
Hotfix check passed.

---

For old Windows versions (WS 2012, Windows 7 and older) TLS 1.2 must be explicitly enabled...
TLS 1.2 client usage enabled.

---

Running Cipher Suite check (BCrypt)...
All enabled cipher suites: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RS
A_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_RSA_WI
TH_AES_128_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P2
56 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384 TLS_ECDHE_ECDS
A_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_DSS_WITH
_AES_256_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_RC4_128_MD5
At least one of the TLS 1.2 cipher suites supported by Azure DevOps is enabled and working.
Matching cipher suites: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

---

Running Group Policy check...
Group Policy cipher suites override defined: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_
256_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P25
6 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES
_128_CBC_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P
384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA25
6 TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_RC4_128_MD5
Missing cipher suites:
No need to change the GP override since cipher suites required by Azure DevOps are already enabled.

---

Running Key Exchange check...
Diffie-Hellman key exchange allowed.
Key Exchange check passed.

---

Running Elliptic Curve check...
Skipping elliptic curve check due to OS version.

| Analysis of TLS 1.2 compatibility: .NET Framework |

.NET Framework release is 4.7+ (release 528049)
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)
All mitigations required to ensure TLS 1.2-compatibility of legacy .NET applications are in place.

Please help me to fix this probe issue.

Agents offline and unable to connect during TLS deprecation

Please note that we also have an MS Premier support case open on this issue and have been through numerous engineers and scenarios, all with no fix.
Our situation is thus:
2012R2 servers (also some 2008 servers) with .Net 4.8. We've gone through the ciphers and they're supposed to be correct, however, we still have the issue. We are rapidly approaching the deadline of Thursday and thus far, Premier support has been unable to provide a solution. Posting here in hopes that we can get some coordination between the ADO devs and Premier support to find a solution. Premier support case number available on request.

PS C:> (Invoke-WebRequest -Uri status.dev.azure.com).StatusDescription
Invoke-WebRequest : The underlying connection was closed: An unexpected error occurred on a send.
At line:1 char:2

• (Invoke-WebRequest -Uri status.dev.azure.com).StatusDescription

•  + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
  eption
   + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
  
  

Output of the recommended check script is:

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: 5.1.14409.1005
PS Edition:  Desktop
Win Build Version:  6.3.9600.0
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_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TL
S_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Missing required cipher suites per local:
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_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
=====================================================
| 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)
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)

Connection error without solution

Hello
I use the script on old build server windows 2012 R2, I got this log without any solutions, what can i do ?

| Probing Azure DevOps sites |

Probing: status.dev.azure.com
ISSUE FOUND: This may be TLS compatibility issue!
Probe failed when TLS-negotiating to [::ffff:13.107.6.183]:443. Error: Unable to
read data from the transport connection: An existing connection was forcibly cl
osed by the remote host..

---

=========================================
| Analysis of TLS 1.2 compatibility: OS |

PS Version: 7.1.3
PS Edition: Core
Win Build Version: 6.3.9600.0
CLR Version:
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 TL
S_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 th
e 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 64
bit OS)

Once fixed, TLS 1.2 issue come back again after few weeks

Hi all
After diagnosing the TLS 1.2 issue using the AzureDevOpsTls12Analysis.ps1 script on my Windows server 2016 (I have three VMs in Azure), the problem was fixed the first time with the generated mitigation scripts Mitigation-NetFramework.ps1 and Mitigation-RegFunctionsDEL.ps1 (run as administrator as suggested in the script output) and a restart was performed. The agent can connect again to azure devops and it shows the green online status.
However, after few weeks, the agent appeared as offline in azure devops and the same problem was diagnosed. I reused the same script (AzureDevOpsTls12Analysis.ps1) with the mitigation script (only Mitigation-RegFunctionsDEL.ps1 was generated this time) to refix the issue. Of course, a restart was required.
Once again, the same issue reappeared 4 or 5 times since the first one last June. Somebody can help to fix this issue once and for all.
Best regards

SSL Cipher Suites maximum length in gpedit

One of the mitigations stated to override the group policy (Computer Config/Administrative Templates/Network/SSL Config Settings).

The maximum length of this field (in Windows2008) is 1023 characters, in my case this resulted in an incomplete SSL Cipher Suite.

May I suggest to limit $suggestedFunctionsContent for the gpedit mitigation?