J'ai trouvé la solution moi-même en disséquant le protocole TLS. Il s'avère que le client qui ne fonctionne pas dans l'exemple ci-dessus envoie le certificat my client lors de l'établissement de la liaison ; et le client qui travaille ne fait pas ça. Apparemment, le cryptage est établi de toute façon (je n'ai pas continué dans le protocole TLS), et probablement un échange de certificat/clé a eu lieu plus loin.
Pour que la connexion fonctionne, tout ce que j'avais à faire était de changer la chaîne de connexion et de supprimer toutes les clés Certificate*=. En particulier "Certificate Store Location=CurrentUser". Ma chaîne de connexion SSL MySql actuelle et fonctionnelle est :
server=xxx.yyy.zzz.uuu;database=whopper;user=Username;password=Secret;Pooling=false;SSL Mode=Required;Keepalive=60
De plus, en passant, lors de la dissection de la communication, j'ai constaté que Tamos CommView fait un meilleur travail que WireShark pour intercepter et disséquer les communications VPN. Peut-être en raison de l'incapacité de WinPCaps à disséquer les paquets VPN sous Windows 7 x64. De plus, le dissecteur TLS dans CommView est ce qui m'a vraiment aidé à trouver le problème de prise de contact.
Aussi, comme une deuxième note latérale. Toutes les communications SSL/TLS dans Windows sont gérées par une DLL appelée schannel.dll. La connexion complète au System EventLog pour cette dll peut être activée en créant le DWORD HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\EventLogging avec la valeur 7. En savoir plus ici :http://support.microsoft.com/kb/260729 .
Pour que ça marche. Enlevez des trucs.
