Ik vond de oplossing zelf tijdens het ontleden van het TLS-protocol. Blijkt dat de client die in het bovenstaande voorbeeld niet werkt, het my client-certificaat verzendt tijdens het handenschudden; en de klant die werk doet doet dat niet. Blijkbaar is er toch versleuteling tot stand gebracht (ik ben niet verder gegaan met het TLS-protocol), en waarschijnlijk vindt er verderop een certificaatuitwisseling/sleuteluitwisseling plaats.
Om de verbinding te laten werken, hoefde ik alleen maar de verbindingsreeks te wijzigen en alle Certificate*=-sleutels te verwijderen. In het bijzonder "Certificaat Winkellocatie=Huidige Gebruiker". Mijn huidige, werkende MySql SSL-verbindingsreeks is:
server=xxx.yyy.zzz.uuu;database=whopper;user=Username;password=Secret;Pooling=false;SSL Mode=Required;Keepalive=60
Even terzijde, bij het ontleden van de communicatie, ontdekte ik dat Tamos CommView het beter doet dan WireShark bij het onderscheppen en ontleden tijdens VPN-communicatie. Misschien vanwege WinPCaps onmogelijkheid om VPN-pakketten onder Windows 7 x64 te ontleden. Ook de TLS-dissector in CommView heeft me echt geholpen om het probleem met handenschudden te vinden.
Ook als tweede kanttekening. Alle SSL/TLS-communicatie in Windows wordt afgehandeld door een DLL genaamd schannel.dll. Volledige aanmelding bij de System EventLog voor die dll kan worden ingeschakeld door de DWORD HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\EventLogging te maken met de waarde 7. Lees hier meer:http://support.microsoft.com/kb/260729 .
Om het te laten werken. Verwijder spullen.