rss.livelink.threads-in-node

How to Add an Adaptive Card in Microsoft 365 Agent SDK

meenakshiBalekar — Wed, 01 Apr 2026 01:12:58 GMT

One of the most important UI capabilities is Adaptive Cards, which let your agent send structured, interactive content such as forms, inputs, buttons, and layouts.

In this guide, you’ll learn exactly how to:

Create an Agent SDK bot
Send an Adaptive Card when a user joins
Handle Action.Execute submit events
Parse user input from the card
Respond with text

I will walk through the full working code from my project.

You can download complete sample from : M365AgentSDKAdaptiveCard

Step 1: Understanding How Adaptive Cards Work in Agent SDK

Adaptive Cards are sent in the Agent SDK using:

var attachment = new Attachment { ContentType = "application/vnd.microsoft.card.adaptive", Content = <JSON> };

You then send them like this:

await turnContext.SendActivityAsync(MessageFactory.Attachment(attachment));

And to handle submit actions (Action.Execute), the Agent SDK triggers:

ActivityTypes.Invoke Name = "adaptiveCard/action"

Step 2: Use the Adaptive Card Designer

Create or test your card on our new designer here: https://adaptivecards.microsoft.com/designer

Your sample card:

Collects name & age
Uses Action.Execute with verb "personalInfo"

Step 3: The Full Working Agent SDK Code

Below is the complete working implementation showing:

✔ Welcome card using Adaptive Card
✔ Parsing Action.Execute values
✔ Responding back to the user

This is based entirely on your code, cleaned up and rewritten for clarity & correctness.

Complete Agent SDK Bot with Adaptive Card

using Microsoft.Agents.Builder; using Microsoft.Agents.Builder.App; using Microsoft.Agents.Builder.State; using Microsoft.Agents.Core.Models; using Microsoft.Extensions.Hosting; using Microsoft.Extensions.Logging; using System.Text.Json; using System.Text.Json.Nodes; using System.Threading; using System.Threading.Tasks; namespace MyFirstAgentSDK.Bot; public class EchoBot : AgentApplication { public EchoBot(AgentApplicationOptions options, IHostEnvironment env, ILoggerFactory loggerFactory) : base(options) { OnConversationUpdate(ConversationUpdateEvents.MembersAdded, WelcomeMessageAsync); OnActivity(ActivityTypes.Message, OnMessageAsync, rank: RouteRank.Last); OnActivity(ActivityTypes.Invoke, OnInvokeAsync); } private async Task WelcomeMessageAsync(ITurnContext turnContext, ITurnState turnState, CancellationToken cancellationToken) { foreach (ChannelAccount member in turnContext.Activity.MembersAdded) { if (member.Id != turnContext.Activity.Recipient.Id) { var attachment = new Attachment { ContentType = "application/vnd.microsoft.card.adaptive", Content = """ { "type": "AdaptiveCard", "version": "1.4", "schema": "http://adaptivecards.io/schemas/adaptive-card.json", "body": [ { "type": "Container", "items": [ { "type": "TextBlock", "text": "Please enter your personal information", "weight": "Bolder", "size": "Medium", "color": "Accent" }, { "type": "Input.Text", "id": "Name", "label": "What's your name?", "placeholder": "Enter your full name", "maxLength": 50, "isRequired": true, "errorMessage": "Name is required" }, { "type": "Input.Number", "id": "Age", "label": "How old are you?", "placeholder": "Enter your age", "min": 1, "max": 150, "isRequired": true, "errorMessage": "Please enter a valid age between 1 and 150" } ], "style": "emphasis", "spacing": "Medium" } ], "actions": [ { "type": "Action.Execute", "title": "Submit", "verb": "personalInfo", "style": "positive" } ] } """ }; await turnContext.SendActivityAsync(MessageFactory.Attachment(attachment), cancellationToken); } else { await turnContext.SendActivityAsync(MessageFactory.Text("Hello and Welcome!"), cancellationToken); } } } private async Task OnMessageAsync(ITurnContext turnContext, ITurnState turnState, CancellationToken cancellationToken) { await turnContext.SendActivityAsync($"You said: {turnContext.Activity.Text}", cancellationToken: cancellationToken); } private async Task OnInvokeAsync(ITurnContext turnContext, ITurnState turnState, CancellationToken cancellationToken) { if (turnContext.Activity.Name == "adaptiveCard/action") { JsonElement root; if (turnContext.Activity.Value is JsonElement element) { root = element; } else { var json = JsonSerializer.Serialize(turnContext.Activity.Value); root = JsonDocument.Parse(json).RootElement; } if (root.TryGetProperty("action", out var action)) { if (action.TryGetProperty("verb", out var verbElement) && verbElement.GetString() == "personalInfo") { if (action.TryGetProperty("data", out var data)) { var name = data.GetProperty("Name").GetString(); var age = data.GetProperty("Age").ToString(); await turnContext.SendActivityAsync(MessageFactory.Text($"Hello {name}, you are {age} years old!"), cancellationToken); var invokeResponse = new Activity { Type = ActivityTypes.InvokeResponse, Value = new InvokeResponse { Status = 200 } }; await turnContext.SendActivityAsync(invokeResponse, cancellationToken); } } } } } }

Step 4: What This Code Does

1. Sends an Adaptive Card when a new user joins or as per your criteria

The card that I have used includes:

Text
Name input (required)
Age input (required)
A submit button with verb "personalInfo"

2. When the user clicks Submit

Teams / Message Extension sends:

invoke name = adaptiveCard/action

OnInvokeAsync() receives:

{ "action": { "verb": "personalInfo", "data": { "Name": "...", "Age": "..." } } }

3. Bot parses and sends a text response

Example output:

Hello Meenakshi, you are 30 years old! ( P.S I am older than this )

Locally when you run the project on playground it looks like :

This is how it looks on test in webchat

And this how it looks on teams :

4. Responds with 200 status

This is required for Teams & M365:

var invokeResponse = new Activity { Type = ActivityTypes.InvokeResponse, Value = new InvokeResponse { Status = 200 } }; await turnContext.SendActivityAsync(invokeResponse, cancellationToken);

Conclusion

With the Microsoft 365 Agent SDK:

Action.Execute events are handled inside OnInvokeAsync
Inputs are parsed through the Activity.Value JSON payload
The SDK is lightweight and much simpler than the old Azure Bot SDK

Your bot is now fully capable of collecting structured user input using Adaptive Cards.

Drop in any queries or samples that you would like me to explain.

Happy Learning!

Let's Create Our First Microsoft 365 Agent SDK using Python - For Single Tenant

meenakshiBalekar — Wed, 01 Apr 2026 01:12:42 GMT

Step 1: Set Up Your Development Environment

I am using VS Code, so you don’t need to manually install Python on your system (unless you want to).
VS Code can handle Python via extensions which makes it super easy and everything at once place.

You can download complete sample : here

Install These Extensions in VS Code

Open VS Code → Extensions → install:

Python (Microsoft)
Dev Tunnels (optional but helpful)
GitHub Pull Requests & Issues ( Saves a lot of Download time)

These ensure:

You can run Python files directly inside VS Code
IntelliSense / linting works
Dev tunnel commands work in the integrated terminal

Step 2: Download/Clone the Official Sample

I am using this exact sample: Agent SDK Python Cards

Run these commands inside VS Code Terminal:

git clone https://github.com/microsoft/Agents.git cd Agents/samples/python/cards

You now have the complete working Python Agent sample.

Step 3: Install All Required Packages

Inside the cards folder, run:

pip install -r requirements.txt

This installs:

FastAPI
Uvicorn
Agents SDK
dotenv

VS Code will automatically detect and configure a Python interpreter for you. Once done, your requirements.txt file will look like :

Step 4: Add Your M365 Agent Configuration

Inside the folder, you’ll see:

.env.TEMPLATE

Rename it to:

.env

Then open the file and fill in:

CONNECTIONS__SERVICE_CONNECTION__SETTINGS__CLIENTID= CONNECTIONS__SERVICE_CONNECTION__SETTINGS__CLIENTSECRET= CONNECTIONS__SERVICE_CONNECTION__SETTINGS__TENANTID=

Here I am creating a single tenant bot, hence I am suing these settings for MSI it will be different
You can refer the different type of available authentication types here

Python -m src.main

Where do these values come from?
Your Azure portal -> App Registration/ Managed Identity ( Depending on what type of application is created)

Step 5: Run the M365 Agent Locally

Start your Agent:

Python -m src.main

You will see :

But you will not be able to test the bot here locally, so we would need additional tools to help us test locally.

Step 6: Create a Dev Tunnel

You must expose your local bot over HTTPS.
For that we use devtunnel.

Step 6.1 — Authenticate devtunnel

You must authenticate first or you’ll get:

Unauthorized tunnel creation access

So run:

devtunnel user login

A browser pops up -> Sign in with the same Microsoft account used for your M365 Agent.

Step 6.2 — Create the Tunnel

Now run:

devtunnel host -p 3978 --allow-anonymous

You will get a public HTTPS URL like:

Copy this URL and we can test the bot in Azure bot service

Step 7: Update the M365 Agent Endpoint in Portal

Go to your Azure portal → ABS Agent → Settings → Endpoint URL
Paste: <tunnel-url>/api/messages

Click Save.

At this point:

Your Agent is running locally
Your tunnel is publishing it
You will be able to can talk to your Agent

Step 8: Test the Agent (The Fun Part)

Go to your Azure bot service → Test in Web Chat.

Type:

hello

You should get back the card responses from the sample.

If the sample sends Adaptive Cards or text messages, you will see them appear here exactly as coded.

That's It! You Built Your First Python M365 Agent

This guide took you from:
✔ VS Code setup
✔ Python environment extensions
✔ Cloning the sample
✔ Adding env configuration
✔ Running the Agent
✔ Creating a dev tunnel
✔ Testing in Web Chat

Happy Learning!

Resolving Weak SSL Ciphers in .NET Framework 4.5

Goyal_Sandeep — Wed, 01 Apr 2026 01:12:12 GMT

Symptom

Applications built on the .NET Framework 4.5 may fail to establish secure HTTPS connections or may default to outdated and insecure protocols. This can result in connection failures, browser security warnings, or rejection by modern APIs and services that require stronger encryption standards like TLS 1.2 or higher.

Cause

.NET framework 4.5 is out of support and hence it does not use the latest cryptography mechanisms, we strongly recommend building apps in supported frameworks. Add the support lifecycle article there

.NET Framework official support policy | .NET

Resolution

The most robust fix is to upgrade your application to .NET Framework 4.6, 4.7 or later, where TLS 1.2 is enabled by default. This ensures your application uses stronger cipher suites and secure protocols automatically, without requiring additional configuration.

After installing the newer .NET Framework on your development or production environment, update your project’s target framework and recompile. For ASP.NET applications, update your Web.config file to reflect the new framework version. For example, if upgrading to .NET 4.6:

<system.web>

</system.web>

This change, along with rebuilding your application under the updated framework, ensures that IIS and the .NET runtime use the latest libraries. Once deployed, your application will negotiate HTTPS connections using TLS 1.2 by default, resolving issues related to weak or unsupported cipher protocols.

IIS setup a web site to be accessed without a domain name....how?

Gregary — Thu, 08 Jan 2026 10:51:25 GMT

I want to setup a web site for testing without a domain name.
I have 3 web sites with domain name that are working fine.
I am working on a web site for Millhouse and they already have an existing web site with the domain name millhouse.org.au

I want to setup their new web site on my web server for testing purposes and so member of the organisation can view it (as http) to assess it.
I want to be able access it like this: 58.168.225.214:8080
But what I have done so far isn't working:

I have setup port fording in my modem with WAN and LAN ports of 8080.

And 8080 as the port in the web site settings in IIS.

IIS Site Randomly Returns 404 While App Pool Remains Started

captainit — Fri, 26 Dec 2025 21:17:14 GMT

Hello,

We have an IIS site running behind Azure Front Door that becomes unavailable every few days.

Symptoms:

Application Pool remains started

Users see the blue "Not Found" page from Azure Front Door

When accessing the site directly on the server during the failure, we get a 404 from IIS, not Front Door

The site does not recover on its own

Recovery requires an App Pool recycle or IIS restart, and sometimes a full server reboot because recycle or IIS restart does not help

What it is NOT:

No CPU, memory, disk, or network pressure

Event logs do not correlate with the outage

When it happens:

Random and unpredictable

Any insights would be appreciated.

From the server itself:

Please your support.

Azure Bot Identity | Application with identifier 'x' was not found in the directory 'Bot Framework'

manojdixit — Fri, 05 Dec 2025 14:42:50 GMT

TL;DR

Every Azure Bot has a fixed identity (MicrosoftAppId) tied to either an App Registration or a Managed Identity—it cannot be changed or reused.
Azure Bot supports three identity types:
- User-Assigned Managed Identity
- Single-Tenant App Registration
- Multi-Tenant App Registration (deprecated after July 31, 2025)
Bots involve three auth flows:
1. Client → Channel (platform-specific)
2. Channel ↔ Bot (core system auth using OAuth2 + Entra ID)
3. User sign-in (optional; uses Authorization Code Flow)
The error “AADSTS700016: Application with identifier 'xxx' was not found in the directory 'Bot Framework'” happens when the Bot application tries to request tokens from the botframework.com tenant instead of its home tenant while the App registration is set as SingleTenant.
BotFrameworkAdapter Class (Microsoft.Bot.Builder) | Microsoft Learn is hardcoded to the Bot Framework tenant and does not work with Single-Tenant or Managed Identity bots. In Bot-Builder SDK (retires after Dec 2025), CloudAdapter Class (Microsoft.Bot.Builder.Integration.AspNet.Core) | Microsoft Learn supports SingleTenant and UserAssigned-MSI bots and MicrosoftAppType needs to be configured to reflect the correct Bot Identity.
With announcement of the Bot-Builder SDK deprecation, we recommend moving to The M365 Agents SDK which retains many Bot Builder concepts with ability to create next generation Agents with orchestration, observability and more secure options authentication. This also offers flexible and more secure options for token aquisition.

Skip directly to the "Channel (2) ↔ Bot (3) Authorization" section if you want to understand why the error occurs.

Azure Bot Identity

Every Azure Bot Service has a unique Id (also known as MSAAppId or MicrosoftAppId) which you can find in Azure Portal -> Azure Bot Resource -> Configuration if the Bot is created:

This MSAAppId corresponds to either the Client ID of Application Registration in Microsoft Entra ID or Managed Identity in Azure . This is Id is tied to the respective Bot Service from creation until deletion, cannot be modified or reused for a different Bot resource. Closely related to this is the concept of the Azure Bot Identity Type and can be one of the following:

User-assigned managed identity - identity tied to a Managed Identity in Azure
Single-tenant - identity tied to an Application Registration in Microsoft Entra ID with Supported account types = Accounts in this organizational directory only
- Reference - How to register an app in Microsoft Entra ID - Microsoft identity platform | Microsoft Learn
Multi-Tenant (Deprecated – ends July 31, 2025) - identity tied to an Application Registration in Microsoft Entra ID with Supported account types = Accounts in any organizational directory
- Reference - Microsoft Identity Platform Glossary - Microsoft identity platform | Microsoft Learn

References:

Create an Azure Bot resource in the Azure portal - Bot Service | Microsoft Learn

Identity and Authorization

As described in Navigating Azure Bot Networking: Key Considerations for Privatization, an Azure Bot Solution consists of below components:

Clients (1): User-facing application used to consume/converse with Bot solutions. Examples include Web Chat Widget, Teams, Slack etc.
The Bot Service: This managed SaaS umbrella includes configuration management, channel services and token services. Services are made available with the <service>.botframework.com endpoints.
The Bot Application (2): Using the Bot/Agents SDK or Composer, you create an HTTP-based application that encapsulates your functional and conversational logic, including recognition, processing, and storage. The Bot application operates using the Bot Framework Activity Specification. The Bot application exposes a public messaging endpoint for receiving activities (messaging endpoint).
Channel Connectors (3): While Azure Bot Service provides two native channels—Direct Line and Web Chat—it is designed to be highly extensible and supports integration with additional clients and communication platforms through external channels. These channels are implemented and operated by their respective providers and run within their own managed data centers. The bot’s messaging endpoint is not exposed directly to end users; instead, users interact with the bot via channel connectors, which handle session management, activity routing, and authentication on behalf of the client. Different clients, such as Teams and Slack, represent messages and activities uniquely. Since Bot applications understands and responds with activities as defined in the Bot Framework Activity Specification, channels are responsible for transforming activities and forwarding them to the application.

There are 3 Authentication/Authorization flows in a Bot solution.

Client (1) to Channel (2) Authentication - This flow is platform-specific and is implemented by the channel owner. It governs how an end-user or client application authenticates with the channel before any interaction reaches the bot. For example, the Direct Line channel requires a token or secret to establish trust, as described in Direct Line Authentication in Azure AI Bot Service - Bot Service | Microsoft Learn
Channel (2) <-> Bot (3) Authorization - This flow is channel-independent and is consistent across all Azure Bot channels. Communication between the channel and the bot occurs via bi-directional HTTPS calls secured using OAuth2 JWT Access Tokens issued by Microsoft Entra ID. Both the channel and the bot validate each other by exchanging these tokens. This mechanism is what directly relies on the Azure Bot Identity type (Managed Identity, Single-Tenant App, or legacy Multi-Tenant App) and is the primary focus of this blog.
User Authentication - This is an optional flow enables end users to authenticate within the chat experience so the bot can identify the user, access protected user data or perform actions on the user’s behalf (e.g., schedule meetings, access emails). User authentication is implemented using the "Authorization Code Flow" and supports multiple identity providers, including Microsoft Entra ID. When Entra ID is used, the bot can authenticate users using the same App Registration as the bot identity, or a separate App Registration, depending on security and design requirements. This user sign-in process is independent of the Channel-to-Bot authorization flow and is not affected by the bot’s identity type.

- References:
  - Add authentication to a bot in Bot Framework SDK - Bot Service | Microsoft Learn
  - Flow Diagram - botframework-sdk - In a brief:
    - The Bot application checks whether a user access token already exists in the Azure Bot Token Store.
    - If no token is found, the bot challenges the user to sign in within the chat interface. Some channels, such as Microsoft Teams, also support SSO - Enable SSO with Microsoft Entra ID - Teams | Microsoft Learn
    - The issued token is then securely stored in the Azure Bot Token Store.
    - The user is redirected to the configured Identity Provider (for example, Microsoft Entra ID) and authenticates successfully.
    - The Bot application retrieves the token from the Token Store and uses it to access protected resources or perform actions on the user’s behalf.

Channel (2) <-> Bot (3) Authorization

As we see in the "Outbound Flow: Bot to Channel", the Bot Application typically uses OAuth 2.0 client credentials flow on the Microsoft identity platform - Microsoft identity platform | Microsoft Learn. The token authority (endpoint) used for this flow depends on the Bot Identity Type, as documented in Authenticate requests with the Bot Connector API - Bot Service | Microsoft Learn.

The error "Application with identifier 'xxx' was not found in the directory 'Bot Framework'" happens when:

The Bot’s Application Registration is configured as Single-Tenant
(Supported account types = Accounts in this organizational directory only)
The Bot application requests a token from the Bot Framework tenant:
- https://login.microsoftonline.com/botframework.com/oauth2/v2.0/token
Since the App Registration is Single-Tenant, only the home tenant can issue tokens.
The Bot Framework tenant is not the home tenant → token issuance fails.

All the operations shown in diagram except business logic is automatically handled by the SDK (BotSDK or AgentsSDK) but the Developer gets control correct token endpoint.

Bot SDK automatically infers the token endpoint/Authority based on the configuration:
- If you are using BotFrameworkAdapter Class (Microsoft.Bot.Builder) | Microsoft Learn - it will always make calls to "https://login.microsoftonline.com/botframework.com/oauth2/v2.0/token". Thus, it cannot work with SingleTenant or UserAssigned MSI Bot.
- If you are using CloudAdapter Class (Microsoft.Bot.Builder.Integration.AspNet.Core) | Microsoft Learn, it supports configuring the Bot Identity using the MicrosoftAppType. Review samples to understand how this is configured for different runtimes:
  - BotBuilder-Samples/samples at main · microsoft/BotBuilder-Samples · GitHub
  - BotBuilder-Samples/samples/csharp_dotnetcore/02.echo-bot/appsettings.json at main · microsoft/BotBuilder-Samples · GitHub
M365 Agents SDK - This is a successor of Bot SDK and will be the only supported SDK after December 2025:
- The Identity configuration is flexible and simplified in Agents SDK. The concepts remain same, appropriate token endpoint/authority needs to be used.
  - Configure authentication in a .NET agent | Microsoft Learn
  - Agents/samples at main · microsoft/Agents · GitHub

Migration fromMultiTenant SingleTenant to in the Bot code:

With announcement of the Bot-Builder SDK deprecation, we recommend moving to Agents SDK which retains many Bot Builder concepts with ability to create next generation Agents with orchestration, observability and more secure options authentication.
- GitHub - microsoft/botframework-sdk: Bot Framework provides the most comprehensive experience for building conversation applications.
- Azure Bot Framework SDK to Microsoft 365 Agents SDK migration guidance | Microsoft Learn
For Bot SDK to work with SingleTenant, you must use CloudAdapter Class (Microsoft.Bot.Builder.Integration.AspNet.Core) | Microsoft Learn and configure correct MicrosoftAppType.

I hope it helps.

Addressing .Net EOL installations for Windows Admins

manojdixit — Fri, 28 Nov 2025 13:53:53 GMT

TL; DR:

Installing the latest .NET runtime on a server does not upgrade existing applications that are built on unsupported versions (for example, anything older than .NET 8 as of Nov 2025). Applications must be explicitly upgraded through a full development lifecycle—retargeting the project to a supported framework, updating dependencies, rebuilding, testing, and redeploying.

This is not something a Windows administrator can safely perform alone. However, admins can and should identify which applications are running on EOL .NET versions and coordinate with development teams to ensure they are upgraded to a supported release.

.NET vs .NET Framework: Understanding the Difference

Unlike the classic .NET Framework, modern .NET (formerly .NET Core) is not an integral part of the Windows operating system. It is typically installed on-demand when an application requires it. This means multiple .NET versions can coexist on the same system without automatically affecting each other.

Modern .NET is:

Cross-platform (Windows, Linux, macOS)
Open source
Designed for rapid evolution and cloud-native development

Because of these design goals, modern .NET follows a fixed annual release cadence with defined support timelines.

Official documentation:

End of Life (EOL)

As a .NET version approaches End of Life (EOL), Microsoft recommends upgrading to a supported version and reducing dependency on the expiring runtime. After EOL:

Security updates stop
Bug fixes stop
Microsoft technical support ends
Compliance and audit risks increase

Microsoft strongly discourages continued use of unsupported runtimes:

Using out-of-support .NET versions may expose your applications, data, and environment to security vulnerabilities and operational failures.

EOL is also referred to as End of Support (EOS).

Why Security Tools Flag EOL .NET Installations

Once a .NET runtime reaches EOL, vulnerability scanners and endpoint security software often flag it as a risk and recommend removal. Even if your tools do not explicitly report it, proactive removal and upgrade is still best practice.

Before uninstalling, however, administrators typically ask:

What will break if I remove this version?
Can I just install the latest .NET to replace it?
Which applications are dependent on this runtime?
Can I safely remove it if nothing appears to use it?

Here is a general workflow that can be used to address the above questions:

Step 1 – Identify Applications Using EOL ASP.NET / .NET Runtimes

Important: The steps below identify only the applications actively running at the time of execution. Any dormant services, scheduled tasks, or rarely used applications may still depend on EOL .NET but will not appear until they are executed.

To identify currently running applications that are using the .NET runtime, you can use Sysinternals ListDLLs from Microsoft.
Download ListDLLs - Sysinternals | Microsoft Learn and run the following command from an elevated (Administrator) CMD prompt:

listdlls.exe -d coreclr.dll -accepteula -vSample output of listdll command

This will show all the dotnet processes (with versions 6/7 or 8 or previous) along with version of .Net runtime loaded (coreclr). Make a note of processes that are loading EOL .Net versions - .NET and .NET Core official support policy.

Note - coreclr is the Dotnet runtime dll which will be loaded in a .Net process. The listdll shows a specific version loaded by respective process, that would help identify processes using EOL .Net runtime.

Reference - CoreCLR is now Open Source - .NET Blog

Step 2 - Reach to the developers to upgrade the Application to supported version:

Applications do not automatically upgrade to a newer .NET version simply because a supported runtime is installed on the server. Each application must be rebuilt and retargeted to explicitly use the newer framework version.
The upgrade process typically follows a full software development lifecycle (SDLC), including:
- Retargeting the project to the latest supported .NET version
- Updating NuGet packages and dependencies
- Fixing breaking changes
- Rebuilding the application
- Functional and regression testing
- Deployment to production
This process is not something a Windows administrator can safely perform alone. It requires access to the application source code and ownership from the development or product team. Administrators should focus on identifying incompatible or EOL runtimes and coordinating with application owners to plan upgrades.
Reference:
- Upgrade to a new .NET version - .NET | Microsoft Learn

Step 3 – Confirm No Applications Are Using EOL .NET Runtimes

After application owners have upgraded and deployments are completed, you must verify that no processes are still running on unsupported .NET runtimes.

Repeat the same process from Step 1 to re-scan the system:

Step 4 – Uninstall / Remove EOL .NET Runtimes

Once you confirmed no dependency on the EOL products you can proceed with uninstall.
Note that .Net apps can be self-contained or framework-dependent:
- .NET application publishing overview - .NET | Microsoft Learn
- Publish self-contained
  This mode produces a publishing folder that includes a platform-specific executable used to start the app, a compiled binary containing app code, any app dependencies, and the .NET runtime required to run the app. The environment that runs the app doesn't need to have the .NET runtime preinstalled.
- Publish framework-dependent
  This mode produces a publishing folder that includes an optional platform-specific executable used to start the app, a compiled binary containing app code, and any app dependencies. The environment that runs the app must have a version of the .NET runtime installed that the app can use.
  - Framework dependant apps will use the shared runtimes that you may have installed from Download .NET (Linux, macOS, and Windows) | .NET.
- For self-contained apps, the developer must provide a latest package with supported runtimes.
Of course, to anticipate failure, please have back up/recovery plans and execute the actions during a downtime as per your company policies.

I hope this helps.

HTTPS Reverse Proxy on IIS 10 – External Access Fails (Timeout) Although Local Requests Work

raysefo — Sat, 22 Nov 2025 20:03:22 GMT

Hello everyone,

I’m currently facing an issue with an IIS 10 reverse proxy configuration on Windows Server, and I would really appreciate your guidance.

Environment

Windows Server

IIS 10

Application Request Routing (ARR) + URL Rewrite enabled

Backend application running on:

http://localhost:8080/ http://localhost:8080/login

Public domain:

https://lojistik.abc.com.tr

What I want to achieve

I want users to access the backend web application through the following URL:

https://lojistik.abc.com.tr/LMYS/login

Internally, IIS should proxy this to:

http://localhost:8080/login

What works

The backend application is accessible without issues:

http://localhost:8080/login

From the server itself, reverse proxy works:

Invoke-WebRequest "https://lojistik.abc.com.tr/LMYS/login"

→ StatusCode: 200 (success)

What does NOT work

From any client machine, the following request results in a timeout:

https://lojistik.abc.com.tr/LMYS/login

Browser shows connection timeout.

No entry appears in IIS logs for external requests to /LMYS/....

Tests performed

▪ netstat -ano | findstr :443 on the server → Port 443 is listening ▪ DNS resolves correctly:

lojistik.abc.com.tr → 10.6.130.90

▪ Reverse proxy rule on IIS is correctly configured under the HTTPS binding site:

Pattern: ^LMYS(/.*)?$ Rewrite to: http://localhost:8080{R:1}

▪ ARR Server Proxy is enabled.

Key observation

Requests from the server itself succeed (reverse proxy returns 200), but external clients always time out, which suggests that the HTTPS traffic is not reaching IIS at all (likely blocked or not NAT-forwarded on the network path).

Question

What could cause HTTPS (port 443) traffic to reach IIS locally, but external requests to the same port to hang indefinitely?

Any guidance would be greatly appreciated.

Thank you in advance.

Best regards,

Why Does an Old Certificate Reappear After Reboot in Azure VMs?

Shekhar — Wed, 29 Oct 2025 16:02:22 GMT

Issue Observed

A customer removed an expired SSL certificate from their Azure VM after installing a renewed one. However, after every reboot, the old certificate reappeared, and IIS site bindings automatically started picking it up.

Investigation Steps

1. Identify the Process Bringing Back the Certificate

To trace the root cause, we configured Sysmon following this guide:
Auditing Scenarios for Web Application Hosted in IIS - Part 1 - SSL Binding Modified | Microsoft Community Hub

We asked the customer to remove the certificate and reboot the server to reproduce the issue.
After rebooting, the certificate was reinstalled. Event logs revealed a process named akvvm_service.exe was responsible for bringing the certificate back.

Following is the screenshot from the event log:

I then checked the task manager to check about the process (7964) and see following:

2. What is akvvm_service.exe?

akvvm_service.exe is the service executable for the Azure Key Vault VM extension.
Purpose of this service:
- Monitors certificates stored in Azure Key Vault that the VM is configured to observe.
- Automatically downloads, installs, and refreshes those certificates into the Windows certificate store (e.g., LocalMachine\My) at a defined polling interval:
  - Azure Key Vault VM extension for Windows - Azure Virtual Machines | Microsoft Learn

3. Why Was This Happening?

The customer had multiple certificates in their Key Vault. The VM extension KeyVaultForWindows was pulling all configured certificates back into the server during every reboot.

To check the extensions:
Go to Azure VM -> Search for Extensions -> Select Extensions + applications:

We see all the Extensions + applications configured with the VM and here we see this extension KeyVaultForWindows configured:

Further checks revealed:

Issue was only happening in DEV, TEST and STG environment and not in PROD

DEV, TEST, and STG environments had the KeyVaultForWindows extension installed.
PROD environment did not have this extension, which explained why the issue was isolated to non-PROD environments.

Resolution

We shared the following action plan:

Option 1: Uninstall the Key Vault VM extension to match the PROD setup.
Option 2: Delete or disable certificates that are no longer required in Key Vault.

The customer chose Option 2 and confirmed:

“Disabling expired certificates within Key Vault fixed the issue.”

Key Takeaways

If old certificates reappear after reboot, check for Azure Key Vault VM extension.
This extension automatically syncs certificates from Key Vault to your VM.
To prevent unwanted certificates:
- Remove the extension if not needed.
- Or disable/delete unnecessary certificates in Key Vault.

IIS app pool in-memory cache miss

indrajit — Fri, 03 Oct 2025 16:56:02 GMT

Hi,

Our IIS server runs on windows 2016 servers, recently we are experiencing frequent miss from in-memory cache, and instead of connecting to NCache which is our cache solution, it is sending request to database. After lots of debug we still could not identify the issue here. But as a best practice we are going to change some setting. But, one suggestion is to change max worker count from 4 to 1. Will that impact our performance? How much will it be effective to bring that value to 1 from 4, in terms of single worker cache miss issue occurrences?

Troubleshooting File Upload Error: 413 Request Body Too Large in .NET Core

Goyal_Sandeep — Tue, 02 Sep 2025 16:25:30 GMT

Troubleshooting File Upload Error: 413 Request Body Too Large in .NET Core

When working with file uploads in .NET Core, you might encounter the 413 "Request Body Too Large" error even if the maxAllowedContentLength value in your web.config file is correctly set. This issue can be perplexing, especially when all configurations seem to be in place. In this blog, we will explore a common cause of this error related to the ASPNETCORE_TEMP environment variable and how to resolve it.

Understanding the Issue

The 413 error indicates that the request body size exceeds the server's configured limit. Typically, this is controlled by the maxAllowedContentLength setting in the web.config file. However, if the ASPNETCORE_TEMP environment variable is incorrectly set, it can lead to this error despite having the correct maxAllowedContentLength value.

Scenario

Let's consider a scenario where the maxAllowedContentLength in the web.config file is set to 50 MB, but the application still throws a 413 error for files larger than 10 MB. Upon investigation, it is found that the ASPNETCORE_TEMP environment variable is incorrectly configured in the launchSettings.json file.

Steps to Resolve the Issue

Verify maxAllowedContentLength in web.config: Ensure that the maxAllowedContentLength value in your web.config file is correctly set according to your requirements. For example:

<system.webServer>

</requestFiltering>

</security>

</system.webServer>

Check ASPNETCORE_TEMP Environment Variable: The ASPNETCORE_TEMP environment variable specifies the location where ASP.NET Core stores temporary files, such as those used for buffering large request bodies. If this variable is incorrectly set, it can cause the 413 error.
Update launchSettings.json: Ensure that the ASPNETCORE_TEMP environment variable is correctly configured in the launchSettings.json file. Here is an example of how to set it:

{

"profiles": {

"IIS Express": {

"commandName": "IISExpress",

"launchBrowser": true,

"environmentVariables": {

"ASPNETCORE_ENVIRONMENT": "Development",

"ASPNETCORE_TEMP": "C:\\Temp\\ASPNETCORE"

}

"YourProjectName": {

"commandName": "Project",

"dotnetRunMessages": true,

"launchBrowser": true,

"applicationUrl": "https://localhost:5001;http://localhost:5000",

"environmentVariables": {

"ASPNETCORE_ENVIRONMENT": "Development",

"ASPNETCORE_TEMP": "C:\\Temp\\ASPNETCORE"

}

Verify the Temporary Directory: Ensure that the directory specified in the ASPNETCORE_TEMP environment variable exists and has the necessary permissions for the application to write temporary files.

Example Case

In a recent support case, the maxAllowedContentLength was set to 50 MB in the web.config file, but the application was still throwing a 413 error for files larger than 10 MB. Upon checking, it was found that the ASPNETCORE_TEMP environment variable was set to an incorrect path in the launchSettings.json file. Correcting the path resolved the issue.

Conclusion

By ensuring that the ASPNETCORE_TEMP environment variable is correctly set and the maxAllowedContentLength value in the web.config file is appropriate, you can resolve the 413 "Request Body Too Large" error in your .NET Core application. Proper configuration of these settings ensures smooth handling of large file uploads without encountering size-related errors.

If you have any further questions or need additional assistance, feel free to reach out!

Enabling Client Certificate Authentication for an Application Inside Default Web Site

Goyal_Sandeep — Tue, 02 Sep 2025 16:25:14 GMT

Enabling Client Certificate Authentication for an Application Inside Default Web Site

In this blog, we will explore how to enable client certificate authentication for a specific application hosted inside the Web Site in IIS, while keeping client certificate authentication disabled at the Web Site level. This configuration is useful when you want to secure only a particular application with client certificates, without affecting the entire site.

Understanding the Scenario

Imagine you have a Web Site in IIS that hosts multiple applications. You want to enable client certificate authentication for one specific application, but not for the entire Web Site. This setup ensures that only the designated application requires client certificates for access, while the rest of the site remains accessible without this additional layer of security.

Step-by-Step Configuration

Install IIS Client Certificate Mapping Authentication:

Open Server Manager.
Click on Manage and then Add Roles and Features.
In the Add Roles and Features Wizard, click Next until you reach the Server Roles page.
Expand Web Server (IIS), then Web Server, then Security.
Select IIS Client Certificate Mapping Authentication and click Next.
Complete the wizard and click Install

Configure SSL Settings at the Application Level:

Launch IIS Manager and navigate to your Default Web Site.
Select the specific application for which you want to enable client certificate authentication.
In the Features View, double-click on SSL Settings.
Check Require SSL and Require under Client Certificates

Disable Client Certificate Authentication at the Web Site Level:

In IIS Manager, select the Default Web Site.
Go to SSL Settings.
Ensure that Require SSL and Client Certificates are not checked

Configure Client Certificate Mapping Authentication:

Select the specific application in IIS Manager.
In the Features View, select Configuration Editor under the Management section.
Navigate to system.webServer/security/authentication/iisClientCertificateMappingAuthentication.
Set the enabled field to true.
Set the oneToOneCertificateMappingsEnabled property to true.
Click on Edit Items under the oneToOneMappings property.
Add a new mapping by providing the BLOB of the client certificate

Common Mistakes and Solutions

Configuring at the Sub-Application Level:

A common mistake is configuring client certificate authentication at the sub-application level. This approach does not work as expected and should be avoided. Instead, configure it at the server and site level to ensure proper authentication

Fallback Mechanism Issue:

Ensure that all other authentication methods are disabled for the application that requires client certificate authentication. This prevents fallback mechanisms from allowing access without the correct certificate.

Conclusion

By following these steps, you can successfully enable client certificate authentication for a specific application within the Default Web Site in IIS. This configuration ensures that only the designated application requires client certificates for access, while the rest of the site remains accessible without this additional layer of security. If you encounter any issues or need further assistance, feel free to reach out.

Identifying and Blocking Python-httpx Requests

Goyal_Sandeep — Tue, 02 Sep 2025 16:24:57 GMT

Introduction

In today’s API-driven world, automated scripts—especially those using Python libraries like httpx—can pose a risk if left unchecked. While many of these scripts are legitimate, some are used for scraping, brute-force attacks, or unauthorised data access. This blog explores how to detect and block such requests using IIS features like the URL Rewrite Module and Request Filtering.

Identifying Python-httpx Requests

The first step is detection. We identified Python scripts accessing APIs by analysing IIS logs, particularly the User-Agent field. Suspicious entries like "Python httpx" indicated automated access attempts.

Blocking with URL Rewrite Module

The URL Rewrite Module in IIS allows you to create inbound rules based on request headers. Here's how to block requests from httpx:

Open IIS Manager and navigate to your site.
Open the URL Rewrite module.
Add a new Inbound Rule.
Set the condition:

Input: {HTTP_USER_AGENT}
Check if it Matches the Pattern: .*httpx.*

Set the action to Abort Request or return a custom status code like 404.

This method is flexible—you can customise the response code or redirect the request.

Blocking with Request Filtering

As an alternative, Request Filtering offers a simpler but less flexible approach:

Open Request Filtering in IIS.
Go to the HTTP Verbs or Headers tab.
Add a rule to deny requests where the User-Agent contains httpx.

When tested, this method returned a 400 status code, effectively blocking the script.

Testing the Block

Here’s a simple Python script using httpx to test your rules:

Testing Script

Create a new Python file and give it any name (for example, TestPython.py).
Copy and paste the following content into that file.

import httpx

response = httpx.get('http://localhost/test.htm')

print(response.status_code)

Testing Method

Open the Command Prompt.
Navigate to the directory where the test Python script is located.
Run the following command:

python TestPython.py

When accessed ('http://localhost/test.htm') via a browser: 200 OK
When accessed via script: 403, 404, or 400 depending on your configuration

Choosing Between Methods

Feature	URL Rewrite Module	Request Filtering
Custom Status Codes	✅ Yes	❌ No

Conclusion

Blocking automated httpx requests is essential for protecting your APIs from misuse. IIS provides robust tools to help you do this effectively. Whether you prefer the flexibility of URL Rewrite or the simplicity of Request Filtering, both methods can be tailored to your security needs.

Troubleshooting SSL Certificate Issues in Reverse Proxy

Goyal_Sandeep — Tue, 02 Sep 2025 16:24:40 GMT

Introduction

Reverse proxies are essential in modern web architectures, especially for isolating backend services and enforcing security. However, SSL certificate issues can introduce complex challenges, particularly when dealing with HTTPS-only bindings, self-signed certificates, or organisational constraints. This blog shares practical insights from real-world troubleshooting, lab simulations, and customer scenarios.

Reverse Proxy Configuration: HTTP vs HTTPS Bindings

HTTP Binding Setup

In one scenario, I configured a reverse proxy for a backend site using HTTP binding on a custom port (e.g., 82). This setup is straightforward and avoids SSL complications. The reverse proxy helps prevent direct public access to the backend server, enhancing security.

HTTPS Binding Challenges

When the backend site is configured with only HTTPS binding (e.g., port 49494), the reverse proxy must validate the SSL certificate. This introduces challenges, especially with self-signed or privately issued certificates. In such cases, clients may encounter 502.3 - Bad Gateway errors due to failed certificate validation.

Certificate Issues and Solutions

Certificate Warnings

Accessing the reverse proxy site over HTTPS often led to browser warnings due to untrusted certificates. This is common when the backend uses a self-signed certificate or one issued by a private CA.

Solution 1: Root Certificate Installation

Installing the backend server’s root certificate on the reverse proxy server resolved the warning. This approach is secure and recommended for production environments.

Solution 2: Registry Change (Temporary)

For testing or constrained environments, I used a registry key to bypass certificate validation:

[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\IIS Extensions\\Application Request Routing\\Parameters]

"SecureConnectionIgnoreFlags"=dword:00003100

⚠️ This is a temporary workaround and should not be used in production due to security risks.

Troubleshooting Tips

Always verify the backend URL directly from the proxy server.
Use freb logs to identify SSL handshake failures.
Monitor for 502.3 errors and correlate with certificate validation logs.

Lab Setup Guide

Prerequisites

Reverse Proxy Server (Windows Server)
Backend Server (Windows Server)
Client Machine (Windows 10/11)

Backend Server

Create a website with HTTP (e.g. port 82) and HTTPS (e.g. port 49494) bindings.
Use self-signed or test certificates for HTTPS.

Reverse Proxy Server

Configure URL rewrite rules for both HTTP and HTTPS.
Test access to backend URLs from the proxy server.
Import root certificates or apply registry changes as needed.

Client Machine

Access the reverse proxy URL and validate connectivity.
Observe browser behaviour and error messages.

Conclusion

SSL certificate issues in reverse proxy setups can be complex but manageable with the right approach. Whether you're dealing with HTTP/HTTPS bindings, self-signed certificates, or organisational constraints, understanding the root cause and applying targeted solutions is key. Collaboration, testing, and documentation are your best allies.

Troubleshooting IIS Admin Service Termination: “Invalid Signature” Error

Goyal_Sandeep — Tue, 02 Sep 2025 16:23:56 GMT

🔍 Overview

If you've encountered the following error in your Windows Event Viewer:

“The IIS Admin Service service terminated with the following service-specific error: Invalid Signature”

you're likely dealing with a cryptographic issue affecting the IIS metabase. This blog post walks you through the root causes, diagnostics, and step-by-step resolutions to restore service functionality.

🧠 What Causes This Error?

This error typically appears as Event ID 7024 and is often triggered by:

Corruption or deletion of the machine key used by IIS.
Improper SSL certificate updates.
Misconfigured permissions on cryptographic folders.

The IIS Admin Service relies on a secure machine key (usually a file starting with c23) stored in:

C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys

If this key is missing or invalid, IIS cannot decrypt its configuration, resulting in the “Invalid Signature” error.

🧪 Diagnostic Steps

Check Event Viewer
Look for Event ID 7024 under System logs.
Verify Machine Key Presence
Navigate to the MachineKeys folder and check for a file starting with c23.
Audit Permissions
Ensure SYSTEM and Administrators have Full Control on the MachineKeys folder.

🛠️ Resolution Steps

✅ Option 1: Restore from Backup

If you have a backup of the c23* file:

Replace the corrupted file.
Restart the IIS Admin Service.

🔄 Option 2: Reinstall IIS 6 Metabase Compatibility

If no backup is available:

Delete the corrupted c23* file.
Open Server Manager → Manage Optional Features.
Uninstall IIS 6 Metabase Compatibility.
Reboot the server.
Reinstall the feature to regenerate the machine key.

🔐 Option 3: Reset Permissions

Ensure the following permissions on C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys:

SYSTEM: Full Control
Administrators: Full Control

💡 Pro Tips

Always back up the MachineKeys folder before making changes.
Consider enabling IIS Configuration Backup for future recovery.

Capture .NET Memory Dump on Linux

meenakshiBalekar — Tue, 02 Sep 2025 16:23:35 GMT

Collecting memory dumps is a crucial part of diagnosing and troubleshooting application issues on Linux machines. Microsoft suggests three primary tools for this purpose: dotnet-dump, procdump, and createdump. In this blog post, we will explore these tools, provide the commands needed to use them, and offer a summary to understand their significance better.

1. Methods to Collect Memory Dumps on Linux

dotnet-dump

The dotnet-dump tool is a part of the .NET SDK and can be used to collect and analyze dumps. It allows you to capture a dump file from a running .NET application without needing to install additional debugging tools.

https://learn.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-dump

procdump

Procdump is a versatile tool provided by Microsoft that captures dumps based on various triggers, such as high CPU usage or unhandled exceptions. Originally built for Windows, it has been ported to Linux, offering similar functionalities.

https://github.com/microsoft/ProcDump-for-Linux

createdump

The createdump utility is specifically designed for .NET Core applications. It creates core dumps that can be used for post-mortem debugging when an application crashes.

https://learn.microsoft.com/en-us/troubleshoot/developer/webapps/aspnetcore/practice-troubleshoot-linux/lab-1-3-capture-core-crash-dumps#configure-createdump-to-run-at-process-termination

2. Command for dotnet-dump

To collect a memory dump using dotnet-dump, you can execute the following command:

./dotnet-dump collect -p <ProcessID>

In case you want to collect dump on crash you can use below :

./dotnet-dump collect -p <ProcessID> -Crashreport

Here, replace with the ID of the process you want to dump.

3. Command for procdump

To capture a dump with procdump, use the command:

sudo procdump -p <PID> -n 3 - s 10

sudo procdump -C <CPU_Usage> -M <Memory_Usage> <PID> -n 3 - s 10

In this example, the tool will create a dump if the CPU usage exceeds a certain threshold over three consecutive 10-second intervals. Adjust the parameters as needed for your specific scenario.

4. Command for createdump

To generate a dump using createdump, the command is:

sudo createdump --full <PID>

Replace with the appropriate process ID.

Summary

Collecting memory dumps is essential for diagnosing application issues on Linux. Microsoft provides three recommended tools: dotnet-dump, procdump, and createdump. Each of these tools offers unique functionalities to help capture detailed information about your applications' state at the time of issues. By utilizing the respective commands for each tool, you can efficiently collect memory dumps and troubleshoot more effectively.

The commands for capturing memory dumps are straightforward:

dotnet-dump: dotnet-dump collect -p

procdump: procdump -p -s 10 -n 3

createdump: createdump --full <PID>

By following these steps, you can ensure that you have the necessary data to analyze and resolve issues efficiently. Memory dump collection is a valuable skill for any Linux system administrator or developer, and mastering these tools will significantly enhance your troubleshooting capabilities.

Customizing Temporary File Paths in ASP.NET Applications

Tanya_Dhariwal — Tue, 02 Sep 2025 16:22:53 GMT

Issue:

In ASP.NET applications, temporary files are generated during compilation and runtime. By default, these files are stored in system directory at: C:\Windows\Microsoft.NET\Framework[64]\<version>\Temporary ASP.NET Files\.

These ASP.NET temporary files include:

Compiled assemblies (DLLs) of your web pages, user controls, and other server-side code.
Cached versions of resources like Razor views (.cshtml), Web Forms (.aspx), and other dynamic content.
Intermediate files used during the build and runtime process.

This can lead to the following issues:

Running out of space on the system drive (C:)
Difficulty in managing or monitoring temp files
Performance bottlenecks on slower disks

Resolution:

You can resolve this issue by changing the location of ASP.NET temporary files using the tempDirectory attribute in web.config. This allows you to redirect ASP.NET to use a custom directory for temporary files by modifying your web.config as follows:

<system.web>
<compilation tempDirectory="E:\TemporaryASPNETFiles" />
</system.web>

Ensure the custom folder (E:\TemporaryASPNETFiles) is:

Created manually before use.
Writable by the IIS App Pool identity, e.g., IIS APPPOOL\YourAppPoolName. You can set permissions via File Explorer or using PowerShell.

After making this change:

Recycle the application pool or
Restart IIS using iisreset to apply the new configuration

Important Note:

This setting is valid for ASP.NET (System.Web) applications running on the .NET Framework. It does not apply to ASP.NET Core.

From Hello to Secure: The SSL/TLS Handshake Explained Like a Conversation

meenakshiBalekar — Tue, 02 Sep 2025 16:21:48 GMT

Hey everyone!
Welcome back to the blog — today, we’re going to break down something that powers almost every secure interaction on the internet, but sounds way more intimidating than it is: the SSL/TLS handshake.

You can read on how to setup SSL on IIS here :

Access Denied | Microsoft Community Hub

You’ve probably heard of SSL or TLS when someone talks about “HTTPS” or “secure websites.” But what’s really happening under the hood when your browser says "Secure"? Let’s find out together.

First Things First: What Is SSL/TLS?

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are cryptographic protocols. Their job is to:

Encrypt data between client and server (so no one else can read it)
Verify that the server (and optionally the client) is who it says it is
Ensure data hasn’t been tampered with during transit

SSL is the older version, and TLS is its improved, more secure successor. Nowadays, when people say “SSL,” they usually mean “TLS.”

What Is the SSL/TLS Handshake?

Before secure communication begins, the client (like your browser) and the server (like microsoft.com) go through a process to:

Agree on how to communicate securely
Authenticate each other
Exchange keys for encryption

That process is called the SSL/TLS handshake.

Think of it like this:
The browser and server meet each other at a masquerade party. Before dancing (i.e., securely exchanging data), they check IDs, agree on the music, and lock the dancefloor so no one else can sneak in.

Step-by-Step: How the SSL/TLS Handshake Works (TLS 1.2)

Let’s break it down using TLS 1.2 (most widely used, though TLS 1.3 is also common now).

1. ClientHello

The browser initiates the handshake with:

Supported TLS versions
List of supported cipher suites (ways to encrypt)
Random number (client_random)
Optional: Server name (via SNI extension)

This is the browser saying, “Hey, here are the languages I speak. Can we talk securely?”

2. ServerHello

The server responds with:

Chosen TLS version
Selected cipher suite
Its own random number (server_random)
Digital certificate (proves its identity)
Optional: ServerKeyExchange (for some cipher suites)

This is the server saying, “Sure, I’ll speak this encryption language. Here’s my ID (certificate) to prove I am who I say I am.”

3. Certificate Verification (on client side)

The client checks if:

The certificate is valid and trusted (via CA)
The hostname matches
It’s not expired or revoked

Think of it like checking if a driver's license is real and matches the person.

4. Pre-Master Secret Generation

Client generates a Pre-Master Secret (a temporary, shared value)
It encrypts this using the server’s public key (from certificate)
Sends it to the server

Only the server can decrypt this because only it has the private key.

5. Key Derivation (on both sides)

Using:

Pre-Master Secret
client_random
server_random

Both the client and the server derive the same symmetric session key, which will be used to encrypt communication.

6. Finished Messages

Client sends a “Finished” message (encrypted with the new key)
Server sends its own “Finished” message

Now both sides know the connection is secure. The handshake is complete!

From here on, your data (like passwords, credit card info, chats) is encrypted.

What Does This Look Like in a Network Trace?

Let’s peek into a real-world network trace using Microsoft Network Monitor (NetMon) or Wireshark.

TLS:TLS Rec Layer-1 HandShake: Client Hello.

TLS:TLS Rec Layer-1 HandShake: Server Hello.; TLS Rec Layer-2 HandShake: Certificate.

TLS:Continued Data: 1378 Bytes

TLS:TLS Rec Layer-1 HandShake: Client Key Exchange.; TLS Rec Layer-2 Cipher Change Spec; TLS Rec Layer-3 HandShake: Encrypted Handshake Message.

TLS:TLS Rec Layer-1 HandShake: Encrypted Handshake Message.; TLS Rec Layer-2 Cipher Change Spec; TLS Rec Layer-3 HandShake: Encrypted Handshake Message.

TLS:TLS Rec Layer-1 SSL Application Data

What’s Happening Here?

Frame 1: ClientHello

You’ll see the cipher suites listed and maybe an SNI (like www.domain.com).

Frame 2: ServerHello + Certificate

This frame includes:

Server's selected cipher suite
Digital certificate with public key

Expand the certificate section to view fields like CN (Common Name), issuer, and validity dates.

Frame 3: ClientKeyExchange

The Pre-Master Secret is sent (encrypted with the server’s public key).

Then you’ll also see ChangeCipherSpec — this says, “From now on, I’m speaking in encrypted form.”

Frame 4: Server Finished

The server also sends ChangeCipherSpec and finishes the handshake. From this point forward, application data (like your login info) is encrypted.

Final Thoughts

And there you go! That’s the SSL/TLS handshake, explained step-by-step with a peek into what it looks like on the wire.

It might seem complicated at first, but once you break it down, it's just a smart conversation between two computers deciding how to talk securely — kind of like two spies agreeing on a secret code before chatting.

Got Questions?

Drop your questions in the comments — I love digging into anything nerdy.

Until next time — stay curious and stay secure!

Why Port 87 Works in IE and Curl but Fails in Edge and Chrome: Understanding ERR_UNSAFE_PORT

Goyal_Sandeep — Tue, 02 Sep 2025 16:21:22 GMT

Overview

In enterprise environments, configuring IIS to run on non-standard ports is a common practice. However, this can lead to unexpected browser behavior. One such case involves port 87, which works seamlessly in Internet Explorer (IE) and via Curl, but fails in Microsoft Edge and Google Chrome, throwing an ERR_UNSAFE_PORT error.

This blog explores the root cause and resolution strategies for this issue.

Summary

Environment: Windows Server with Chromium-based Edge or Chrome
Application: IIS-hosted application on port 87
Symptoms:

Works fine in Internet Explorer
Works via Curl command
Fails in Edge and Chrome with ERR_UNSAFE_PORT

Root Cause Analysis

Modern browsers like Edge and Chrome are built on the Chromium engine, which includes a security feature that blocks access to certain ports deemed unsafe. These ports are reserved for legacy or sensitive protocols and are listed in Chromium’s port_util.cc file.

Port 87 is among the restricted ports, historically associated with the ttylink protocol

The full list of blocked ports includes:

1, 7, 9, 11, 13, 15, 17, 19, 20, 21, 22, 23, 25, 37, 42, 43, 53, 69, 77, 79, 87, ...

For the complete list, refer to https://superuser.com/questions/188058/which-ports-are-considered-unsafe-by-chrome

Resolution Options

✅ Recommended Solution: Change the Port

Action: Reconfigure IIS to use a port not listed in the restricted ports array.
Reason: Chromium browsers will continue to block unsafe ports by design. There is no registry key or browser setting to override this behavior.

🧩 Alternative: Use IE Mode in Edge

Action: Enable Internet Explorer Mode in Edge using the Enterprise Mode Site List Manager.
Use Case: If changing the port is not feasible due to legacy dependencies.

Conclusion

The ERR_UNSAFE_PORT error in Edge and Chrome is not a bug but a security feature. While legacy tools like IE and Curl bypass this restriction, modern browsers enforce it strictly. The best path forward is to migrate your IIS service to a safe port or leverage IE Mode for backward compatibility.

References

https://superuser.com/questions/188058/which-ports-are-considered-unsafe-by-chrome

https://www-archive.mozilla.org/projects/netlib/portbanning#portlist

How to Set Up SSL on IIS

meenakshiBalekar — Tue, 02 Sep 2025 16:20:32 GMT

Hi All!

If you're running a website on a Windows server using IIS (Internet Information Services), and you're thinking "How do I make my site more secure?" — you're in the right place.

In this guide, I’ll walk you through setting up SSL (Secure Sockets Layer) on IIS. Whether you're doing this for a production environment or just want to learn, I’ve got you covered.

First, What is SSL and Why Should You Care?

Think of SSL as a bodyguard for your website. It encrypts communication between your users and your server — so hackers can't snoop in and grab sensitive data like passwords or credit card numbers.

Here’s how SSL (and its more modern version TLS) protects you:

Encryption: Jumbles up data so only the intended receiver can read it.
Authentication: Confirms your website is legit — not a copycat.
Integrity: Prevents data from being tampered with in transit.

With SSL, your site changes from http:// to https:// and you get that nice padlock icon in the browser.

What You’ll Need Before Getting Started

Before jumping in, here’s your SSL setup toolkit checklist:

Item	Why It’s Needed
A domain name	SSL is tied to a specific domain
An SSL certificate	Purchased from a CA or created for internal use
Windows Server with IIS	That’s where we’ll set up the SSL
Admin access	To install and manage certificates
Port 443 open in firewall	The port SSL uses to talk to browsers

Understanding the SSL/TLS Handshake (Made Easy)

Here’s how the magic happens when someone visits your HTTPS website:

Client Hello: Your browser says, "Hi server, here’s what I support!"
Server Hello: The server replies, "Hi back! Here’s my certificate and details."
Certificate Exchange: Browser checks if the certificate is valid.
Key Exchange: They agree on encryption methods and keys.
Secure Session: Boom! Now all data is encrypted.

Imagine this like a secret handshake between your browser and the server — if done right, everything that follows is in a secret code.

How to Set Up SSL on IIS – Step by Step

Let’s get our hands dirty! Here's how you actually install and configure SSL on IIS.

Step 1: Get an SSL Certificate

You have two choices:

Buy one from a trusted Certificate Authority (e.g., DigiCert, GoDaddy, Namecheap).
Generate a self-signed certificate using IIS (only for testing or internal use not for production).

To create a self-signed cert:

Open IIS Manager
Click on your server name
Go to Server Certificates > Create Self-Signed Certificate

Step 2: Install the Certificate

Let’s plug that certificate into your server:

Press Windows + R, type mmc, hit Enter.
Go to File > Add/Remove Snap-in > Choose Certificates > Select Computer Account
Navigate to Personal > Certificates
Right-click and select Import, then follow the wizard to import your SSL certificate file.

Step 3: Bind the Certificate to Your Website

Now, let’s link the cert to your actual website:

Open IIS Manager
In the left panel, expand Sites and click on your site
Click Bindings (on the right)
Click Add → Choose Type: https → Select your certificate from the list
Hit OK and then Close

Step 4: Test the Setup

Fire up your browser and go to https://yourdomain.com ( hoping your domain is already registered )

Do you see the padlock icon?
No warnings or errors?

Awesome! Your SSL is live and ready to use

Where Are SSL Certificates Stored in Windows?

You can find them in the Windows Certificate Store, accessed via MMC:

Personal > Certificates: These are certs for the local machine
Trusted Root Certification Authorities: These store certificates from trusted CAs

Troubleshooting Tips: What If Something Goes Wrong?

Even if something breaks, don’t panic. Here's where to look:

Tool/Log	What to Check For
IIS Logs	Status codes like 403 or 500
Event Viewer	SSL handshake errors under Application logs
Browser Console	Certificate mismatches or expiry issues
Certificate Store (MMC)	Expired certs, wrong bindings

Why Use SSL? The Real Benefits

Let’s recap why this effort is totally worth it:

Better Security: Encrypts user data
More Trust: Visitors know your site is safe
Higher SEO Rankings: Search engines prefers HTTPS
Compliance: Required for GDPR, HIPAA, etc.

In short, SSL is not optional anymore — it’s essential.

Conclusion: You’ve Got This!

Setting up SSL on IIS might sound technical, but once you break it down, it’s really just a series of logical steps. You’ve now learned:

What SSL is and why it’s important
What tools you need to prepare
How to install and bind the certificate
How to troubleshoot common issues

Whether you’re securing a business site or learning for personal growth, this knowledge is a big win. If you have questions or run into problems, drop them in the comments — I’m here to help!