http://bugs.winehq.org/show_bug.cgi?id=17296 --- Comment #86 from John Smith <jsmith_uk(a)ymail.com> 2011-05-29 21:17:45 CDT --- Created an attachment (id=34959) --> (http://bugs.winehq.org/attachment.cgi?id=34959) +secur32|grep schan Fedora 14, wine-1.3.19, winetricks 20110429, samba-winbind-3.5.8, gnutls-2.8.6 + Added ESX IP address to /etc/hosts. + Added ESX certificate to /etc/pki/tls/certs/ca-bundle.crt. This makes OpenSSL happy, but wget and FireFox do not trust ESX certificate. + Attempt to login to ESX by name results in warning about untrusted SSL certificate. If I check 'Don't display any security warnings...' and click Ignore, I get familiar error 'could not establish the initial connection'. Windows registry gets a new key containing SHA-1 fingerprint of the certificate: [HKCU\Software\VMware\Virtual Infrastructure Client\Preferences\UI\SSLIgnore] "hostname:443"="6C91F84997213E3449BB1179FF6BE0ADAD2E4FE0" Looking at the wine debug logs, I am not convinced that this key affects the way a connection attempt is done. GnuTLS either refuses to establish untrusted SSL connection or is unable to establish SSH connection with unsafe re-negotiation (see attached). The only way I can force gnutls-cli to connect to ESX is by specifying --priority "NONE:%UNSAFE_RENEGOTIATION:+VERS-TLS1.0:+AES-256-CBC:+RSA:+SHA1:+COMP-NULL". It comes with a few warnings and errors though: Signature Algorithm: RSA-MD5 warning: signed using a broken signature algorithm that can be forged. - The hostname in the certificate matches 'localhost.enterprise.com'. |<2>| ASSERT: verify.c:281 |<2>| ASSERT: verify.c:474 - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: TLS1.0 - Key Exchange: RSA - Cipher: AES-256-CBC - MAC: SHA1 - Compression: NULL - Session ID: (null) - Handshake was completed gnutls-cli happily establishes connection with AES-128-CBC cipher as well. Ciphersuite RSA_AES_128_CBC_SHA1 is exactly what is failing when vpxClient.exe tries to connect. If I take it right, there is no way to force gnutls to accept self-generated SSL certificate. It has to be done at the application level. But then, when the registry key is in place, the application still fails to connect because of gnutls being stuck with SAFE_RENEGOTIATION. To the best of my belief, this needs to be fixed: fixme:secur32:schan_imp_create_session Using hardcoded "NORMAL" priority If priority here maps to gnutls-cli one to one, then %UNSAFE_RENEGOTIATION is absolutely necessary to talk to ESX. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.