Deprecating weak cryptographic standards (TLS 1.0 and 1.1) in Azure DevOps Services

Mark Graham

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.

Pipeline Task

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.

87 comments

Discussion is closed. Login to edit/delete existing comments.

  • Ben Reisner 0

    Can you offer suggestion for checking compatibility with Visual Studio 2012?

    • Mark GrahamMicrosoft employee 0

      Here’s a link to the previous blog post that has more information on Visual Studio. In there there’s another link to registry settings to enable TLS 1.2.

      When it comes to checking compatibility. You could try the PowerShell checks above, as Visual Studio uses .NET Framework behind the scenes. And then look to test it out during the 2 windows next week on the 22nd and 24th.

      • Stefan Cervenka (scervenk) 0

        Hi Mark,
        I have the self-hosted build agent 2.200.2 with Windows Server 2019.
        I set all by link to registry settings to enable TLS 1.2.
        PowerShell command (Invoke-WebRequest -Uri status.dev.azure.com).StatusDescription still fails with “The underlying connection was closed: An unexpected error occurred on a send.”
        Agent error displayed below.

        How can I fix it, please ?

        “Agent connect error: The SSL connection could not be established, see inner exception.. Retrying until reconnected.”

        System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
        —> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host..
        —> System.Net.Sockets.SocketException (10054): An existing connection was forcibly closed by the remote host.
        — End of inner exception stack trace —
        at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken)
        at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.GetResult(Int16 token)
        at System.Net.FixedSizeReader.ReadPacketAsync(Stream transport, AsyncProtocolRequest request)
        at System.Net.Security.SslStream.ThrowIfExceptional()
        at System.Net.Security.SslStream.InternalEndProcessAuthentication(LazyAsyncResult lazyResult)
        at System.Net.Security.SslStream.EndProcessAuthentication(IAsyncResult result)
        at System.Net.Security.SslStream.EndAuthenticateAsClient(IAsyncResult asyncResult)
        at System.Net.Security.SslStream.<>c.b__65_1(IAsyncResult iar)
        at System.Threading.Tasks.TaskFactory1.FromAsyncCoreLogic(IAsyncResult iar, Func2 endFunction, Action1 endAction, Task1 promise, Boolean requiresSynchronization)
        — End of stack trace from previous location where exception was thrown —
        at System.Net.Http.ConnectHelper.EstablishSslConnectionAsyncCore(Stream stream, SslClientAuthenticationOptions sslOptions, CancellationToken cancellationToken)
        — End of inner exception stack trace —
        at Microsoft.VisualStudio.Services.Common.VssHttpRetryMessageHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        at System.Net.Http.HttpClient.FinishSendAsyncBuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)
        at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.SendAsync(HttpRequestMessage message, HttpCompletionOption completionOption, Object userState, CancellationToken cancellationToken)
        at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.SendAsync[T](HttpRequestMessage message, Object userState, CancellationToken cancellationToken)
        at Microsoft.VisualStudio.Services.Location.Client.LocationHttpClient.GetConnectionDataAsync(ConnectOptions connectOptions, Int64 lastChangeId, CancellationToken cancellationToken, Object userState)
        at Microsoft.VisualStudio.Services.WebApi.Location.VssServerDataProvider.GetConnectionDataAsync(ConnectOptions connectOptions, Int32 lastChangeId, CancellationToken cancellationToken)
        at Microsoft.VisualStudio.Services.WebApi.Location.VssServerDataProvider.ConnectAsync(ConnectOptions connectOptions, CancellationToken cancellationToken)
        at Microsoft.VisualStudio.Services.Agent.AgentServer.EstablishVssConnection(Uri serverUrl, VssCredentials credentials, TimeSpan timeout)

      • Hicham Boutaleb 0

        in this link VS 2019 shouldn’t be impacted because it support TLS 1.2, but 4im not able to connect to https://dev.azure.com/orgname Git repos. VS 2019 is installed on Win 2019 Standard. can you help please?

        • Ondrej KapralMicrosoft employee 0

          This looks like cipher suite incompatbility, potentially caused by group policy-enforcement.

          Please use readiness checker script on the affected computer.

      • Lou Soto 0

        Hi Mark,

        I noticed an error yesterday and today and I’m not sure if it relates to the changes you mentioned, but my CICD pipeline (devOps) has worked consistently for over 6 month without any issues but failed yesterday and today….
        I ran a new release and got an error when docker was pushing the image to ACR:

        unauthorized: Invalid clientid or client secret.

        [error]unauthorized: Invalid clientid or client secret.

        [error]The process ‘/usr/bin/docker’ failed with exit code 1

        any clues?

        Thanks

  • Michael Germino 0

    Does this apply to on-prem deployment pools?

    • Mark GrahamMicrosoft employee 0

      This only applies to Azure DevOps Services and not Azure DevOps Server (on-premises).

      Basically, if you’re using Self-Hosted Agent Pools and/or calling API’s via the following domains you might have TLS connectivity issues once we turn-off TLS 1.0/1.1 and enforce TLS 1.2: https://dev.azure.com/ and https://.visualstudio.com

  • Chris Ulisse 0

    We are running into some issues with VS2019 after disabling TLS 1.0 and 1.1 with DevOps on-premises too.

    • Mark GrahamMicrosoft employee 0

      This only applies to Azure DevOps Services and not Azure DevOps Server (on-premises).

      If you’re having issues with your on-premise Azure DevOps Server and battling with connectivity with VS2019. It might be worth contacting support.

  • Taylor 0

    Thank you for including the cipher suites. I thought we were prepared for TLS 1.2 last time, but had an issue with cipher suites. I also appreciate the test period to make sure we are ready this time. Thanks!

    • Mark GrahamMicrosoft employee 0

      Thanks Taylor. yeah cither suites are one of the key areas to check. I hope the test period is successful for you.

  • Shingayi 0

    Thanks for sharing all these details and particularly the pipeline sample to run on selfhosted agents. How can I do a similar test for linux build agents?

    • Mark GrahamMicrosoft employee 0

      I haven’t been able to test fully on Linux without TLS 1.2 enabled. But think the following statement should be able to generate a similar result to the Windows one above:

      curl -o /dev/null -s -w "%{http_code}\n" https://status.dev.azure.com

      And if you were to put it into a yaml pipeline it would look something like this:

       task: Bash@3
        inputs:
          targetType: 'inline'
          script: 'curl -o /dev/null -s -w "%{http_code}\n" https://status.dev.azure.com'
          failOnStderr: true

      Any error should show if it’s working or not.

      Let me know how it goes.

      • Suphanat Sunthornthaweechot 0

        I’m running self-hosted Linux agents. Is this issue not affected to running all my agents? but I must be check version of Virtual Studio in my local computer to communicate to Azure DevOps repository

  • Said Zarouk 0

    When using https://dev.azure.com and Self-Hosted Agent Pools on-premise Buildserver and querying site status.dev.azure.com in Powershell console:
    Since PowerShell runs on .NET Framework,use the correct Powershell version that uses .Net Framework 4.7+ to test the mentioned code.
    If you use Powershell 5.1 (default Microsoft .NET Framework 4.5),you still get the “The underlying connection was closed: An unexpected error occurred on a send”,even if your on-premise server meets the requirements for TLS 1.2.
    Querying site “status.dev.azure.com” in Powershell console with Powershel 7.2 and .NET Framework 4.7, returns message status OK!

  • Ondrej KapralMicrosoft employee 0

    We put together a powershell script “TLS 1.2 transition readiness checker” which identifies most frequently seen TLS-compatibility issues and prints mitigation advice together with docs.microsoft.comlinks. Hope this helps!

    https://github.com/microsoft/azure-devops-tls12

    The script is work in progress, let us know in case of issues; feel free to contribute with PR 🙂

    • chirag shah 0

      amazing script.

      This is what i found on my non working machine

      MITIGATION: update OS, then per https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/manage-ssl-pro
      tocols-in-ad-fs
      [HKLM:\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002] ‘Functions’ append line: TLS_
      DHE_RSA_WITH_AES_256_GCM_SHA384
      [HKLM:\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002] ‘Functions’ append line: TLS_
      DHE_RSA_WITH_AES_128_GCM_SHA256

  • Kunal Tanti 0

    We have an app calling the ADO API’s and it is deployed in app service, do we need to configure the TLS to 1.2 in the app service?
    Also, we are planning to move to AKS, any TLS configuration we should be enforcing in AKS or in the docker image?

    • Ondrej KapralMicrosoft employee 0

      To be compatible with TLS 1.2-enforcing changes in Azure DevOps, there’s no need to reconfigure “Minimum TLS Version” of your app service. Ad AKS: no special configuration should be needed.

  • thomas woelfer 0

    So we are using TF.EXE (actually, we are using the TF Shell extensions that don’t seem to get updated, but tf.exe has the same problem) and when trying to

    tf get

    we see TF400324 – which i assume is beeing caused by some TLS issues with tf.exe. We are using the version of tf.exe that came with vs 2019. Shouldn’t this just work? Any suggestions?

    • Ondrej KapralMicrosoft employee 0

      We tried to reproduce the error you’re getting with VS 2019’s TF.exe. It worked fine against TLS 1.2-only endpoints. Also, looking into source codes, the tool is TLS 1.2-ready.

  • Jeremy Patrick 0

    Having an issue connecting to Visual Studio 2017 now, we use TFS but is the dev.azure.com/Project which according to this shouldn’t be affected currently.
    I was told TLS 1.2 was enabled on our server which is a 2012 server R2. I am able to log in to other applications using my Active Directory account.

    I did run the powershell script, and received the “Underlying connection was closed” error”

    • Ondrej KapralMicrosoft employee 0

      It is not clear what is meant by ‘connecting to Visual Studio’. Some auth, licensing and account management flows of VS have API calls against visualstudio.com, so impact here is possible.

      Please try to run the readiness checker script here: https://github.com/microsoft/azure-devops-tls12/blob/main/AzureDevOpsTls12Analysis.ps1.

      Seeing WS 2012 R2 is used, this might be either problem with required cipher suites being disabled or .NET Framework-related issue. The readiness checker should recognize those and provide mitigation advice.

      • Jeremy Patrick 0

        Think we resolved the issue, we had made some changes to the Reg Keys, although we were still having the issue, then update VS 2017 with the Feb and March updates, and we were able to finally connect.

        Well, just realized it is after 21:00 UTC time…so probably not working.

      • Jeremy Patrick 0

        Here is what we are getting with the powershell script.

        ===========================

        | 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: 4.0
        PS Edition:
        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_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

        [HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727] 'SchUseStrongCrypto'=dword:1, 'SystemDefaultTlsVersi
        

        ons’=dword:1

        • Ondrej KapralMicrosoft employee 0

          Jeremy, please rerun the newest version of the readiness checker.

          In collaboration with community on github we discovered the case when the script returned all-green while there were cipher suites disabled by GPs. I believe this is also your case.

          • Jeremy Patrick 0

            ==============================

            | 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: 4.0
            PS Edition:
            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_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: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
            ISSUE FOUND: No TLS 1.2 cipher suites required by Azure DevOps are available
            Cipher suites are supported by the OS but explicitly disabled (probably by group policy)
            MITIGATION: per https://docs.microsoft.com/en-us/skypeforbusiness/manage/topology/disable-tls-1.0-1.1
            If the below registry change does not work (or works temporarily, ask your domain admin to enable cipher suites by G
            P)
            [HKLM:\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002] ‘Functions’ append lines: TLS_DHE_RSA_WI
            TH_AES_256_GCM_SHA384
            [HKLM:\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002] ‘Functions’ append lines: TLS_DHE_RSA_WI

            TH_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

            [HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727] 'SchUseStrongCrypto'=dword:1, 'SystemDefaultTlsVersi
            

            So I believe we only have 1, and I am in the process of trying to have our IT enable it. To both the 384 and 256 need to be available and active?

          • Ondrej KapralMicrosoft employee 0

            Yes, that output looks better!

            To both the 384 and 256 need to be available and active?

            It is enough to enable one of the two cipher suites:
            TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
            TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

          • Jeremy Patrick 0

            We are now connected!! The probing shows the connection, however it stills says the cipher is not enabled. We are connecting to TFS now from VS2017!!! I will post the message below that we are receving, but not response is needed at this time. Ty for your help!!!

            ==============================

            | 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: 4.0
            PS Edition:
            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_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: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
            ISSUE FOUND: No TLS 1.2 cipher suites required by Azure DevOps are available
            Cipher suites are supported by the OS but explicitly disabled (probably by group policy)
            MITIGATION: per https://docs.microsoft.com/en-us/skypeforbusiness/manage/topology/disable-tls-1.0-1.1
            If the below registry change does not work (or works temporarily, ask your domain admin to enable cipher suites by G
            P)
            [HKLM:\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002] ‘Functions’ append lines: TLS_DHE_RSA_WI
            TH_AES_256_GCM_SHA384
            [HKLM:\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002] ‘Functions’ append lines: TLS_DHE_RSA_WI

            TH_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

            [HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727] 'SchUseStrongCrypto'=dword:1, 'SystemDefaultTlsVersi
            

            ons’=dword:1

Feedback usabilla icon