Cannot conect to stateless streamable http mcp server developed using C# SDK using VSCode mcp client

[ananthubabu-geodis]

Developed and deployed a mcp server exposing majorly prompts and just one tool for testing and is getting the error :

2025-06-20 14:50:02.632 [info] Starting server from LocalProcess extension host
2025-06-20 14:50:02.663 [info] Connection state: Running
2025-06-20 14:50:03.942 [info] Discovered 0 tools
2025-06-20 14:50:04.775 [info] Connection state: Error ; will retry with new session ID

I have provided the options

            .ConfigureServices((_, services) =>
                {
                    services
                        .AddMcpServer(options =>
                        {
                            options.ServerInfo = new Implementation
                            {
                                Name = "Vite MCP Server",
                                Version = "1.0.0"
                            };
                        })
                        .WithHttpTransport(options =>
                        {
                            options.IdleTimeout = TimeSpan.FromMinutes(15);
                            options.MaxIdleSessionCount = 100;
                            options.Stateless = true;
                        })
                        .WithToolsFromAssembly()
                        .WithPromptsFromAssembly();
                });

also in Startup.cs :

            app.UseCors("CorsPolicy");
            app.UseEndpoints(endpoints =>
            {
                endpoints.MapMcp("/mcp");
            });

It works fine in local machine using http ports but not in https.

The hosted server also returns the error.

Could this be because of any certificate issue?

VSCode is my mcp client.

Edit :

This is a certificate issue :

Error from MCP server: TypeError: fetch failed
    at node:internal/deps/undici/undici:13502:13
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async StreamableHTTPClientTransport.send (file:///C:/Users/ananthu.babu/AppData/Local/npm-cache/_npx/5a9d879542beca3a/node_modules/@modelcontextprotocol/sdk/dist/esm/client/streamableHttp.js:251:30) {
  [cause]: Error: unable to get local issuer certificate
      at TLSSocket.onConnectSecure (node:_tls_wrap:1679:34)
      at TLSSocket.emit (node:events:518:28)
      at TLSSocket._finishInit (node:_tls_wrap:1078:8)
      at ssl.onhandshakedone (node:_tls_wrap:864:12) {
    code: 'UNABLE_TO_GET_ISSUER_CERT_LOCALLY'
  }
}

Any fix?

[halter73]

I tried this out and was able to reproduce the issue. I can work around this issue by setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to 0 before launching VS code, but this shouldn't be necessary.

> $env:NODE_TLS_REJECT_UNAUTHORIZED=0
> code .

The ASP.NET Core dev certificate on Windows works with Edge and most other clients/browsers that use Schannel or at least the user certificate store.

When I try to make a fetch request from an Node.js v22 interactive session without the environment variable set to 0, I see the following error

> node
Welcome to Node.js v22.16.0.
Type ".help" for more information.
> await fetch('https://localhost:7133')
Uncaught TypeError: fetch failed
    at node:internal/deps/undici/undici:13510:13
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async REPL1:1:33 {
  [cause]: Error: self-signed certificate
      at TLSSocket.onConnectSecure (node:_tls_wrap:1679:34)
      at TLSSocket.emit (node:events:518:28)
      at TLSSocket.emit (node:domain:552:15)
      at TLSSocket._finishInit (node:_tls_wrap:1078:8)
      at ssl.onhandshakedone (node:_tls_wrap:864:12)
      at TLSWrap.callbackTrampoline (node:internal/async_hooks:130:17) {
    code: 'DEPTH_ZERO_SELF_SIGNED_CERT'
  }
}

The DEPTH_ZERO_SELF_SIGNED_CERT error code implies to me that Node.js knows of the existence of the ASP.NET Core dev cert but rejects self-signed certs as a matter of policy.

@AArnott, is this something we can do to fix this on the VS Code side? I know that https.get from the 'node:https' module allows you to specify rejectUnauthorized: false on a per-request basis which flows through to tls.connect, but I'm not sure how you would flow that to streamableHttp.ts which just uses fetch. And even if you could, it'd be best to just allow self-signed certs rather than disable all CA validation.

I think we should do something though. I don't want to encourage developers to disable all TLS certificate validation for all the node processes launched by VS Code, but it'd be nice if the VS Code MCP client at least accepted the ASP.NET Core dev cert like most browsers do.

In the meantime, I'd recommend using plain HTTP if possible.

[ananthubabu-geodis]

I got the previous error in the mcp/inspector terminal which I surpassed through setting the flag NODE_TLS_REJECT_UNAUTHORIZED to 0 as you mentioned.

But still in VSCode I was getting the same error

2025-06-20 14:50:04.775 [info] Connection state: Error ; will retry with new session ID

Meanwhile, while calling the list/prompts in the mcp inspector, I got another error

Error from MCP server: Error: Error POSTing to endpoint (HTTP 500): {"title":"The key {3cad59da-6b11-43d4-a0f9-8b69bfae313c} was not found in the key ring. 
For more information go to [https://aka.ms/aspnet/dataprotectionwarning","status":500,"instance":"/mcp","detail":"innerException:](https://aka.ms/aspnet/dataprotectionwarning%22,%22status%22:500,%22instance%22:%22/mcp%22,%22detail%22:%22innerException:) 
Trace:   at Microsoft.AspNetCore.DataProtection.KeyManagement.KeyRingBasedDataProtector.UnprotectCore(Byte[] protectedData, Boolean allowOperationsOnRevokedKeys, UnprotectStatus& status)\n   at Microsoft.AspNetCore.DataProtection.KeyManagement.KeyRingBasedDataProtector.Unprotect(Byte[] protectedData)\n   at Microsoft.AspNetCore.DataProtection.DataProtectionCommonExtensions.Unprotect(IDataProtector protector, String protectedData)\n   at 
ModelContextProtocol.AspNetCore.StreamableHttpHandler.GetSessionAsync(HttpContext context, String sessionId)\n   at ModelContextProtocol.AspNetCore.StreamableHttpHandler.GetOrCreateSessionAsync(HttpContext context)\n   at ModelContextProtocol.AspNetCore.StreamableHttpHandler.HandlePostRequestAsync(HttpContext context)\n

which I fixed using a workaround disabling all encryptions by

                    // In ConfigureServices:
                    services.AddSingleton<IDataProtectionProvider, NoOpDataProtectionProvider>();
                    services
                        .Configure<CookieAuthenticationOptions>(options =>
                        {
                            options.DataProtectionProvider = new NoOpDataProtectionProvider();
                        });

    public class NoOpDataProtectionProvider : IDataProtectionProvider, IDataProtector
    {
        public IDataProtector CreateProtector(string purpose) => this;
        public byte[] Protect(byte[] plaintext) => plaintext;
        public byte[] Unprotect(byte[] protectedData) => protectedData;
}

And thus I was able to connect from VSCode even without disabling any flags or using any of these

    "win-ca.inject": "append",
    "http.experimental.systemCertificatesV2": true,
    "http.proxyStrictSSL": false

Any idea why or how?

Is this an issue in the server I developed or is it common for all mcp servers developed using dotnet SDK?

[halter73]

@ananthubabu-geodis I recommend against using a NoOpDataProtectionProvider since that could allow spoofing sessions. Using it for cookie authentication seems particularly problematic since that would allow anyone to forge an arbitrary HttpContext.User. You might see data protection errors if you are hosting your ASP.NET Core app in multiple servers/containers if you haven't provided a mechanism for these servers/containers to share private keys needed to encrypt and decrypt things like authentication cookies or stateless MCP session IDs.

Can you use sticky sessions or store the data protection keys in shared file system or DB? That should fix that issue without disabling encryption.

As for why you do not see the certificate errors, I'm guessing that's because you're not using the self-signed ASP.NET Core certificate intended only for "localhost". I assumed you were previously. Are you using the ASP.NET Core dev cert?

[halter73]

is this something we can do to fix this on the VS Code side? I know that https.get from the 'node:https' module allows you to specify rejectUnauthorized: false on a per-request basis which flows through to tls.connect, but I'm not sure how you would flow that to streamableHttp.ts which just uses fetch. And even if you could, it'd be best to just allow self-signed certs rather than disable all CA validation.
I think we should do something though. I don't want to encourage developers to disable all TLS certificate validation for all the node processes launched by VS Code, but it'd be nice if the VS Code MCP client at least accepted the ASP.NET Core dev cert like most browsers do.

@digitarald Do you know if there's anything we can do in VS Code so it doesn't fail to connect to MCP servers protected by the self-signed ASP.NET Core dev cert?