[Bug 17296] VMware Infrastructure Client 2.5 could not validate server's SSL certificate

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=17296

--- Comment #86 from John Smith <jsmith_uk at 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.