Introduction

In .NET Framework 4.5, you should not assume that secure outbound connections will automatically negotiate modern TLS versions the way newer runtimes do. The practical point is that .NET 4.5 predates the later "use the operating system defaults" behavior, so if you care about TLS 1.2-level compatibility, you usually need to think about ServicePointManager.SecurityProtocol explicitly.

What SecurityProtocol Controls

When older .NET code uses APIs such as HttpWebRequest, the runtime looks at ServicePointManager.SecurityProtocol to decide which SSL or TLS protocol versions are allowed for new outbound connections.

Typical values include:

• 'Ssl3'
• 'Tls'
• 'Tls11'
• 'Tls12'

The confusing part is that support and default behavior are not the same thing. A runtime may understand a protocol enum value without using it by default.

The Important Practical Answer

For baseline .NET 4.5 behavior, do not assume TLS 1.2 is automatically enabled. Older applications often negotiate older protocols unless you opt into newer ones or move to later framework behavior.

That is why many developers working against modern HTTPS endpoints add an explicit setting such as:

using System.Net;

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

That line is often the difference between a successful HTTPS call and a handshake failure against servers that no longer accept older protocols.

Why the Default Causes Confusion

There are two separate questions:

1. Which protocol enum values does the framework know about?
2. Which protocols will an app use if you do nothing?

Developers often read that .NET 4.5 supports Tls11 and Tls12 and conclude that the runtime will automatically use them. That is not a safe assumption. In practice, older framework versions often need explicit configuration, and operating system patch level can also affect what is actually possible at runtime.

So the reliable engineering guidance is simple: if your application must talk to modern HTTPS endpoints, set the protocol you require or move to a newer framework that delegates protocol selection more intelligently.

Example

A minimal example looks like this:

1using System;
2using System.IO;
3using System.Net;
4
5class Program
6{
7    static void Main()
8    {
9        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
10
11        var request = WebRequest.Create("https://example.com");
12        using var response = request.GetResponse();
13        using var stream = response.GetResponseStream();
14        using var reader = new StreamReader(stream);
15
16        Console.WriteLine(reader.ReadToEnd());
17    }
18}

The important part is not the web request itself. It is the fact that the allowed protocol set is established before the request is made.

Later Framework Versions Behave Differently

This topic is often mixed up with later .NET Framework behavior. Much newer framework versions moved toward relying on operating system defaults more directly, which changed the guidance.

That means advice that is correct for .NET Framework 4.7 or newer is not automatically correct for .NET 4.5. When reading old Stack Overflow answers or vendor documentation, always check which framework version the advice assumes.

Server Compatibility Still Matters

Even if you explicitly request TLS 1.2, the server must support it and the operating system must have the necessary underlying support enabled. The client and server have to negotiate a mutually supported protocol version.

So when debugging handshake failures, think in layers:

• framework version
• explicit SecurityProtocol setting
• operating system TLS support
• server-side accepted protocols

Common Pitfalls

• Assuming .NET 4.5 will automatically negotiate TLS 1.2 just because the enum exists leads to fragile production behavior.
• Copying guidance from newer framework versions into older applications can produce the wrong conclusion about defaults.
• Setting insecure protocol combinations for compatibility can reopen protocols that modern servers rightly reject.
• Forgetting that operating system support also matters can make a correct-looking code change appear ineffective.
• Treating protocol support and protocol default as the same thing causes most of the confusion around this topic.

Summary

• In .NET 4.5, do not assume modern TLS versions are used automatically by default.
• 'ServicePointManager.SecurityProtocol controls which protocols older networking APIs may use.'
• If your app must talk to modern HTTPS services, explicitly enabling Tls12 is common and often necessary.
• Support for a protocol and default use of that protocol are different questions.
• Always check framework version, OS support, and server policy together when debugging TLS issues.