Ein chinesischer Entwickler stieß kürzlich auf ein rätselhaftes SSL-Problem: Ein Zertifikat funktionierte einwandfrei auf nginx, schlug jedoch auf Kestrel, dem plattformübergreifenden Webserver von ASP.NET Core, fehl. Das Problem trat bei der Aktualisierung von SSL-Zertifikaten für ein Projekt mit CYarp auf, das Kestrel als externes Gateway bereitstellt. Während Browser das neue Zertifikat akzeptierten, lehnten Client-Geräte – wahrscheinlich mit eingeschränkten oder angepassten Vertrauensspeichern – es ab. Der Autor verglich systematisch das Verhalten von Kestrel und nginx und stellte fest, dass Kestrel standardmäßig eine strengere Zertifikatskettenprüfung durchführt. Dies umfasst eine rigorosere Überprüfung von Zwischenzertifikaten und Vertrauensankern, während nginx oft Ketten akzeptiert, die Kestrel als unvollständig betrachtet. Der Beitrag bietet praktische Debugging-Schritte, wie die Inspektion der Zertifikatskette mit OpenSSL und die Anpassung der Kestrel-Validierungseinstellungen über die `KestrelServerOptions`-Konfiguration. Für .NET-Entwickler, die Kestrel in Edge- oder Gateway-Rollen einsetzen, ist dies eine wichtige Erinnerung, das SSL-Vertrauen über alle Client-Typen hinweg zu testen, nicht nur über Browser. Die Ursache ist kein Fehler, sondern ein Designunterschied: Kestrel priorisiert Sicherheit vor Kompatibilität, was Verbindungen von älteren oder eingebetteten Clients unterbrechen kann.
Ein realer Debugging-Fall zeigt, dass die SSL-Zertifikatskettenprüfung von Kestrel sich von nginx unterscheidet und in eingeschränkten Client-Umgebungen zu Vertrauensfehlern führt.