http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #86 from John Smith jsmith_uk@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.