Felsöka SslStream autentiseringsproblem

Den här artikeln beskriver de vanligaste autentiseringsproblemen vid användning av SslStream kryptografi- och säkerhetsrelaterade funktioner i .NET implementeras med interop med antingen OS-API:et (till exempel Schannel i Windows) eller systembibliotek på låg nivå (till exempel OpenSSL i Linux). Beteendet för .NET-programmet, inklusive undantagsmeddelanden och felkoder, kan därför ändras beroende på vilken plattform det körs på.

Vissa problem kan vara enklare att undersöka och felsöka genom att observera de faktiska meddelanden som utbyts via kabeln med hjälp av verktyg som Wireshark eller tcpdump. Dessa verktyg kan användas för att inspektera ClientHello, ServerHello, och andra meddelanden för annonserade TLS-versioner som tillåts, förhandlade chiffersviter och de certifikat som utbyts för autentisering.

Mellanliggande certifikat skickas inte

Under TLS-handskakningen skickar servern (och även klienten, om klientautentisering begärs) sitt certifikat för att bevisa sin identitet för klienten. För att verifiera certifikatets äkthet måste en kedja av certifikat skapas och verifieras. Roten i kedjan måste vara en av den betrodda rotcertifikatutfärdare (CA), vars certifikat lagras i datorcertifikatarkivet.

Om peer-certifikatet inte har utfärdats av någon av de betrodda certifikatutfärdarna krävs ett mellanliggande CA-certifikat för att skapa certifikatkedjan. Men om det mellanliggande certifikatet inte är tillgängligt går det inte att verifiera certifikatet och TLS-handskakningen kan misslyckas.

Det här problemet påträffas oftast i Windows. Även om programmet tillhandahöll mellanliggande certifikat via autentiseringsalternativen skickas de inte till peer-datorn om de inte lagras i Windows-certifikatarkivet. Den här begränsningen beror på att det faktiska TLS-handskakningen sker utanför programprocessen.

För serverprogram är det möjligt att skicka ett SslStreamCertificateContext som SslServerAuthenticationOptions.ServerCertificateContext. Under konstruktionen av instansen SslStreamCertificateContext kan du skicka ytterligare mellanliggande certifikat och dessa läggs tillfälligt till i certifikatarkivet.

Tyvärr är den enda lösningen för klientprogrammet att lägga till certifikaten i certifikatarkivet manuellt.

Handskakningen misslyckades med tillfälliga nycklar

I Windows kan du stöta på felmeddelandet (0x8009030E): No credentials are available in the security package när du försöker använda certifikat med tillfälliga nycklar. Det här beteendet beror på en bugg i det underliggande OS-API:et (Schannel). Mer relevant information och lösningar finns i det associerade GitHub-problemet.

Klienten och servern har ingen gemensam algoritm

När du inspekterar ClientHello meddelandena och ServerHello kan du få reda på att det inte finns någon chiffersvit som erbjuds av både klient och server eller ens att vissa chiffer inte erbjuds även om de uttryckligen konfigureras via CipherSuitesPolicy (endast tillgängligt i Linux). Det underliggande TLS-biblioteket kan inaktivera TLS-versioner och chiffersviter som anses vara osäkra.

På många Linux-distributioner finns relevant konfigurationsfil på /etc/ssl/openssl.cnf.

På Windows kan PowerShell Enable-TlsCipherSuite och Disable-TlsCipherSuite cmdlet:erna användas för att konfigurera chiffersviter. Enskilda TLS-versioner kan aktiveras/inaktiveras genom att konfigurera registernyckeln HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS <version>\{Client|Server}\Enabled .