[Bug 17296] New: VMware Infrastructure Client 2.5 could not validate server's SSL certificate
http://bugs.winehq.org/show_bug.cgi?id=17296
Summary: VMware Infrastructure Client 2.5 could not validate server's SSL certificate Product: Wine Version: 1.1.14 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: secur32 AssignedTo: kai.blin@gmail.com ReportedBy: wine@doty.ru
While starting VMware Instrastructure Client 2.5 after typing hostname, user and password and hitting Login button, got error: "VMware Infrastructure Client could not establish the initial connection with server 'XX.XX.XX.XX'. Details: The client could not validate the server's SSL certificate".
Console log errors appeared:
fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority fixme:secur32:schan_QueryContextAttributesW Unhandled attribute 0x5a fixme:secur32:schan_QueryContextAttributesW Unhandled attribute 0x53
Thus program could not check servers' SSL certificate and don't run next. I used .NET Framework 2.0 installed with this program version.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #1 from Juan Lang juan_lang@yahoo.com 2009-02-07 21:00:21 --- Not sure why this is getting assigned to Kai. Perhaps because he's the default assignee for secur32?
0x5a is SECPKG_ATTR_CONNECTION_INFO, and 0x53 is SECPKG_ATTR_REMOTE_CERT_CONTEXT. This latter one seems relevant, so I'm guessing you've got the correct component.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #2 from Austin English austinenglish@gmail.com 2009-02-07 21:39:12 --- (In reply to comment #1)
Not sure why this is getting assigned to Kai. Perhaps because he's the default assignee for secur32?
Yes, he is. I presume he requested it, but I don't know that for sure.
http://bugs.winehq.org/show_bug.cgi?id=17296
Kai Blin kai.blin@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|kai.blin@gmail.com |wine-bugs@winehq.org
--- Comment #3 from Kai Blin kai.blin@gmail.com 2009-02-08 02:48:37 --- SSL bug, not NTLM/SPNEGO/Kerberos bug, reassigning.
http://bugs.winehq.org/show_bug.cgi?id=17296
Micha³ Panasiewicz wolvverine@tlen.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #4 from Micha³ Panasiewicz wolvverine@tlen.pl 2009-04-24 10:27:38 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=17296
Steven Edwards winehacker@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehacker@gmail.com
--- Comment #5 from Steven Edwards winehacker@gmail.com 2009-05-08 14:59:36 --- I see this behaviour as well. I need this application for my work so I'm very interested in it.
http://bugs.winehq.org/show_bug.cgi?id=17296
Hubert Mercier anigel@club-internet.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |anigel@club-internet.fr
--- Comment #6 from Hubert Mercier anigel@club-internet.fr 2009-06-08 12:45:28 --- Interested too, and confirmed for wine-1.1.23.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #7 from Steven Edwards winehacker@gmail.com 2009-06-08 13:07:58 --- (In reply to comment #6)
Interested too, and confirmed for wine-1.1.23.
I was able to get the VI client to work for the most part except for the Console (which from what I hear is really VNC and there are other ways to hook in to it, however it seems pretty fast to just be VNC). The only bad thing about it is you need admin access on the VI server to disable the SSL mode and force authentication and communication in over standard HTTP.
This site explains the magic, it took me about 2 hours of tweaking with a different order for install using a newer Wine but I eventually got a mostly working VI client.
http://www.virtualinsanity.com/index.php/2009/02/02/vmware-infrastructure-cl...
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #8 from Hubert Mercier anigel@club-internet.fr 2009-06-08 13:50:23 --- Hi, And thanks for this suggestion. But I need this tool for a cluster administration in a professional environment. Disabling SSL isn't an option :(.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #9 from Hans Leidekker hans@meelstraat.net 2009-06-08 15:12:08 --- Created an attachment (id=21657) --> (http://bugs.winehq.org/attachment.cgi?id=21657) secur32: Partial support for SECPKG_ATTR_REMOTE_CERT_CONTEXT and SECPKG_ATTR_CONNECTION_INFO.
Please apply this patch and attach a WINEDEBUG=+secur32 trace.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #10 from Hubert Mercier anigel@club-internet.fr 2009-06-09 05:06:58 --- Created an attachment (id=21673) --> (http://bugs.winehq.org/attachment.cgi?id=21673) WINEDEBUG=+secur32 log, after patching wine-1.1.23 with previous patch
Here is the result of the trace.
Thanks,
http://bugs.winehq.org/show_bug.cgi?id=17296
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hans@meelstraat.net
--- Comment #11 from Hans Leidekker hans@meelstraat.net 2009-06-09 05:16:53 --- It fails even earlier for you. Try installing the winbind package.
http://bugs.winehq.org/show_bug.cgi?id=17296
Hubert Mercier anigel@club-internet.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #21673|0 |1 is obsolete| |
--- Comment #12 from Hubert Mercier anigel@club-internet.fr 2009-06-09 06:26:24 --- Created an attachment (id=21676) --> (http://bugs.winehq.org/attachment.cgi?id=21676) WINEDEBUG=+secur32 log, after patching wine-1.1.23 with previous patch and compiling winbind
Done ;)
Sorry,
http://bugs.winehq.org/show_bug.cgi?id=17296
Hubert Mercier anigel@club-internet.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #21676|0 |1 is obsolete| |
--- Comment #13 from Hubert Mercier anigel@club-internet.fr 2009-06-09 07:11:09 --- Created an attachment (id=21680) --> (http://bugs.winehq.org/attachment.cgi?id=21680) WINEDEBUG=+secur32 log, after patching wine-1.1.23 with previous patch and compiling winbind
Changed attachment type to plain text.
Sorry,
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #14 from Hans Leidekker hans@meelstraat.net 2009-06-09 07:18:09 --- Still not good, did you build with gnutls support?
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #15 from Hubert Mercier anigel@club-internet.fr 2009-06-09 07:28:03 --- GnuTLS seems not to be available on amd64 gentoo package...
[ebuild R ] app-emulation/wine-1.1.23 USE="X alsa cups gecko jpeg ncurses opengl oss png samba ssl xml (-dbus) -esd (-gnutls) (-hal) -jack -lcms (-ldap) (-nas) (-scanner) -win64 -xcomposite -xinerama" 0 kB [?=>1]
The problem : http://bugs.gentoo.org/show_bug.cgi?id=244422
I'll contact Gentoo devs and come back later.
http://bugs.winehq.org/show_bug.cgi?id=17296
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |juan_lang@yahoo.com
--- Comment #16 from Juan Lang juan_lang@yahoo.com 2009-08-07 18:00:58 --- Any update? If you want to try with 1.1.27, you'll probably need to apply this patch instead of the one attached here: http://www.winehq.org/pipermail/wine-patches/2009-August/076773.html
http://bugs.winehq.org/show_bug.cgi?id=17296
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #21657|0 |1 is obsolete| |
--- Comment #17 from Juan Lang juan_lang@yahoo.com 2009-08-10 10:52:05 --- (From update of attachment 21657) Support for SECPKG_ATTR_REMOTE_CERT_CONTEXT and SECPKG_ATTR_CONNECTION_INFO has been committed, so please retry with current git.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #18 from Hubert Mercier anigel@gmx.fr 2009-08-10 12:08:51 --- Hi,
Little message to let you know that I won't be able to help you anymore with this bug : my VMWare infrastructure has been migrated to vSphere, so I had to update the client too.
So I'll try to help you with client v4.0 now ;).
Cheers,
http://bugs.winehq.org/show_bug.cgi?id=17296
Krzysztof krzysztof.kardas@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |krzysztof.kardas@gmail.com
--- Comment #19 from Krzysztof krzysztof.kardas@gmail.com 2009-08-11 02:38:14 --- (In reply to comment #18)
Hi,
Little message to let you know that I won't be able to help you anymore with this bug : my VMWare infrastructure has been migrated to vSphere, so I had to update the client too.
So I'll try to help you with client v4.0 now ;).
Cheers,
Hi. I have still VMWare infrastructure client 2.5 so I can still help. Cheers Krzysztof Kardas
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #20 from Juan Lang juan_lang@yahoo.com 2009-08-12 13:06:46 --- (In reply to comment #19)
I have still VMWare infrastructure client 2.5 so I can still help.
Very good. Could you retry with current git, or with 1.1.28 when that comes out?
http://bugs.winehq.org/show_bug.cgi?id=17296
Cédric Schieli cschieli@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cschieli@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=17296
fgatwork@verizon.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fgatwork@verizon.net
--- Comment #21 from fgatwork@verizon.net 2009-08-31 12:31:52 --- I have tested this using the wine-snapshot from openSUSE : wine-snapshot-1.1.28.20090830-1.1 and am still receiving the above referenced error when trying to start VMware Infrastructure Client.
I have attached the secur32 debug output as well.
Am looking forward to getting this working. I would only be one app away from removing my Windows vm (Outlook to Exchange 2007).
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #22 from fgatwork@verizon.net 2009-08-31 12:34:11 --- Created an attachment (id=23356) --> (http://bugs.winehq.org/attachment.cgi?id=23356) Wine trace output with +secur32 @ 1.1.28
http://bugs.winehq.org/show_bug.cgi?id=17296
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|secur32 |crypt32 Depends on| |18337
--- Comment #23 from Juan Lang juan_lang@yahoo.com 2009-08-31 12:40:47 --- (In reply to comment #22)
Wine trace output with +secur32 @ 1.1.28
Two errors from the log stand out: fixme:crypt:CertVerifyCertificateChainPolicy unimplemented for 4 fixme:crypt:CertGetNameStringW unimplemented for type 2
The first is complaining that crypt32 doesn't implement CERT_CHAIN_POLICY_SSL. This is bug 18337, which this now depends on. The second is that CertGetNameStringW doesn't implement CERT_NAME_RDN_TYPE.
Both are in crypt32, so changing the component.
http://bugs.winehq.org/show_bug.cgi?id=17296
mouchon lemouchon@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lemouchon@gmail.com
--- Comment #24 from mouchon lemouchon@gmail.com 2009-09-28 07:57:26 --- tried with wine-1.1.30 on ubuntu juntu
and following error
fixme:advapi:DeregisterEventSource (0xcafe4242) stub fixme:wtsapi:WTSQuerySessionInformationW Stub (nil) 0xffffffff 4 0xa5e6f4 0xa5e6ec fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority fixme:crypt:CertVerifyCertificateChainPolicy unimplemented for 4 fixme:crypt:CertVerifyCertificateChainPolicy unimplemented for 4 GNUTLS ERROR: Function was interrupted.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #25 from Juan Lang juan_lang@yahoo.com 2009-10-27 15:59:17 --- Created an attachment (id=24400) --> (http://bugs.winehq.org/attachment.cgi?id=24400) Patch
Does the attached patch help?
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #26 from Frank G. fgatwork@verizon.net 2009-10-27 20:24:10 --- I will try it tomorrow when I get to work on my sandbox. Thanks!!
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #27 from Frank G. fgatwork@verizon.net 2009-10-28 09:47:39 --- k - I applied the patch to the latest code available in git and I can't even get to the point where I can test it. I have opened bug 20502 to report this as it seems to be a regression with some recently merged msi code.
Do you have a private branch that I can base off of to avoid these main line issues?
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #28 from Frank G. fgatwork@verizon.net 2009-10-28 12:33:26 --- k - I applied the patch to the latest code available in git and I can't even get to the point where I can test it. I have opened bug 20502 to report this as it seems to be a regression with some recently merged msi code.
Do you have a private branch that I can base off of to avoid these main line issues?
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #29 from Juan Lang juan_lang@yahoo.com 2009-10-28 12:54:49 --- (In reply to comment #28)
Do you have a private branch that I can base off of to avoid these main line issues?
No, no private branch. You can apply the patch to an older version of the tree too.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #30 from Frank G. fgatwork@verizon.net 2009-10-28 14:26:20 --- Back in action - other issue was resolved and I have now reinstalled the VM Infrastructure Client again.
Now for the results - closer, but not quite there. It looks like it is going into a very hideous loop when trying to validate the self-signed certificate from the server. I redirected output to a log file and, without realizing it, I quickly created a 1.6GB log file. I've truncated it to 1MB to attach here.
The command I used to run it was : env WINEPREFIX="/home/f.gruman/.wine" WINEDEBUG=crypt,secur32 wine "C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\vpxClient.exe" &>vmInfrastructureClient_run.log
Regards, Frank
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #31 from Frank G. fgatwork@verizon.net 2009-10-28 14:28:43 --- Created an attachment (id=24416) --> (http://bugs.winehq.org/attachment.cgi?id=24416) client runtime log with crypt32 and secur debug output.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #32 from Juan Lang juan_lang@yahoo.com 2009-10-28 14:58:52 --- You truncated your log too early. It stops before it's finished loading the root certificates on your system. Please attach a different set. Perhaps the last 1MB instead?
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #33 from Frank G. fgatwork@verizon.net 2009-10-28 15:38:20 --- (In reply to comment #32)
You truncated your log too early. It stops before it's finished loading the root certificates on your system. Please attach a different set. Perhaps the last 1MB instead?
At the end of my 1.6GB log...
f.gruman@pioneer6-l:~/Download> tail -n15 vmInfrastructureClient_run.log trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) f.gruman@pioneer6-l:~/Download>
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #34 from Frank G. fgatwork@verizon.net 2009-10-28 15:54:49 --- (In reply to comment #32)
You truncated your log too early. It stops before it's finished loading the root certificates on your system. Please attach a different set. Perhaps the last 1MB instead?
ok - wowzers - this is going to be heinous. After another peak at the log, I found that the repeating text actually really starts at about line 322667 of my log (~18.5 MB into it). Here is the transition...
322648 trace:crypt:CRYPT_MemEnumCert returning (nil) 322649 trace:crypt:CertFreeCertificateContext (0x1fb9c8) 322650 trace:crypt:Context_Release freeing 0x1fb9c8 322651 trace:crypt:Context_Release 0x1af698's ref count is 1 322652 trace:crypt:CRYPT_CollectionAdvanceEnum returning (nil) 322653 trace:crypt:CRYPT_CollectionEnumCert returning (nil) 322654 trace:crypt:CertFindCertificateInStore returning (nil) 322655 trace:crypt:CRYPT_BuildAlternateContextFromChain (0x1cd8f8, 0x394db40, (nil), 0x1fb9c8) 322656 trace:crypt:CRYPT_BuildAlternateContextFromChain (nil) 322657 trace:crypt:CertGetCertificateChain returning 1 322658 trace:crypt:CertDuplicateCertificateChain (0x1fb9c8) 322659 trace:crypt:CertDuplicateCertificateContext (0x14ee30) 322660 trace:crypt:CertGetCertificateContextProperty (0x14ee30, 101, 0x394d9f0, 0x394da1c) 322661 trace:crypt:CertContext_GetProperty (0x14ee30, 101, 0x394d9f0, 0x394da1c) 322662 trace:crypt:ContextPropertyList_FindProperty (0x14ee58, 101, 0x394d904) 322663 trace:crypt:CertContext_GetProperty returning 0 322664 trace:crypt:CertGetCertificateContextProperty returning 0 322665 trace:crypt:CertDuplicateCertificateContext (0x14ee30) 322666 trace:crypt:CertFreeCertificateChain (0x1fb9c8) 322667 trace:crypt:CertVerifyCertificateChainPolicy (#0001, 0x1fb9c8, 0x394dc28, 0x394dc14) 322668 trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394dca0, 0x394dc3c) 322669 trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) 322670 trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) 322671 trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) 322672 trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) 322673 trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) 322674 trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) 322675 trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) 322676 trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) 322677 trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) 322678 trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) 322679 trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68) 322680 trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1fb9c8, 0x394db8c, 0x394db68)
So - I can put the current log up for your access and review (zipped up, of course) unless you want some other sort of parameters set when I run it.
Regards, Frank
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #35 from Frank G. fgatwork@verizon.net 2009-10-29 08:59:56 ---
So - I can put the current log up for your access and review (zipped up, of course)
You can find the complete logs compressed at http://www.thegrumans.net/transfer/vmInfrastructureClient_run.smallLog.tar.g... (1.1MB), uncompressed = ~18.5MB http://www.thegrumans.net/transfer/vmInfrastructureClient_run.largeLog.tar.g... (6.3MB), uncompressed = ~1.6GB
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #36 from Juan Lang juan_lang@yahoo.com 2009-10-29 10:51:15 --- (In reply to comment #35)
You can find the complete logs compressed at
Thanks. I had a look, and you're right, the client gets into a loop where it's repeatedly calling CertVerifyCertificateChainPolicy. I also looked at the Wine code, and there's no way (short of stack corruption) for Wine to do this. So either there is stack corruption, or the program is barfing on something else. At the moment I don't have any bright ideas, although the ref count bug (bug 20503) could cause corruption.
http://bugs.winehq.org/show_bug.cgi?id=17296
Bug 17296 depends on bug 18337, which changed state.
Bug 18337 Summary: CertVerifyCertificateChainPolicy doesn't implement CERT_CHAIN_POLICY_SSL http://bugs.winehq.org/show_bug.cgi?id=18337
What |Old Value |New Value ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #37 from Juan Lang juan_lang@yahoo.com 2009-10-29 13:22:49 --- Does the patch I sent for bug 20503 help? http://www.winehq.org/pipermail/wine-patches/2009-October/080719.html
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #38 from Juan Lang juan_lang@yahoo.com 2009-10-29 14:52:01 --- (In reply to comment #37)
Does the patch I sent for bug 20503 help? http://www.winehq.org/pipermail/wine-patches/2009-October/080719.html
Update: I actually sent two ref counting patches: http://www.winehq.org/pipermail/wine-patches/2009-October/080729.html http://www.winehq.org/pipermail/wine-patches/2009-October/080730.html
Please try with both applied.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #39 from Frank G. fgatwork@verizon.net 2009-10-29 19:35:04 ---
Please try with both applied.
Applied both patches and the issue is not resolved. I have uploaded the log: http://www.thegrumans.net/transfer/vmInfrastructureClient_run.10292009-1.tar...
Thanks for working on this. If there is anything I can do to make the testing more effective, please let me know.
Regards, Frank
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #40 from Juan Lang juan_lang@yahoo.com 2009-10-29 19:42:21 --- (In reply to comment #39)
Thanks for working on this. If there is anything I can do to make the testing more effective, please let me know.
Thanks for testing it. Here's something you can do: please capture a +relay log. It'll get massive, but I don't need the whole thing. I'm curious what's going on between each successive CertVerifyCertificateChainPolicy call.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #41 from Frank G. fgatwork@verizon.net 2009-10-29 21:21:49 ---
Thanks for testing it. Here's something you can do: please capture a +relay log. It'll get massive, but I don't need the whole thing. I'm curious what's going on between each successive CertVerifyCertificateChainPolicy call.
Knowing a little about what I've been seeing in the logs, here is a command I used to parse this massive pig: This is the first run of the method 'cat -n vmInfrastructureClient_run3.log |grep "CertVerifyCertificateChainPolicy (#0001"' These are the first two lines containing the loops. 'cat -n vmInfrastructureClient_run3.log |grep "CertVerifyCertificateChainPolicy (#0004" |head -2 |tail -2' Pretty much gets everything from the place we start into the verify method until we start looping. 'cat -n vmInfrastructureClient_run3.log |head -1165209 |tail -275'
This partial log is here: http://www.thegrumans.net/transfer/vmInfrastructureClient_run.10292009-2.par...
This is the place where we start the CertVerifyCertificateChainPolicy: 1164953 trace:crypt:CertVerifyCertificateChainPolicy (#0001, 0x3a0cac8, 0x38ddc28, 0x38ddc14)
Then we start the actual looping: 1165172 0057:Ret KERNEL32.SetLastError() retval=800b0109 ret=79e7bba9 1165173 0057:Call KERNEL32.InterlockedCompareExchange(00b929d8,00000008,00000004) ret=79ef5742 1165174 0057:Ret KERNEL32.InterlockedCompareExchange() retval=00000004 ret=79ef5742 1165175 0057:Call crypt32.CertVerifyCertificateChainPolicy(00000004,03a0cac8,038ddca0,038ddc3c) ret=02c562e8 1165176 trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x3a0cac8, 0x38ddca0, 0x38ddc3c) 1165177 0057:Ret crypt32.CertVerifyCertificateChainPolicy() retval=00000001 ret=02c562e8 1165178 0057:Call KERNEL32.GetLastError() ret=02c562ee 1165179 0057:Ret KERNEL32.GetLastError() retval=800b0109 ret=02c562ee 1165180 0057:Call KERNEL32.InterlockedCompareExchange(00b929d8,00000004,00000008) ret=79ef56cc 1165181 0057:Ret KERNEL32.InterlockedCompareExchange() retval=00000008 ret=79ef56cc 1165182 0057:Call KERNEL32.GetUserDefaultLCID() ret=0036a7e3 1165183 0057:Ret KERNEL32.GetUserDefaultLCID() retval=00000409 ret=0036a7e3 1165184 0057:Call KERNEL32.GetLastError() ret=0036a7e9 1165185 0057:Ret KERNEL32.GetLastError() retval=800b0109 ret=0036a7e9 1165186 0057:Call KERNEL32.FormatMessageW(00001200,00000000,800b0109,00000409,001fb5c8,000001ff,00000000) ret=02c53bc4 1165187 0057:Ret KERNEL32.FormatMessageW() retval=00000000 ret=02c53bc4 1165188 0057:Call KERNEL32.GetLastError() ret=02c53bca 1165189 0057:Ret KERNEL32.GetLastError() retval=00000717 ret=02c53bca 1165190 0057:Call KERNEL32.GetLastError() ret=79e8e15b 1165191 0057:Ret KERNEL32.GetLastError() retval=00000717 ret=79e8e15b 1165192 0057:Call KERNEL32.SetLastError(00000717) ret=79e8e1ca 1165193 0057:Ret KERNEL32.SetLastError() retval=00000717 ret=79e8e1ca 1165194 0057:Call KERNEL32.InterlockedCompareExchange(00b92114,00000008,00000004) ret=79ef5742 1165195 0057:Ret KERNEL32.InterlockedCompareExchange() retval=00000004 ret=79ef5742 1165196 0057:Call KERNEL32.InterlockedCompareExchange(00b92114,00000004,00000008) ret=79ef56cc 1165197 0057:Ret KERNEL32.InterlockedCompareExchange() retval=00000008 ret=79ef56cc 1165198 0057:Call KERNEL32.InterlockedCompareExchange(00b934e8,00000008,00000004) ret=79ef5742 1165199 0057:Ret KERNEL32.InterlockedCompareExchange() retval=00000004 ret=79ef5742 1165200 0057:Call crypt32.CertVerifyCertificateChainPolicy(00000004,03a0cac8,038ddb8c,038ddb68) ret=02c562e8 1165201 trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x3a0cac8, 0x38ddb8c, 0x38ddb68) 1165202 0057:Ret crypt32.CertVerifyCertificateChainPolicy() retval=00000001 ret=02c562e8 1165203 0057:Call KERNEL32.GetLastError() ret=02c562ee 1165204 0057:Ret KERNEL32.GetLastError() retval=00000717 ret=02c562ee 1165205 0057:Call KERNEL32.InterlockedCompareExchange(00b934e8,00000004,00000008) ret=79ef56cc 1165206 0057:Ret KERNEL32.InterlockedCompareExchange() retval=00000008 ret=79ef56cc 1165207 0057:Call KERNEL32.InterlockedCompareExchange(00b934e8,00000008,00000004) ret=79ef5742 1165208 0057:Ret KERNEL32.InterlockedCompareExchange() retval=00000004 ret=79ef5742 1165209 0057:Call crypt32.CertVerifyCertificateChainPolicy(00000004,03a0cac8,038ddb8c,038ddb68) ret=02c562e8
The full log (26MB compressed, 3.8GB full) can be found at http://www.thegrumans.net/transfer/vmInfrastructureClient_run.10292009-2.tar...
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #42 from Juan Lang juan_lang@yahoo.com 2009-10-29 22:13:24 --- (In reply to comment #41)
1165178 0057:Call KERNEL32.GetLastError() ret=02c562ee 1165179 0057:Ret KERNEL32.GetLastError() retval=800b0109 ret=02c562ee
Setting aside why it's looping--I have no idea what it's expecting to change--this error gives a hint. 0x800b0109 is CERT_E_UNTRUSTEDROOT. Is the root certificate installed on your system? Wine doesn't install any certificates itself, and restricts itself to those installed on your machine. Those sometimes differ between Windows and *ix.
Also, it may be that the installation instructions direct you to install a root certificate, I don't know. For example, the following VMware kb article seems to imply that you may have to install a root certificate under Windows/Wine: http://kb.vmware.com/kb/4646606
http://bugs.winehq.org/show_bug.cgi?id=17296
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #24400|0 |1 is obsolete| |
--- Comment #43 from Juan Lang juan_lang@yahoo.com 2009-10-30 15:05:59 --- (From update of attachment 24400) An improved version of this was already committed.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #44 from Juan Lang juan_lang@yahoo.com 2009-10-30 15:09:05 --- You should be able to test with latest git, by the way, rather than applying any patches referenced here. Except this one: http://www.winehq.org/pipermail/wine-patches/2009-October/080763.html
I noticed in your full +relay,+crypt log that quite a few certs were rejected due to bad usage. These could be the source of untrusted roots. Oops. Please apply that patch and try again.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #45 from Frank G. fgatwork@verizon.net 2009-11-05 15:23:50 --- (In reply to comment #44)
You should be able to test with latest git, by the way, rather than applying any patches referenced here. Except this one: http://www.winehq.org/pipermail/wine-patches/2009-October/080763.html
I noticed in your full +relay,+crypt log that quite a few certs were rejected due to bad usage. These could be the source of untrusted roots. Oops. Please apply that patch and try again.
More testing and no love (although I feel it's close)
I got the latest git pull as of this morning (which seems to have included the above patch) and still no love. I can see in the log output that I am still getting "trace:crypt:CryptDecodeObjectEx returning 1" which I am assuming is a failure (zero being success).
I have verified that I have imported the self-signed certificate as both a trusted and CA certificate (certmgr -list -c Trust and again with CA).
Once again, you can find log output at http://www.thegrumans.net/transfer/vmInfrastructureClient_run.11052009-2.par.... I truncated this log at 1.1 million lines. I think this is well past where it starts looping again. The full log is http://www.thegrumans.net/transfer/vmInfrastructureClient_run.11052009.tar.g...
Thanks for waiting for my feedback. Frank
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #46 from Juan Lang juan_lang@yahoo.com 2009-11-05 15:39:32 --- (In reply to comment #45)
I got the latest git pull as of this morning (which seems to have included the above patch) and still no love. I can see in the log output that I am still getting "trace:crypt:CryptDecodeObjectEx returning 1" which I am assuming is a failure (zero being success).
No, 1 is success for BOOL, which is what CryptDecodeObjectEx returns.
I have verified that I have imported the self-signed certificate as both a trusted and CA certificate (certmgr -list -c Trust and again with CA).
Trust isn't the appropriate store on Wine. Root is. Could you try again, importing it into root instead?
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #47 from Frank G. fgatwork@verizon.net 2009-11-05 16:04:18 --- (In reply to comment #46)
Trust isn't the appropriate store on Wine. Root is. Could you try again, importing it into root instead?
OK - I am going to have to ask for an extra hand here - I have used certmgr (which I have used for some of my .Net/Mono SSL work) and I have used keytool (for Java work) and I have imported the certificate for use with Firefox so that the browser does not complain. Apparently none of these tools imports the certificate and puts it in a place that is friendly for Wine.
How do I import this certificate for Wine to see and use?
Frank
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #48 from Juan Lang juan_lang@yahoo.com 2009-11-05 16:22:57 --- (In reply to comment #47)
How do I import this certificate for Wine to see and use?
Wine reads the certs from your distro, so you'll have to install it using whatever mechanism is appropriate for your distro. On your system, I think they're installed in /etc/ssl/certs, and they're in PEM format. So if you have a cert in DER format (binary), you'd have to convert it first, e.g.: $ openssl rsa -inform DER -outform PEM -in cert.crt -out cert.pem then copy it to /etc/ssl/certs.
(Maybe Wine should use the Trust store too, but that'd be a different bug.)
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #49 from Juan Lang juan_lang@yahoo.com 2009-11-05 17:02:15 --- Created an attachment (id=24565) --> (http://bugs.winehq.org/attachment.cgi?id=24565) Patch: Allow certificates in the Trust store to be trusted roots
You could also try this patch, which should allow you to keep your current config (with the VMware cert in the Trust store).
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #50 from Frank G. fgatwork@verizon.net 2009-11-05 23:14:53 --- Well - there is mostly good news, and a little bad news.
First, the bad news. it's not _all_ the way there yet.
The good news, I am now able to accept or pass the certificate validation. I ended up putting in your latest patch for looking at Trusted (this is perhaps a Mono container since certmgr is a Mono tool?). I had applied the patch and done another build and test without any good results until just dumb luck pushed me to what seems to have worked.
What I DID do: - VMware stores the certificate and key in C:\Documents and Settings\All Users\Application Data\VMware\VMWare Server\SSL\rui.[crt|key] on the server. - I moved both of those files to my Linux client. - run the following 2 commands: cat rui.crt > VMware-SelfSigned.pem cat rui.key >> VMware-SelfSigned.pem - As root, copy VMware-SelfSigned.pem to system local key store (on openSUSE, it is /etc/ssl/certs, can't speak for any others)
After this, when starting the vpxClient.exe, I am presented with the same certificate warning I received in Windows - untrusted SSL certificate - (I danced a jig at this point). At this point, I can view the certificate and install it or choose to ignore the warning and continue. When I continue, I am getting a communications error.
On a side note, I read on several forums that VMware uses pkcs12 rather than rsa for their keys. Perhaps there is a more reliable way to generate the .pem than my method? (i.e. my concatenation might just be the cause of my second problem).
I will plug on that one tomorrow.
Regards, Frank
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #51 from Juan Lang juan_lang@yahoo.com 2009-11-06 10:47:24 --- (In reply to comment #50)
What I DID do:
- VMware stores the certificate and key in C:\Documents and Settings\All
Users\Application Data\VMware\VMWare Server\SSL\rui.[crt|key] on the server.
- I moved both of those files to my Linux client.
- run the following 2 commands: cat rui.crt > VMware-SelfSigned.pem cat rui.key >> VMware-SelfSigned.pem
- As root, copy VMware-SelfSigned.pem to system local key store (on openSUSE,
it is /etc/ssl/certs, can't speak for any others)
You shouldn't need the key on the client. Also, by copying it to the /etc/ssl/certs directory, you don't need to apply the patch to use the Trust store: the Root store is mapped to /etc/ssl/certs, and the chain verification code already trusts those.
After this, when starting the vpxClient.exe, I am presented with the same certificate warning I received in Windows - untrusted SSL certificate - (I danced a jig at this point). At this point, I can view the certificate and install it or choose to ignore the warning and continue. When I continue, I am getting a communications error.
What's the console output at this point? I don't need any particular debug flags yet, I'm curious what output, if any, there is. If there isn't anything "interesting", perhaps another +crypt,+chain log would be in order.
On a side note, I read on several forums that VMware uses pkcs12 rather than rsa for their keys. Perhaps there is a more reliable way to generate the .pem than my method? (i.e. my concatenation might just be the cause of my second problem).
That statement doesn't make sense to me. pkcs12 is a data format (which Wine doesn't implement, see bug 11070), RSA is a cipher. In any case, the .crt file is most likely either in DER format or it's base64 encoded DER. At least, that's what the extension implies. If it's the former, it'll be binary, and if it's the latter, it'll be legible. A quick glance at it with your favorite editor will tell you. Either way, pkcs12 vs. rsa is a red herring, I believe.
If you omit concatenating the key, and the .crt works as before, and the .crt file is base64 encoded, it's already in .pem format, or near enough to it.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #52 from Frank G. fgatwork@verizon.net 2009-11-12 10:27:37 --- Juan,
Apologies for trying to muddy the waters with my ignorance.
The error thrown from the client is the generic "Details: A communication error occurred receiving data from the server."
A snippet of the log at that point is: 324059 trace:crypt:CertVerifyCertificateChainPolicy (#0001, 0x1bd2a0, 0x38edc28, 0x38edc14) 324060 trace:crypt:CertVerifyCertificateChainPolicy returning 1 (00000000) 324061 trace:crypt:CertVerifyCertificateChainPolicy (#0004, 0x1bd2a0, 0x38edca0, 0x38edc3c) 324062 trace:crypt:CertFindExtension "2.5.29.17" 0 (nil) 324063 trace:crypt:CertFindExtension "2.5.29.7" 0 (nil) 324064 trace:chain:match_dns_to_subject_dn L"vulcan" 324065 trace:crypt:CryptDecodeObjectEx (0x00000001, #0014, 0x1bcdc4, 227, 0x00008001, (nil), 0x38edaf8, 0x38edaf4) 324066 trace:crypt:CryptDecodeObjectEx returning 1 324067 trace:crypt:CertFindRDNAttr "0.9.2342.19200300.100.1.25" 0x1bd350 324068 trace:crypt:CertFindRDNAttr "2.5.4.3" 0x1bd350 324069 trace:chain:match_dns_to_subject_dn CN = L"VULCAN" 324070 trace:crypt:CertVerifyCertificateChainPolicy returning 1 (00000000) 324071 trace:crypt:CertGetCertificateContextProperty (0x1516f0, 3, (nil), 0x38ed6a4) 324072 trace:crypt:CertContext_GetProperty (0x1516f0, 3, (nil), 0x38ed6a4) 324073 trace:crypt:ContextPropertyList_FindProperty (0x1fce58, 3, 0x38ed588) 324074 trace:crypt:CertContext_GetProperty returning 1 324075 trace:crypt:CertGetCertificateContextProperty returning 1 324076 trace:crypt:CertGetCertificateContextProperty (0x1516f0, 3, 0xa2c904, 0x38ed6a4) 324077 trace:crypt:CertContext_GetProperty (0x1516f0, 3, 0xa2c904, 0x38ed6a4) 324078 trace:crypt:ContextPropertyList_FindProperty (0x1fce58, 3, 0x38ed588) 324079 trace:crypt:CertContext_GetProperty returning 1 324080 trace:crypt:CertGetCertificateContextProperty returning 1 324081 trace:crypt:CertFreeCertificateChain (0x1fa7c0) 324082 trace:crypt:CertFreeCertificateContext (0x1516f0) 324083 trace:crypt:CertCloseStore (0x1ab170, 00000000) 324084 trace:crypt:CertCloseStore 0x1ab170's ref count is 0, freeing 324085 trace:crypt:CRYPT_CollectionCloseStore (0x1ab170, 00000000) 324086 trace:crypt:CRYPT_CollectionCloseStore closing 0x1ab1d8 324087 trace:crypt:CertCloseStore (0x1b0470, 00000000) 324088 trace:crypt:CertCloseStore 0x1b0470's ref count is 1 324089 trace:crypt:CertFreeCertificateContext (0x1516f0) 324090 trace:crypt:CertFreeCertificateContext (0x1516f0) 324091 GNUTLS ERROR: Function was interrupted. 324092 fixme:ntdll:RtlNtStatusToDosErrorNoTeb no mapping for c0000109
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #53 from Juan Lang juan_lang@yahoo.com 2009-11-12 11:32:03 --- (In reply to comment #52) Thanks for the follow-up, Frank. Now we have a new culprit:
324091 GNUTLS ERROR: Function was interrupted.
This indicates the error is no longer in crypt32 (w00t!), and it's moved on to an schannel error. You could try the patch in bug 3254: http://bugs2.winehq.org/attachment.cgi?id=23392
http://bugs.winehq.org/show_bug.cgi?id=17296
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|crypt32 |secur32
--- Comment #54 from Juan Lang juan_lang@yahoo.com 2009-11-12 11:32:55 --- Forgot to change component.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #55 from Frank G. fgatwork@verizon.net 2009-11-12 12:51:24 --- No joy. Same error.
The full log (+chain, + crypt) is available at http://www.thegrumans.net/transfer/vmInfrastructureClient_run.11122009.tar.g... (approx 1MB).
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #56 from Juan Lang juan_lang@yahoo.com 2009-11-12 13:04:36 --- Okay. Since the crypt32 error appears to be fixed, crypt,chain logs are no longer very interesting. secur32 ones might be more interesting.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #57 from Frank G. fgatwork@verizon.net 2009-11-12 13:05:47 --- (Mid-air collision on comments) hrmmmm - Google is my friend - I searched on that GNUTLS message and was provided the following script and resulting output.
echo QUIT |gnutls-cli --print-cert --starttls --port 8333 vulcan Resolving 'vulcan'... Connecting to '10.0.0.31:8333'...
- Simple Client Mode:
*** Starting TLS handshake *** Fatal error: A TLS packet with unexpected length was received. *** Handshake has failed
FYI (if not obvious) - vulcan is the name of the vm server.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #58 from Frank G. fgatwork@verizon.net 2009-11-12 13:13:19 --- And voila - here appears to be a problem...
573 trace:secur32:schan_gnutls_log <4> REC[7c0bb090]: Expected Packet[1] Application Data(23) with length: 37 574 trace:secur32:schan_gnutls_log <4> REC[7c0bb090]: Received Packet[1] Application Data(23) with length: 32 575 trace:secur32:schan_pull Pull 32 bytes 576 trace:secur32:schan_get_buffer Using buffer 0: cbBuffer 37, BufferType 0x1, pvBuffer 0xa28354 577 trace:secur32:schan_pull Read 32 bytes 578 trace:secur32:schan_gnutls_log <4> REC[7c0bb090]: Decrypted Packet[1] Application Data(23) with length: 0 579 trace:secur32:schan_pull Pull 5 bytes 580 trace:secur32:schan_get_buffer Using buffer 0: cbBuffer 37, BufferType 0x1, pvBuffer 0xa28354 581 trace:secur32:schan_get_buffer No next buffer 582 trace:secur32:schan_gnutls_log <2> ASSERT: gnutls_buffers.c:360 583 GNUTLS ERROR: Function was interrupted. 584 trace:secur32:schan_DecryptMessage Returning SEC_E_INCOMPLETE_MESSAGE 585 fixme:ntdll:RtlNtStatusToDosErrorNoTeb no mapping for c0000109 586 trace:secur32:DeleteSecurityContext 0xa26948
Full log (+secur32) available at http://www.thegrumans.net/transfer/vmInfrastructureClient_run.11122009-2.tar...
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #59 from Juan Lang juan_lang@yahoo.com 2009-11-24 15:47:15 --- (In reply to comment #58)
583 GNUTLS ERROR: Function was interrupted.
You might try this patch from bug 20748: http://bugs2.winehq.org/attachment.cgi?id=24832
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #60 from Frank G. fgatwork@verizon.net 2009-11-24 16:52:00 --- No joy. The same error still occurs (using the +secur32 debug parameter).
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #61 from Juan Lang juan_lang@yahoo.com 2010-03-18 14:31:51 --- Sorry I didn't spot this earlier. Could you try this patch from bug 3254? http://bugs2.winehq.org/attachment.cgi?id=23392
http://bugs.winehq.org/show_bug.cgi?id=17296
Andras Kovacs andras@csevego.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andras@csevego.net
--- Comment #62 from Andras Kovacs andras@csevego.net 2010-03-19 06:04:26 --- (In reply to comment #61)
Sorry I didn't spot this earlier. Could you try this patch from bug 3254? http://bugs2.winehq.org/attachment.cgi?id=23392
It still freezes with saying "Connecting...". +crypt dispalys this messages continously: trace:crypt:CertVerifyCertificateChainPolicy (#0004, ...
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #63 from Juan Lang juan_lang@yahoo.com 2010-03-19 10:51:21 --- (In reply to comment #62)
It still freezes with saying "Connecting...". +crypt dispalys this messages continously: trace:crypt:CertVerifyCertificateChainPolicy (#0004, ...
Hmmm. Could you attach a +crypt,+chain,+relay log between one of these CertVerifyCertificateChainPolicy calls and the next?
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #64 from Andras Kovacs andras@csevego.net 2010-03-19 13:44:11 --- Created an attachment (id=26894) --> (http://bugs.winehq.org/attachment.cgi?id=26894) +crypt,+chain,+relay log (last 2000 lines before kill)
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #65 from Andras Kovacs andras@csevego.net 2010-03-19 14:19:10 --- Infrastructure Client error message:
vSphere Client could not connect with the vCenter Server "servername.hu".
Details: The server took too long to respond. (The operation has timed out)
[OK]
----
Console output:
fixme:sync:CreateMemoryResourceNotification (0) stub err:ole:CoGetContextToken apartment not initialised fixme:win:EnumDisplayDevicesW ((null),0,0x32dce8,0x00000000), stub! fixme:crypt:SystemFunction041 (0x18566c, 10, 0): stub [RtlDecryptMemory] fixme:dciman:DCICreatePrimary 0x600 0x3ad12ac fixme:crypt:SystemFunction040 (0x17897c, 10, 0): stub [RtlEncryptMemory] fixme:ras:RasEnumConnectionsW (0x199050,0x45ce258,0x45ce254),stub! fixme:ras:RasEnumConnectionsW RAS support is not implemented! Configure program to use LAN connection/winsock instead! fixme:winsock:WSAIoctl -> SIO_ADDRESS_LIST_CHANGE request: stub fixme:ras:RasConnectionNotificationW (0xffffffff,0x1fc,0x00000003),stub! fixme:crypt:SystemFunction040 (0x19ee1c, 10, 0): stub [RtlEncryptMemory] fixme:winsock:WSAIoctl -> SIO_ADDRESS_LIST_CHANGE request: stub fixme:iphlpapi:GetAdaptersAddresses no support for IPv6 addresses fixme:iphlpapi:GetAdaptersAddresses no support for IPv6 addresses err:ntlm:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. err:ntlm:SECUR32_initNTLMSP Usually, you can find it in the winbind package of your distribution. fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority fixme:crypt:CRYPT_CriticalExtensionsSupported unsupported critical extension "2.5.29.32" fixme:crypt:CRYPT_CriticalExtensionsSupported unsupported critical extension "2.5.29.32" fixme:thread:NtQueryInformationThread info class 16 not supported yet fixme:thread:NtQueryInformationThread info class 16 not supported yet fixme:thread:NtQueryInformationThread info class 16 not supported yet fixme:thread:NtQueryInformationThread info class 16 not supported yet fixme:thread:NtQueryInformationThread info class 16 not supported yet fixme:crypt:SystemFunction040 (0x19edbc, 10, 0): stub [RtlEncryptMemory] fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority fixme:thread:NtQueryInformationThread info class 16 not supported yet fixme:thread:NtQueryInformationThread info class 16 not supported yet fixme:thread:NtQueryInformationThread info class 16 not supported yet
Please note I am using vSphere Client 4.0, because we are using it with ESXi 4.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #66 from Juan Lang juan_lang@yahoo.com 2010-03-19 14:56:07 --- Thanks. Here's the trouble:
trace:chain:match_dns_to_subject_alt_name L"vmhost7.sze.hu" trace:chain:match_dns_to_subject_alt_name dNSName: L"localhost.localdomain" trace:crypt:CertVerifyCertificateChainPolicy returning 1 (800b010f)
The servername you're connecting to is vmhost7.sze.hu, yet the DNS name in the certificate is localhost.localdomain. This violates the SSL policy: the servername you're connecting to must match the name in the certificate, as the name in the certificate is bound to the certificate.
You need to regenerate the certificate with the name vmhost7.sze.hu in it, rather than localhost.localdomain. If VMware is generating the certificate automatically, then your DNS settings probably need to be adjusted. (Try modifying /etc/hosts so that 127.0.0.1 points to vmhost7.sze.hu, for example.)
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #67 from Andras Kovacs andras@csevego.net 2010-03-19 15:53:04 --- (In reply to comment #66) On windows this windows shows: http://mgmt.sth.sze.hu/~andras/vmwarecert.png
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #68 from Juan Lang juan_lang@yahoo.com 2010-03-19 16:06:44 --- (In reply to comment #67)
On windows this windows shows: http://mgmt.sth.sze.hu/~andras/vmwarecert.png
That's interesting. Out of curiosity, does a +wintrust log have any output?
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #69 from Andras Kovacs andras@csevego.net 2010-03-19 16:09:50 --- (In reply to comment #68)
(In reply to comment #67)
On windows this windows shows: http://mgmt.sth.sze.hu/~andras/vmwarecert.png
That's interesting. Out of curiosity, does a +wintrust log have any output?
Further investigation:
If I force return value to TRUE and set dwError to 0 in CertVerifyCertificateChainPolicy, the client displays that warning message, what i posted previously. I think windows accepts that certificate, but wine's crypt32 does not. After clicking Ignore, this error message displayed: A communication error occurred receiving data from the server. (The underlying connection was closed: An unexpected error occurred on a receive.)
Console output displays GNUTLS error: fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority GNUTLS ERROR: Resource temporarily unavailable, try again. fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority GNUTLS ERROR: Resource temporarily unavailable, try again.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #70 from Andras Kovacs andras@csevego.net 2010-03-19 16:11:25 --- (In reply to comment #68)
(In reply to comment #67)
...
That's interesting. Out of curiosity, does a +wintrust log have any output?
No, +wintrust does not have any output.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #71 from Juan Lang juan_lang@yahoo.com 2010-03-19 16:48:09 --- (In reply to comment #69)
If I force return value to TRUE and set dwError to 0 in CertVerifyCertificateChainPolicy, the client displays that warning message, what i posted previously. I think windows accepts that certificate, but wine's crypt32 does not.
If it's possible to send me the certificate, I can try to test it on Windows.
After clicking Ignore, this error message displayed: A communication error occurred receiving data from the server. (The underlying connection was closed: An unexpected error occurred on a receive.)
Console output displays GNUTLS error: fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority GNUTLS ERROR: Resource temporarily unavailable, try again. fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority GNUTLS ERROR: Resource temporarily unavailable, try again.
These look like the secur32 errors for which I linked some patches before:
From bug 20748:
http://bugs2.winehq.org/attachment.cgi?id=24832
From bug 3254:
http://bugs2.winehq.org/attachment.cgi?id=23392
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #72 from Andras Kovacs andras@csevego.net 2010-03-19 16:53:25 --- (In reply to comment #71) (...)
These look like the secur32 errors for which I linked some patches before: From bug 20748: http://bugs2.winehq.org/attachment.cgi?id=24832 From bug 3254: http://bugs2.winehq.org/attachment.cgi?id=23392
Both of them applied, but same error.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #73 from Juan Lang juan_lang@yahoo.com 2010-03-19 17:03:40 --- (In reply to comment #72)
Both of them applied, but same error.
Okay. So, to summarize: both you and Frank had trouble with your certificates. Frank's was an installation problem. Yours looks like an invalid certificate, but perhaps there's a crypt32 bug with it too. Even after getting past the certificate problems, neither of you is able to connect, and it appears that secur32 is to blame.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #74 from Frank G. fgatwork@verizon.net 2010-03-22 08:21:48 --- (In reply to comment #61)
Sorry I didn't spot this earlier. Could you try this patch from bug 3254? http://bugs2.winehq.org/attachment.cgi?id=23392
I applied this patch this morning with the latest git pull and it did not change anything for me, either.
trace:secur32:schan_DecryptMessage context_handle 0x1e2b30, message 0x92de4c, message_seq_no 0, quality (nil) trace:secur32:dump_buffer_desc Buffer desc 0x92de4c: trace:secur32:dump_buffer_desc buffer 0: cbBuffer 37, BufferType 0x1 pvBuffer 0x92dd9c trace:secur32:dump_buffer_desc buffer 1: cbBuffer 0, BufferType 0 pvBuffer (nil) trace:secur32:dump_buffer_desc buffer 2: cbBuffer 0, BufferType 0 pvBuffer (nil) trace:secur32:dump_buffer_desc buffer 3: cbBuffer 0, BufferType 0 pvBuffer (nil) trace:secur32:schan_pull Pull 5 bytes trace:secur32:schan_get_buffer Using buffer 0: cbBuffer 37, BufferType 0x1, pvBuffer 0x92dd9c trace:secur32:schan_pull Read 5 bytes trace:secur32:schan_gnutls_log <4> REC[7c0c1260]: Expected Packet[1] Application Data(23) with length: 37 trace:secur32:schan_gnutls_log <4> REC[7c0c1260]: Received Packet[1] Application Data(23) with length: 32 trace:secur32:schan_pull Pull 32 bytes trace:secur32:schan_get_buffer Using buffer 0: cbBuffer 37, BufferType 0x1, pvBuffer 0x92dd9c trace:secur32:schan_pull Read 32 bytes trace:secur32:schan_gnutls_log <4> REC[7c0c1260]: Decrypted Packet[1] Application Data(23) with length: 0 trace:secur32:schan_pull Pull 5 bytes trace:secur32:schan_get_buffer Using buffer 0: cbBuffer 37, BufferType 0x1, pvBuffer 0x92dd9c trace:secur32:schan_get_buffer No next buffer trace:secur32:schan_gnutls_log <2> ASSERT: gnutls_buffers.c:360 GNUTLS ERROR: Function was interrupted. trace:secur32:schan_DecryptMessage Returning SEC_E_INCOMPLETE_MESSAGE
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #75 from Andras Kovacs andras@csevego.net 2010-05-21 21:40:31 --- Same here.
(In reply to comment #74)
(In reply to comment #61)
Sorry I didn't spot this earlier. Could you try this patch from bug 3254? http://bugs2.winehq.org/attachment.cgi?id=23392
I applied this patch this morning with the latest git pull and it did not change anything for me, either.
trace:secur32:schan_DecryptMessage context_handle 0x1e2b30, message 0x92de4c, message_seq_no 0, quality (nil) trace:secur32:dump_buffer_desc Buffer desc 0x92de4c: trace:secur32:dump_buffer_desc buffer 0: cbBuffer 37, BufferType 0x1 pvBuffer 0x92dd9c trace:secur32:dump_buffer_desc buffer 1: cbBuffer 0, BufferType 0 pvBuffer (nil) trace:secur32:dump_buffer_desc buffer 2: cbBuffer 0, BufferType 0 pvBuffer (nil) trace:secur32:dump_buffer_desc buffer 3: cbBuffer 0, BufferType 0 pvBuffer (nil) trace:secur32:schan_pull Pull 5 bytes trace:secur32:schan_get_buffer Using buffer 0: cbBuffer 37, BufferType 0x1, pvBuffer 0x92dd9c trace:secur32:schan_pull Read 5 bytes trace:secur32:schan_gnutls_log <4> REC[7c0c1260]: Expected Packet[1] Application Data(23) with length: 37 trace:secur32:schan_gnutls_log <4> REC[7c0c1260]: Received Packet[1] Application Data(23) with length: 32 trace:secur32:schan_pull Pull 32 bytes trace:secur32:schan_get_buffer Using buffer 0: cbBuffer 37, BufferType 0x1, pvBuffer 0x92dd9c trace:secur32:schan_pull Read 32 bytes trace:secur32:schan_gnutls_log <4> REC[7c0c1260]: Decrypted Packet[1] Application Data(23) with length: 0 trace:secur32:schan_pull Pull 5 bytes trace:secur32:schan_get_buffer Using buffer 0: cbBuffer 37, BufferType 0x1, pvBuffer 0x92dd9c trace:secur32:schan_get_buffer No next buffer trace:secur32:schan_gnutls_log <2> ASSERT: gnutls_buffers.c:360 GNUTLS ERROR: Function was interrupted. trace:secur32:schan_DecryptMessage Returning SEC_E_INCOMPLETE_MESSAGE
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #76 from Juan Lang juan_lang@yahoo.com 2010-05-22 11:02:18 --- Nit: please don't quote the entire last post without good reason, it just adds noise.
There are other uncommitted patches to secur32 floating around in various bugs, you might try them too, e.g. this patch: http://bugs2.winehq.org/attachment.cgi?id=27672 to bug 21870.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #77 from Andras Kovacs andras@csevego.net 2010-08-01 12:20:48 --- Created an attachment (id=29965) --> (http://bugs.winehq.org/attachment.cgi?id=29965) everything from certificate generation process
Juan, I generated a new certificate (this is broken too in wine as the origial), that you can test as mentioned several months before. I echoed in the original script rm commands, so I can attach CA & confs here.
Here is the modified generate-certificates.sh script's output:
hostname: localhost.sth.sze.hu: Unknown host Generating a 2048 bit RSA private key ....+++ ......+++ writing new private key to '/etc/vmware/ssl/ca.key' ----- rm -f -- /tmp/cert.cnf.pgaSZS Generating a 2048 bit RSA private key .......................+++ ................................................................................................................+++ writing new private key to '/etc/vmware/ssl/rui.key' ----- Signature ok subject=/C=US/ST=California/L=Palo Alto/O=VMware, Inc/OU=VMware ESX Server Default Certificate/emailAddress=ssl-certificates@vmware.com/CN=localhost.localdomain/unstructuredName=1280689604,564d7761726520496e632e Getting CA Private Key rm -f -- /tmp/hostcert.cnf.C5EoZV rm -f -- /etc/vmware/ssl/ca.crt rm -f -- /etc/vmware/ssl/ca.key rm -f -- /etc/vmware/ssl/ca.srl
http://bugs.winehq.org/show_bug.cgi?id=17296
Adam Bolte boltronics@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |boltronics@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #78 from Juan Lang juan_lang@yahoo.com 2010-08-04 12:17:00 --- Created an attachment (id=30005) --> (http://bugs.winehq.org/attachment.cgi?id=30005) Test case patch
Thanks for the certs. I converted them to a test case to show that crypt32 is doing the correct thing: vmhost7.sze.hu should fail to validate against a cert issued to localhost.localdomain. The test passes winetestbot (excepting unrelated test failures on Win98.) That doesn't mean there isn't a Wine bug, it just means that the bug is elsewhere.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #79 from Juan Lang juan_lang@yahoo.com 2010-08-04 15:11:02 --- Created an attachment (id=30007) --> (http://bugs.winehq.org/attachment.cgi?id=30007) Patch: Honor SECURITY_FLAG_IGNORE_CERT_CN_INVALID
I might have spoken too soon. Andras, does this help with the certs you provided?
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #80 from Andras Kovacs andras@csevego.net 2010-08-04 18:40:24 --- (In reply to comment #79)
Created an attachment (id=30007)
--> (http://bugs.winehq.org/attachment.cgi?id=30007) [details]
Patch: Honor SECURITY_FLAG_IGNORE_CERT_CN_INVALID
I might have spoken too soon. Andras, does this help with the certs you provided?
Yes it fixes the problem, the rest is schannel problem as mentioned in comment #69. Thank you.
http://bugs.winehq.org/show_bug.cgi?id=17296
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #30005|0 |1 is obsolete| |
--- Comment #81 from Juan Lang juan_lang@yahoo.com 2010-08-12 13:39:38 --- (From update of attachment 30005) I sent a patch which tests the same thing without having to include a separate chain: Patch for the http://www.winehq.org/pipermail/wine-patches/2010-August/091937.html
http://bugs.winehq.org/show_bug.cgi?id=17296
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #30007|0 |1 is obsolete| |
--- Comment #82 from Juan Lang juan_lang@yahoo.com 2010-08-12 13:40:53 --- (From update of attachment 30007) I also sent in the patch to fix the localhost cert problem: http://www.winehq.org/pipermail/wine-patches/2010-August/091938.html
http://bugs.winehq.org/show_bug.cgi?id=17296
Jisakiel jisakiel@yahoo.es changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jisakiel@yahoo.es
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #83 from Juan Lang juan_lang@yahoo.com 2010-10-21 18:28:56 CDT --- At a quick glance, it looks like buffer handling is incorrect. From the logs:
trace:secur32:InitializeSecurityContextW 0x481decc (nil) L"vulcan" 524572 0 16 (nil) 0 0xa3d4c0 0xa3d458 0xa3becc 0x481dec4 trace:secur32:schan_InitializeSecurityContextW 0x1a85a0 (nil) L"vulcan" 524572 0 16 (nil) 0 0x481de08 0xa3d458 0xa3becc 0x481dec4
Here we have the first call to InitializeSecurityContext. The flags are the fourth parameter, 524572, which is 0x0008011c. The interesting one is ISC_REQ_ALLOCATE_MEMORY. The input buffer is so far empty (nil), which we expect.
trace:secur32:dump_buffer_desc Buffer desc 0xa3d458: trace:secur32:dump_buffer_desc buffer 0: cbBuffer 0, BufferType 0x2 pvBuffer (nil)
Here's the output SecBufferDesc getting traced. It's empty so far, and the call flow continues:
trace:secur32:schan_InitializeSecurityContextW Continue... (snip) trace:secur32:schan_InitializeSecurityContextW 0x1a85a0 0x1a8668 L"vulcan" 524572 0 16 0xa3d664 0 0x481dd4c 0xa3d678 0xa3becc 0x481de08
Here's the second call to InitializeSecurityContext. Note the change in the SecBufferDescs:
trace:secur32:dump_buffer_desc Buffer desc 0xa3d664: trace:secur32:dump_buffer_desc buffer 0: cbBuffer 47, BufferType 0x2 pvBuffer 0xa3d4d4 trace:secur32:dump_buffer_desc Buffer desc 0xa3d678: trace:secur32:dump_buffer_desc buffer 0: cbBuffer 0, BufferType 0x2 pvBuffer (nil)
Now the input buffer which contains 47 bytes, and the new output buffer is still empty. A little bit later we have:
trace:secur32:schan_pull Pull 5 bytes trace:secur32:schan_get_buffer Using buffer 0: cbBuffer 47, BufferType 0x2, pvBuffer 0xa3d4d4 trace:secur32:schan_get_buffer No next buffer trace:secur32:schan_gnutls_log <2> ASSERT: gnutls_buffers.c:360
Here's where the problem appears to occur. schan_get_buffer is searching the input buffer for a buffer with the type SECBUFFER_TOKEN, but there are none remaining. It seems as though either schannel should be appending new data to the input buffer, or making use of the output buffer.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #84 from Juan Lang juan_lang@yahoo.com 2010-10-21 18:36:30 CDT --- Created an attachment (id=31434) --> (http://bugs.winehq.org/attachment.cgi?id=31434) Patch: Allow buffer resizing if ISC_REQ_ALLOCATE_MEMORY is set in the context
Could someone try this? It's purely speculative, I have no idea whether it'll help or not, but if someone wants to try it, I might just get lucky ;)
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #85 from Andras Kovacs andras@csevego.net 2010-10-21 20:06:14 CDT --- It doesn't help. Same error as before.
(In reply to comment #84)
Created an attachment (id=31434)
--> (http://bugs.winehq.org/attachment.cgi?id=31434) [details]
Patch: Allow buffer resizing if ISC_REQ_ALLOCATE_MEMORY is set in the context
Could someone try this? It's purely speculative, I have no idea whether it'll help or not, but if someone wants to try it, I might just get lucky ;)
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.
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #87 from Juan Lang juan_lang@yahoo.com 2011-06-03 14:17:14 CDT --- Thanks for that log. This part of the log looks relevant: trace:secur32:schan_CheckCreds dwFlags = 00000018
In particular, the SCH_CRED_MANUAL_CRED_VALIDATION flag is set. This is supposed to prevent schannel from validating the certificate chain, and should probably imply that gnutls should be instructed not to validate it, either.
http://bugs.winehq.org/show_bug.cgi?id=17296
John Smith jsmith_uk@ymail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jsmith_uk@ymail.com
--- Comment #88 from John Smith jsmith_uk@ymail.com 2011-06-12 10:03:11 CDT --- (In reply to comment #87)
Thanks for that log. This part of the log looks relevant: trace:secur32:schan_CheckCreds dwFlags = 00000018
In particular, the SCH_CRED_MANUAL_CRED_VALIDATION flag is set. This is supposed to prevent schannel from validating the certificate chain, and should probably imply that gnutls should be instructed not to validate it, either.
Hi Juan,
I am not quite convinced. I am using 'trusted' certificate by appending it to /etc/pki/tls/certs/ca-bundle.crt these days.
I've recompiled secur32.c by making changes to schannel_gnutls.c in order to specify UNSAFE_RENEGOTIATION: --- wine-1.3.21-b/dlls/secur32/schannel_gnutls.c 2011-06-12 15:50:20.339830008 +0100 +++ wine-1.3.21/dlls/secur32/schannel_gnutls.c 2011-05-27 19:27:04.000000000 +0100 @@ -64 +64 @@ -MAKE_FUNCPTR(gnutls_priority_set_direct); +MAKE_FUNCPTR(gnutls_set_default_priority); @@ -111 +110,0 @@ - const char *err1; @@ -120 +119,3 @@ - err = pgnutls_priority_set_direct(*s, "NONE:%UNSAFE_RENEGOTIATION:+VERS-TLS1.0:+AES-256-CBC:+RSA:+SHA1:+COMP-NULL", &err1); + /* FIXME: We should be using the information from the credentials here. */ + FIXME("Using hardcoded "NORMAL" priority\n"); + err = pgnutls_set_default_priority(*s); @@ -424 +425 @@ - LOAD_FUNCPTR(gnutls_priority_set_direct) + LOAD_FUNCPTR(gnutls_set_default_priority)
I continue to get errors on SAFE_RENEGOTIATION, despite explicit call for UNSAFE_RENEGOTIATION: trace:secur32:schan_gnutls_log <3> HSK[0x7ea11140]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 trace:secur32:schan_gnutls_log <2> EXT[0x7ea11140]: Sending extension SAFE_RENEGOTIATION
I am not a programmer in any sense. How could I force secur32/schan_gnutls to use UNSAFE_RENEGOTIATION?
Best regards, John
http://bugs.winehq.org/show_bug.cgi?id=17296
Kai Kasurinen kai.kasurinen@uninea.fi changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kai.kasurinen@uninea.fi
http://bugs.winehq.org/show_bug.cgi?id=17296
Jens Pranaitis jens@jenux.homelinux.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jens@jenux.homelinux.org
http://bugs.winehq.org/show_bug.cgi?id=17296
Ma Xiaojun damage3025@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |damage3025@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=17296
--- Comment #89 from Andras Kovacs andras@csevego.net 2012-06-26 16:43:02 CDT --- It should be closed, fixed by 394519db67ad0b56dea604185b8ea8de4dc53519. With native gdiplus vsphere can log in succcessfully. Remote console is not working, but it is another bug.
http://bugs.winehq.org/show_bug.cgi?id=17296
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |394519db67ad0b56dea604185b8 | |ea8de4dc53519 Status|NEW |RESOLVED CC| |wylda@volny.cz Resolution| |FIXED
--- Comment #90 from Wylda wylda@volny.cz 2012-06-27 01:10:40 CDT ---
Reported fixed by http://source.winehq.org/git/wine.git/commit/394519db67ad0b56dea604185b8ea8d...
http://bugs.winehq.org/show_bug.cgi?id=17296
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #91 from Alexandre Julliard julliard@winehq.org 2012-07-03 14:14:24 CDT --- Closing bugs fixed in 1.5.8.
-
wine-bugs＠winehq.org