ASP.NET Certificate Authentication Fails with PartialChain When Intermediate Is Included in Client Certificate

[SaleSwift]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

🔐 Certificate Structure:
I’m using a custom certificate chain with the following hierarchy:

Root CA
└── Intermediate CA
└── End-Entity (Leaf) Certificate
The Root CA signs the Intermediate CA.

The Intermediate CA signs the End-Entity (client/leaf) certificate.

The server trusts only the Root CA. The Intermediate CA is not installed on the server's trusted certificate store.

The client certificate includes both the Intermediate and End-Entity certificates in a full chain (e.g., PFX or PEM bundle).

Problem:
When the client sends the certificate with both the Intermediate and End-Entity certificates:

The ASP.NET Certificate Authentication Middleware fails with this error:
PartialChain: unable to get local issuer certificate
The middleware is unable to build a full trust chain, even though the intermediate is present in the client certificate chain.

If only the Intermediate certificate is sent by the client, the request is correctly success

Expected Behavior:
The middleware should be able to build the chain from the leaf through the intermediate up to the trusted root, using the intermediate provided by the client — as most TLS clients (e.g., OpenSSL, browsers) do.

Server side code

public static AuthenticationBuilder AddSaleSwiftCertificate(this AuthenticationBuilder builder)
  {
      return builder.AddCertificate(options =>
      {
          X509Certificate2 rootCertificate = GetRootCertificate();

          options.RevocationMode = X509RevocationMode.NoCheck;
          options.ChainTrustValidationMode = X509ChainTrustMode.CustomRootTrust;
          options.CustomTrustStore = [rootCertificate];

          options.Events = new CertificateAuthenticationEvents()
          {
              OnCertificateValidated = context =>
              {
                  IEnumerable<Claim> claims = ParseSaleSwiftCertificateToClaims(context);

                  ClaimsIdentity claimsIdentity = new(claims, context.Scheme.Name);

                  if (context.Principal == null)
                  {
                      context.Principal = new ClaimsPrincipal(claimsIdentity);
                  }
                  else
                  {
                      context.Principal.AddIdentity(claimsIdentity);
                  }

                  context.Success();

                  return Task.CompletedTask;
              }
          };
      })
          .AddCertificateCache(options =>
          {
              options.CacheSize = 1024;
              options.CacheEntryExpiration = TimeSpan.FromMinutes(2);
          });
  }

Client side code (HttpClient that communicate with the api)

services.AddHttpClient<PossHttpClient>(httpClient =>
    {
        httpClient.BaseAddress = new Uri(configuration.GetConnectionString("PossApi")!);
    }).ConfigurePrimaryHttpMessageHandler((serviceProvider) =>
    {
        HttpClientHandler httpClientHandler = new();
        httpClientHandler.ClientCertificateOptions = ClientCertificateOption.Manual;
        PosServerCertificate posServerCertificate = serviceProvider.GetRequiredService<PosServerCertificate>();
        httpClientHandler.ClientCertificates.Add(posServerCertificate.Value);

        return httpClientHandler;
    });

Question:
Is this behavior expected in ASP.NET Core?

Is it correct that the server trusts only the root CA, while the client provides both the intermediate and leaf certificates in its chain?
Or am I missing a required step (e.g., should the server also know about the intermediate)?

Certificates are added to files

PosServer is the leaf
PosCa is the intermidate
SaleSwiftCA is the root

All passwords 123456

Certificates.zip

Expected Behavior

No response

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

9

Anything else?

No response

[MackinnonBuck]

@bartonjs, do you happen to know what might be wrong here, at a glance?

[bartonjs]

Without looking inside the zip, the possibilities in my head are:

• There are actually two different intermediate certificates that look like valid signers for the leaf cert, but only one of them looks validly signed by the root. If the invalid one is sent in the handshake, the chain engine has no reason to look for a "better" copy of it. If the valid one is retrievable by AIA, then "less data" would yield "more success".
• There's some other, irrelevant, cert in a PFX, and you're not using the one you think you are as the client cert.

[razyhalaby]

Without looking inside the zip, the possibilities in my head are:

• There are actually two different intermediate certificates that look like valid signers for the leaf cert, but only one of them looks validly signed by the root. If the invalid one is sent in the handshake, the chain engine has no reason to look for a "better" copy of it. If the valid one is retrievable by AIA, then "less data" would yield "more success".
• There's some other, irrelevant, cert in a PFX, and you're not using the one you think you are as the client cert.

What do you mean with two intermediate that are valid from the root

When i create the intermediate i save them to .cer file and .pfx
And from the pfx i generate the child one

So into that child i add the cer intermediate and save it into pfx called leaf with intermediate
And that one i use as client certificate

[bartonjs]

What do you mean with two intermediate that are valid from the root

Basically, that "CN=Some Intermediate" was made, then the certificate was edited in a chain-invalidating way; and maybe a new version of "CN=Some Intermediate" was made. So there are, in the universe, two or three different variants of the same certificate.

When i create the intermediate...

Sounds like that isn't the state you're in, then.

As I said, "without looking inside the zip". I was asked if I knew "at a glance" what could cause the state, I answered in the general, not the specific. So someone'll have to do some poking at things in a debugger to get more information specific to the situation.

[razyhalaby]

What do you mean with two intermediate that are valid from the root

Basically, that "CN=Some Intermediate" was made, then the certificate was edited in a chain-invalidating way; and maybe a new version of "CN=Some Intermediate" was made. So there are, in the universe, two or three different variants of the same certificate.

When i create the intermediate...

Sounds like that isn't the state you're in, then.

As I said, "without looking inside the zip". I was asked if I knew "at a glance" what could cause the state, I answered in the general, not the specific. So someone'll have to do some poking at things in a debugger to get more information specific to the situation.

Oh okay I understand.
I hope someone check the certificates
Cause I think that the certificate authentication of asp net core isnt extract the intermediate sent with leaf as client certificate.

[bartonjs]

FWIW, I've assumed that "When the client sends the certificate with both the Intermediate and End-Entity certificates... The ASP.NET Certificate Authentication Middleware fails" means you've seen on a network trace that the intermediate certificate was actually sent.

If the client chain build can't figure out the certificate automatically, then the client won't send the intermediate ("it was in the PFX with the client cert" isn't good enough). Then, if the server doesn't already know about the intermediate, it'll see it as PartialChain.

I think a client cert for SslStream might be able to use SslStreamCertificateContext.Create(cert, extraCerts) to provide the intermediate (as an extraCerts member) down to the TLS engine. But for Windows it might just require putting the intermediate certificate into the CurrentUser\CA (intermediate certificate cache) store.

[razyhalaby]

FWIW, I've assumed that "When the client sends the certificate with both the Intermediate and End-Entity certificates... The ASP.NET Certificate Authentication Middleware fails" means you've seen on a network trace that the intermediate certificate was actually sent.

If the client chain build can't figure out the certificate automatically, then the client won't send the intermediate ("it was in the PFX with the client cert" isn't good enough). Then, if the server doesn't already know about the intermediate, it'll see it as PartialChain.

I think a client cert for SslStream might be able to use SslStreamCertificateContext.Create(cert, extraCerts) to provide the intermediate (as an extraCerts member) down to the TLS engine. But for Windows it might just require putting the intermediate certificate into the CurrentUser\CA (intermediate certificate cache) store.

As far as I understand, if the leaf certificate does not include the intermediate certificate, but the intermediate is installed in the Windows Intermediate Certification Authorities store, then Windows should automatically build the full chain when sending the client certificate during the request.

Alternatively, if I bundle the intermediate certificate within the leaf .pfx file, then it should be sent together without relying on the store.

In any case, I tested three scenarios:
1. Leaf certificate only, with intermediate installed in Windows.
2. Leaf + intermediate bundled in the .pfx, with intermediate also installed in Windows.
3. Leaf + intermediate bundled in the .pfx, with intermediate not installed in Windows.

In all three cases, the server still fails with a PartialChain error.

However, I have not yet used Wireshark to verify whether the client actually sent the intermediate certificate in the TLS handshake.

Note: The server is running on Linux, and the client is on Windows.

[bartonjs]

Alternatively, if I bundle the intermediate certificate within the leaf .pfx file, then it should be sent together without relying on the store.

That is not true. There's no affinity from being co-located in a PFX.

(ASP.NET might have a feature that makes it true... but from the low-level chain-building piece, it's not true)

[ShayMusachanov-dev]

We are experiencing the exact same issue. Despite the client providing the complete certificate chain (including the intermediate certificate), the ASP.NET Core certificate authentication middleware fails with the PartialChain error because the intermediate certificate is not installed on the server.

Important clarification: In our use case, we are using certificates solely for authentication (UseAuthentication) and NOT for establishing the TLS connection. This distinction matters because the workaround mentioned in #42010 (which led to PR #33953 adding a new UseHttps overload with per-connection callbacks) only applies when certificates are used for TLS establishment, not when they're used by the authentication middleware.

After searching for related issues, I found #43661 which appears to describe the same problem. That issue points out that this behavior actually violates RFC 5246, which clearly states that servers should use the certificate chain provided by the client during the TLS handshake for validation purposes.

It's concerning that this issue has been known since at least 2022 (as evidenced by #43661) but still persists. The current implementation forces us to install all intermediate certificates on every server, which is impractical and goes against standard TLS practices where clients provide their certificate chain.

Has there been any progress on fixing this fundamental issue with certificate chain validation in the authentication middleware?

[razyhalaby]

@bartonjs @MackinnonBuck