[Breaking change]: Disable AIA certificate downloads for client-cert validation on server SslStreams by default

[rzikm]

[Breaking change]: Default behavior of SslStream server-side client-certificate validation disables AIA certificate downloads

Description

Starting in .NET 11 Preview 3, the default behavior of SslStream when operating as a server validating client certificates has changed. By default, SslStream now disables downloading intermediate certificates using the Authority Information Access (AIA) extension during the TLS handshake. This change improves performance and security by preventing the server from making outbound HTTP GET requests to client-provided endpoints for intermediate certificate retrieval.

This change only applies when no custom X509ChainPolicy is provided by the user. If a custom X509ChainPolicy is specified, the X509ChainPolicy.DisableCertificateDownloads value is respected.

Version

.NET 11 Preview 3

Previous behavior

When SslStream was used as a server to validate client certificates, it would attempt to download missing intermediate certificates using the AIA extension if the client did not provide all necessary intermediate certificates during the TLS handshake. This behavior occurred even when no custom X509ChainPolicy was specified.

Example

Consider the following code:

var sslStream = new SslStream(networkStream);

sslStream.AuthenticateAsServer(new SslServerAuthenticationOptions
{
    ServerCertificate = serverCertificate,
    ClientCertificateRequred = true,
    CertificateRevocationCheckMode = X509RevocationMode.Online
});

If the client did not send all required intermediate certificates, the server would attempt to download them using the AIA extension.

New behavior

By default, SslStream now disables AIA certificate downloads when operating as a server validating client certificates. If the client does not provide all necessary intermediate certificates during the TLS handshake, the server will no longer attempt to download them. Instead, the handshake will fail unless the server is explicitly configured with the required intermediate certificates.

Example

Using the same code as above, if the client does not send all required intermediate certificates, the handshake will fail with a certificate validation error. To restore the previous behavior, you can explicitly configure an X509ChainPolicy that allows AIA downloads:

Type of breaking change

• Behavioral change: Existing binaries might behave differently at runtime.

Reason for change

This change was introduced to improve the performance and security of SslStream when used as a server for client-certificate validation. Allowing AIA downloads during the TLS handshake can lead to significant performance degradation if the AIA server is slow or unresponsive. Additionally, making outbound HTTP GET requests to client-provided endpoints introduces potential security risks.

Recommended action

If your application relies on the previous behavior of SslStream downloading intermediate certificates using AIA, you need to take one of the following actions:

1. Ensure the client sends all necessary intermediate certificates: Configure the client to include all required intermediate certificates in the TLS handshake. This can be achieved by using SslClientAuthenticationOptions.ClientCertificateContext on the client-side.

2. Configure the server with the required intermediate certificates: Use the X509ChainPolicy.ExtraStore property to provide the necessary intermediate certificates to the server:

   var chainPolicy = new X509ChainPolicy
   {
       // ... revocation check configuration omitted for brevity
   
       // explicitly disable AIA (default is `false`)
       DisableCertificateDownloads = true,
   
       // Add any necessary intermediates to the ExtraStore
       ExtraStore = new X509Certificate2Collection(intermediateCertificate),
   
       // if your scenario uses client certificates issued by a private root CA, you should also specify custom trust
       TrustMode = X509ChainTrustMode.CustomTrustRoot,
       CustomTrustStore = new X509Certificate2Collection(rootCertificate)
   };
   
   var sslStream = new SslStream(networkStream);
   
   sslStream.AuthenticateAsServer(new SslServerAuthenticationOptions
   {
       ServerCertificateContext = serverCertificateContext,
       ClientCertificateRequred = true,
       CertificateChainPolicy = chainPolicy
   
       // Note: CertificateRevocationCheckMode property is superseeded by configuration in the chainPolicy
       // CertificateRevocationCheckMode = X509RevocationMode.Online // has no effect
   });

3. Explicitly allow AIA downloads (not recommended): If necessary, you can restore the previous behavior by setting X509ChainPolicy.DisableCertificateDownloads to false. However, this approach is not recommended due to the associated performance and security risks.

   var chainPolicy = new X509ChainPolicy
   {
       // ... other configuration omitted for brevity
       DisableCertificateDownloads = false // allow AIA downloads
   };
   
   var sslStream = new SslStream(networkStream);
   
   sslStream.AuthenticateAsServer(new SslServerAuthenticationOptions
   {
       ServerCertificateContext = serverCertificateContext,
       ClientCertificateRequred = true,
       CertificateChainPolicy = chainPolicy
   
       // Note: CertificateRevocationCheckMode property is superseeded by configuration in the chainPolicy
       // CertificateRevocationCheckMode = X509RevocationMode.Online // has no effect
   });

Affected APIs

• System.Net.Security.SslStream.AuthenticateAsServer
• System.Net.Security.SslStream.AuthenticateAsServerAsync

Additional information

For more details, see the pull request that introduced this change. The merge commit for this change is available here.

[pentp]

The PR mentions this can happen when:

client does not send necessary intermediates in the handshake (on Windows, this requires that the CA cert is present in the CA store)

Could you clarify under what conditions would the client omit the intermediate CAs in the TLS request on Windows - how exactly does the presence or lack of CAs in the client's CA store affect this?

[rzikm]

Could you clarify under what conditions would the client omit the intermediate CAs in the TLS request on Windows - how exactly does the presence or lack of CAs in the client's CA store affect this?

The native SChannel APIs accept only the leaf certificate, they don't allow specifying intermediates. SChannel will attempt to build the certificate chain internally, which includes looking up the intermediates in Intermediate Certificate Authority store.

It's been a long-standing limitation of SslStream on Windows, see also dotnet/runtime#26323. One way this has been addressed is that creating SslStreamCertificateContext on Windows will insert the intermediates to the necessary store under the hood to make it "just work" for most people (see https://github.com/dotnet/runtime/blob/4bbde33ac01496375ee8902c886c9f0c3c7c709c/src/libraries/System.Net.Security/src/System/Net/Security/SslStreamCertificateContext.Windows.cs#L43-L101). Note that adding a certificate in the Intemediate CA store does not make it trusted, if AIA is enabled, Windows can use that store as a cache to avoid repeated downloads.

The PR description is maybe a bit misleading since no explicit action is needed by the user if they use SslStreamCertificateContext, let me reword it.