ASP.Net MVC5应用随机触发SSL/TLS信任错误，仅回收IIS应用池可恢复，求原因

Let's dig into the likely culprits here—since you've already tried the standard certificate validation bypass and the issue only clears up when recycling the app pool, we’re dealing with stateful problems tied to your application’s runtime context or connection caching. Here are the most probable causes and how to investigate them:

1. Stale ServicePoint Cache State #

.NET’s ServicePointManager caches connection metadata (including certificate validation results) for each unique API endpoint. If your app hits a validation failure once (even for a transient reason like a third-party certificate glitch), that failed state gets stuck in the cache. Since you set the validation callback at startup, it won’t apply to existing ServicePoint instances—they’ll keep using the cached failure until the app pool is recycled (which clears the entire app domain and its caches).

Fix/Investigation Steps:

• Before each API call, explicitly reset or release the cached ServicePoint for the third-party URI:

  var apiUri = new Uri("https://your-third-party-api.com");
  var servicePoint = ServicePointManager.FindServicePoint(apiUri);
  // Reset existing connections tied to this endpoint
  servicePoint.CloseConnectionGroup("");
  // Or fully remove the cached ServicePoint to force a fresh connection
  ServicePointManager.ReleaseServicePoint(apiUri);
  

• Add logging to confirm if your validation callback is even being invoked when the error occurs. If it’s not, the cached ServicePoint is bypassing it:

  ServicePointManager.ServerCertificateValidationCallback = (sender, cert, chain, errors) =>
  {
      // Log these details to your application log
      Console.WriteLine($"SSL Validation Error: {errors} | Cert Subject: {cert?.Subject}");
      return true;
  };
  

2. Accidental Overwriting of the Validation Callback #

If other code in your application (or a third-party library) modifies ServicePointManager.ServerCertificateValidationCallback at runtime, it could overwrite your "always return true" delegate. This would cause validation to start failing, and the change would persist until the app pool is recycled (resetting the global state).

Investigation Steps:

• Search your entire codebase for instances of ServicePointManager.ServerCertificateValidationCallback to ensure no other code is modifying this setting.
• Check if any NuGet packages you use handle SSL connections—some libraries set their own validation callbacks without warning.

3. Corrupted App Domain State #

Over time, long-running app domains can accumulate corrupted state related to security contexts or certificate validation. For example, the .NET runtime’s internal cache for certificate chains might get stuck in a failed state, or the app might lose permissions to access the local certificate store (needed to verify third-party certificate chains). Recycling the app pool resets the app domain, clearing this corrupted state.

Investigation Steps:

• Verify the app pool’s identity (e.g., ApplicationPoolIdentity) has permissions to read the local machine’s Trusted Root Certification Authorities store. If permissions are lost mid-run, validation will fail until the pool is recycled.
• Enable .NET’s SSL tracing to capture detailed validation logs. You can do this by adding the following to your web.config:

  <system.diagnostics>
      <sources>
          <source name="System.Net" tracemode="includehex" maxdatasize="1024">
              <listeners>
                  <add name="System.Net"/>
              </listeners>
          </source>
          <source name="System.Net.Sockets">
              <listeners>
                  <add name="System.Net"/>
              </listeners>
          </source>
          <source name="System.Net.Cache">
              <listeners>
                  <add name="System.Net"/>
              </listeners>
          </source>
      </sources>
      <sharedListeners>
          <add name="System.Net" type="System.Diagnostics.TextWriterTraceListener" initializeData="netlog.txt"/>
      </sharedListeners>
      <switches>
          <add name="System.Net" value="Verbose"/>
          <add name="System.Net.Sockets" value="Verbose"/>
          <add name="System.Net.Cache" value="Verbose"/>
      </switches>
  </system.diagnostics>
  

  This will generate a log file (netlog.txt) with detailed SSL handshake and validation info to pinpoint where the failure occurs.

4. Transient Third-Party Certificate Issues #

It’s possible the third-party API is rotating certificates or experiencing intermittent issues with their certificate chain (e.g., a CA server goes offline temporarily). .NET might cache the failed validation result, and the cache doesn’t expire until the app pool is recycled.

Investigation Steps:

• Reach out to the third-party API provider to confirm if they’ve had recent certificate changes or outages that align with your error timestamps.
• Use tools like curl or OpenSSL to test the API endpoint during an error occurrence—this will help you confirm if the issue is on their end or your app’s caching.

内容的提问来源于stack exchange，提问作者Shawn de Wet