How to require mTLS only for specific ASP.NET Core APIs in the same IIS site, while allowing local (server-internal) calls without mTLS

Question

Title: How to require mTLS only for specific ASP.NET Core APIs in the same IIS site, while allowing local (server-internal) calls without TLS?

Body:

I'm hosting an ASP.NET Core application in IIS using in-process hosting. The same .csproj includes both a website and several Web API endpoints. I'd like to require mutual TLS (mTLS) for my API routes, but not for the rest of the application. Furthermore, I need local requests (e.g., from the same server or an internal process) to still call my APIs without providing a client certificate.

I’ve tried using the <location path="api"> element in web.config to set sslFlags="Ssl, SslNegotiateCert, SslRequireCert", while leaving the parent <location> with sslFlags="None". Unfortunately, this doesn’t work as I expected:

• When browsing to my API routes externally, IIS doesn’t prompt for a certificate.
• If I set sslFlags="Ssl, SslNegotiateCert, SslRequireCert" at the site level, the entire site (including the non-API parts) requires a certificate.
• Even if the client certificate is optional (SslNegotiateCert), the local calls fail unless a certificate is provided.

Goal:

1. mTLS only on /api/... (or some subset of routes) for external clients.
2. No certificate requirement for local calls to /api/....
3. Other routes (e.g., /, /home, etc.) remain accessible without a certificate.

What I've tried so far:

• <location>-based settings in web.config for sslFlags on just the /api path (with Ssl, SslNegotiateCert, SslRequireCert). But modern TLS typically doesn’t renegotiate mid-connection, so the client is never prompted for a cert if the initial handshake was done for a path that doesn’t require it.
• Checking HttpContext.Connection.ClientCertificate in ASP.NET Core middleware, but if IIS didn’t require a cert at handshake, the client never sends one.
• Creating route-based policies in code (works if sslFlags="SslNegotiateCert" globally, but external clients can skip the cert if they wish, unless I block them in my code with a 403—but that also blocks local calls).

I’ve read that the recommended approach is to use separate bindings or a reverse proxy if you want to enforce TLS differently per hostname or port. But in my case, I have only one site and a single hostname. Splitting out the APIs into a completely separate application or binding is possible, but I'd like to avoid it if I can.

Question:
Is there a way to configure IIS in-process hosting so that:

1. Only requests to /api/... from external hosts require a client cert at the handshake,
2. Local requests to /api/... (e.g., localhost or 127.0.0.1) do not require a cert,
3. The rest of the site remains accessible without a cert,
   without splitting the APIs into a separate application or site?

Any help is appreciated—thanks!