• Contact Us

    We will get back to you as soon as possible.

  • We do not collect personal information except to the extent you provide that information to use through email, your web browser or through our contact forms. We will not share, sell or otherwise provide non-public information to others without your consent.


  • We do not collect personal information except to the extent you provide that information to use through email, your web browser or through our contact forms. We will not share, sell or otherwise provide non-public information to others without your consent.

Published on April 13, 2021
Dot Net + TLS


This article includes critical & important relationship dependencies on how exactly DOT NET (.NET) compiled applications function with and along side TLS.  For non-developers, you most certainly will find this article extremely helpful in how we disentangle multiple hidden secrets and dependencies between DOT NET Apps + TLS.

With the number of release-versions of .NET Framework, there are MANY important aspects concerning TLS behavior which should be closely observed and certainly understood.  For instance, let’s consider 4.62 compiled apps natively negotiate TLS differently latter versions. Wow!

At the time of this post Microsoft happens to support a wide range of ten (10) versions of DOT NET (.NET) Framework Runtime for their two (2) versions of Common Language Runtime (CLR) – click for list.


Securing or remediating TLS simply means ensuring the business is functioning at and utilizing the most secure instance or version.  At present, TLS 1.2 is the recommended (secure) version.

When working with, securing or remediating enterprise TLS, there are three (3) distinctly separate components one needs to be intimately familiar with:

    • Compiled Applications
    • DOT NET (.NET) Framework

Fundamental TLS Rule

The highest supported TLS version is always preferred by the operating system during TLS handshake. Although this is true, application behavior (or laughingly called misbehavior) can win-out causing unpredictable and insecure behavior.


    • The phrase DOT NET client applications are interchangeable with ‘.NET applications’ or ‘.NET compiled applications’, etc.
    • Developers write and compile DOT NET client applications. These apps are stamped with a DOT NET compilation (compiled) version.  For example, 3.5x, .4.5.2, 4.6, 4.7, and so on.
      • As a result, differing versions of DOT NET (.NET) applications inherit and maintain unique and backward capabilities


    • Applications are installed on both Workstations & Servers
    • The installed version of .NET Framework Runtime is not of great relevance to TLS remediation efforts.
      • Workstations will commonly have a number of applications installed
      • Typically fewer, Servers likewise maintain a number of installed applications
    • DOT NET (.NET) Framework Runtime is not the same as DOT NET (.NET) client application.

The DOT NET (.NET) Framework Runtime is installed on client computers.  Your DOT NET (.NET) Framework Runtime provides the capability of executing DOT NET (.NET) compiled applications.  An installed and compatible version of the Framework is required to execute applications.  For instance, running a 4.62 compiled app minimally requires that version (4.62) of the Framework. Conversely, you would need to upgrade the Framework to run a 4.7 compiled app. Clear as mud?

  • A Windows computer can support multiple Common Language Runtime (CLR). For example, Runtime 2.0 (Dot Net 3.0) or Runtime 4.0 (DOT NET 4.0)
  • The current (installed) revision of DOT NET (.NET) Framework Runtime is capable of executing compiled application at that version. For example, DOT NET FW 4.7 runtime is capable of executing 4.7 compiled apps.
  • The version .NET Framework Runtime maintains backward compatibility, capable of executing previous (or older) .NET applications previous to its own. This is restricted to it’s own Common Language Runtime (CLR). For example, DOT NET FW 4.8 runtime is capable executing all previous compiled apps (4.7, 4.62, 4.52, etc.) or 3.51 runtime is capable executing all previous compiled apps (3.5,etc.)

More importantly, Every DOT NET (.NET) compiled client-application maintains its own built-in, unique & defined set of TLS protocol instructions and behavior(s).


DOT NET (.NET) App TLS Negotiation Order
3.5 – 3.5.1 SSL 3.0, TLS 1.0
4.0 – 4.5.1 SSL 3.0, TLS 1.0, 1.1 then 1.2
4.5.2 TLS 1.0 then SSL 3.0
4.6 – 4.6.2 TLS 1.2, TSL 1.1 then TLS 1.0
4.7 – 4.8 Relies on OS to negotiate TLS


It isn’t uncommon for a Windows computer to have a variety of locally installed applications (commonly referred as apps).  Depending on its age, apps are compiled with different versions of DOT NET (.NET). Take for example, ADFS 2016 is compiled with DOT NET (.NET) 4.52. Above all, DOT NET apps are seldom compiled with the same version nor do developers always maintain their apps on current versions.

Nearly all DOT NET (.NET) compiled apps have varying TLS negotiation behavior (see diagram example below). This can be a bit frustrating.  On Windows computers, in order to accommodate for the numerous and varying application versions, admins routinely install a current versions of the DOT NET (.NET) Framework Runtime. Newer versions of Windows also come with the near current versions of the Runtime Framework.  In addition, the Framework is routinely updated (or maintained).  In other words, regularly patched.

Maintaining current versions of DOT NET (.NET) Framework Runtime, on client computers, in addition provides backward (execution) compatibilities for previous DOT NET (.NET) compiled application-versions. (see support Runtime versions). Above all, we want to keep our client working.  Clear as mud?

In other words, DOT NET (.NET) Framework Runtime version 4.7 is required for:

    1. Existing 4.7 compiled applications
    2. Previously compiled application versions (4.62, 4.6, 4.52, etc.)

In the case above, if running a 4.8 application, one would need to install the latest 4.8 Framework Runtime.



TLS .Net

A developer compiles their “Coffee Brewing Delight” application stamped with .NET version 4.5.2. This compiled .NET application assumes certain behavioral-characteristics and qualities inherent to version 4.5.2.

Although the above computer has 4.7 of the Runtime installed, in order for this application to run, the client computer would minimally require version 4.5.2 of .NET Framework Runtime.


SCHANNEL controls, exposes and makes use of defined TLS protocols, along with their associated cryptography ciphers. Therefore, controls for these protocols are maintained via Group Policy Objects or the local registry.

For any client/server DOT NET (.NET) application to properly negotiate, it would exclusively depend upon the availability of defined SCHANNEL protocols – meaning, whether that protocol is enabled or disabled.  For example, TLS 1.0, 1.1 or 1.2. 

These DOT NET (.NET) apps have built-in and default TLS behavior(s) – for instance, how the application interacts and negotiates using SCHANNEL. You’re not alone – as a result, this can be a bit confusing.

DOT NET (.NET) applications compiled prior to 4.7 maintain built-in and defined TLS negotiation instructions. In other words, these DOT NET (.NET) apps instruct SCHANNEL which TLS protocols (in sequence) to negotiate.

Take for example:

    • 4.5.2 DOT NET (.NET) 4.5.2 applications instruct SCHANNEL to negotiate TLS protocol in the following order:
      • 1.) TLS 1.0 then
      • 2.) SSL 3.0.
    • 4.6.2 DOT NET (.NET) applications instruct SCHANNEL to negotiate in this order:
      1. TLS 1.2 then
      2. TLS 1.1 then
      3. TLS 1.0.
    • 4.7 DOT NET (.NET) and newer applications (by default) rely on the operating system to negotiate TLS.

(note: although there should not be any reason, the 4.7 default behavior can be disabled.  If disabled, 4.7+ compiled apps would assume the built-in behavior for 4.6 & 4.6.2.)

Newer iterations of .NET, Microsoft has gradually introduced new safeguards which simplifies and standardizes this negotiation process.

Similarly, applications compiled prior to 4.7 versions have built in and defined protocols. As a result, these protocols are passed to, and instruct SCHANNEL which protocols to negotiate.

Above all, as .NET Framework advances, TLS protocol behavior has become more uniform and predictable.

DOT NET + TLS Dependencies


.NET applications depend exclusively upon SCHANNEL to negotiate TLS.




Applications compiled in .NET version 4.5.2 default TLS negotiation-order (behavior) attempts TLS 1.0 then SSL 3.0 (note: if that protocol is disabled via SCHANNEL, communication with that protocol will fail).

This 4.5.2 compiled application passes TLS 1.0 to, and instructions SCHANNEL to negotiate TLS 1.0 (see above diagram). Assuming the TLS 1.0 client protocol is enabled, that .NET Framework application will function as expected. However if the SCHANNEL TLS 1.0 and SSL 3.0 client settings are disabled, the application will fail.

Final Example:

Let’s take another example; the default behavior for 4.7 compiled applications relies exclusively on SCHANNEL to control and negotiate the highest possible (available) version of TLS. If for instance, TLS 1.1 & 1.2 are the only SCHANNELs client protocols enabled, the operating system will negotiate TLS 1.2.

In conclusion, I hope this provides a bit more light on the relationship and dependencies between DOT NET (.NET) Framework, applications and SCHANNEL TLS.

Warmest Regards,

SHAWN MAY – DTS Inc. | Principal Architect & CEO | shawn@yourDTS.com



Dynamic Technical Solutions is one of the best in the business. I had the pleasure of working and learning a great deal from their team members in the past four years. DTS’ work ethic is unlike any I have ever seen. I have always known them to follow through until the job is completed correctly.


R.T., Senior IT Infrastructure & Ops Manager, E-470 Public Highway Authority



I had a pleasure working with Dynamic Technical Solutions very closely on a very complex, critical project with a lot of moving parts and unknowns. Not only did DTS quickly grasped all the complexities of the project, they helped bring clarity and order to it. Their dedication and professionalism are tremendous. They are team members whom you can always count on to be there and deliver what’s required and then some. Their technical abilities have allowed us to develop and implement great solutions. DTS’ understanding of IT security helped us not only come up with a robust technical solution, but also a very secure one. I’ll gladly work with them any time again.


I.S., VP Technology at Barclays Capital



I have had the pleasure of working with Dynamic Technical Solutions over the last year servicing the same customer. DTS demonstrates an exceptional technical aptitude, attention to detail and work ethic that makes their service delivery extraordinary. Anyone requiring solid directory services architectural or technical guidance will benefit from what DTS brings to the table. I recommend their work.


N.K., Microsoft - Senior Technical Account Manager



I had the pleasure of working with Dynamic Technical Solutions at The Children's Hospital and found them to be an extremely knowledgeable in respect to Microsoft Windows Engineering. Their precision, dedication, thoroughness and understanding in Microsoft Active Directory design and support are impeccable. They take pride in continuously learning, adapting and implementing all of the knowledge they possess and have shown such aptitude in technical writings of Kerberos, DNS and Microsoft products as a whole. I would welcome the opportunity of working with DTS again and hope to do so in the future.


M.D., The Children's Hospital



We contracted with DTS to perform an upgrade/migration of our existing Active Directory and Exchange environments onto new equipment. The entire process was extremely painless and we were very happy with the results. I can honestly say that our DTS consultants exceeded our expectations. It took less time than we had anticipated, and some of the issues we were afraid of running into did occur, but our DTS consultants were very quick at finding a working solution.

DTS is technically competent, their work is very thorough, and their attention to detail is the best I have seen. I would not hesitate in recommending Dynamic Technical Solutions to anyone looking for Microsoft professionals.


R.B. Information Technology Director, Colorado City Government – Town of Vail



CH2M Hill is a $5B IT and engineering firm based in Denver, Colorado. CH2M Hill has utilized DTS for complex IT management and support projects. During the time that DTS supported our efforts for one of our customers (a Fortune 500 company), their consultant exhibited significant technical competencies. Furthermore, our DTS consultant is a professional, receiving high marks from the customer for program management as well as communication skills.


Director of Business Development, CH2M Hill


  • Implementing correct solutions
  • Bringing the correct talent (professional-staff-augmentation or project team)
  • Alignment to the business functional & functional direction
  • Maintaining agility with communication and options
  • Ensure to have a properly scoped project and accurate roadmap eliminating fluff


Stay Well

Here are some incredibly-simple videos to watch & share with co-workers, family and friend on staying well: