Ich habe die Lösung selbst gefunden, als ich das TLS-Protokoll seziert habe. Es stellt sich heraus, dass der Client, der im obigen Beispiel nicht funktioniert, während des Handshakes das my-Client-Zertifikat sendet; und der Kunde, die arbeiten tut das nicht. Anscheinend wird trotzdem eine Verschlüsselung hergestellt (ich bin nicht weiter auf das TLS-Protokoll eingegangen), und wahrscheinlich findet im weiteren Verlauf ein Zertifikatsaustausch/Schlüsselaustausch statt.
Damit die Verbindung funktioniert, musste ich lediglich die Verbindungszeichenfolge ändern und alle Certificate*=-Schlüssel entfernen. Insbesondere „Certificate Store Location=CurrentUser“. Meine aktuelle, funktionierende MySql-SSL-Verbindungszeichenfolge lautet:
server=xxx.yyy.zzz.uuu;database=whopper;user=Username;password=Secret;Pooling=false;SSL Mode=Required;Keepalive=60
Als Nebenbemerkung habe ich beim Analysieren der Kommunikation festgestellt, dass Tamos CommView beim Abfangen und Analysieren während der VPN-Kommunikation einen besseren Job macht als WireShark. Möglicherweise aufgrund der Unfähigkeit von WinPCaps, VPN-Pakete unter Windows 7 x64 zu analysieren. Auch der TLS-Dissektor in CommView hat mir wirklich geholfen, das Handshaking-Problem zu finden.
Auch als zweite Randnotiz. Die gesamte SSL/TLS-Kommunikation in Windows wird von einer DLL namens schannel.dll abgewickelt. Die vollständige Protokollierung in das Systemereignisprotokoll für diese DLL kann aktiviert werden, indem das DWORD HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\EventLogging mit dem Wert 7 erstellt wird. Lesen Sie hier mehr:http://support.microsoft.com/kb/260729 .
Damit es funktioniert. Sachen entfernen.
