http://bugs.winehq.org/show_bug.cgi?id=25478
Summary: MS Office Pro 2010 Trial: activation over the internet fails Product: Wine Version: 1.3.9 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: dimesio@earthlink.net Depends on: 25476
Created an attachment (id=32436) --> (http://bugs.winehq.org/attachment.cgi?id=32436) Office Pro 2010 Trial activation failure
To reproduce, download the Trial and install it without Outlook (to work around bug 25476), then start Excel. Excel will open, and a dialog saying Office needs to be activated will appear. Click "Next" and you are presented with three choices for activation: over the internet, by phone (though this one is grayed out), or convert to the full version. Select "over the internet" and click Next. Activation will start, but soon terminate with a popup message saying "An unspecified error has occurred. Your request cannot be processed at this time. Please try again later (0x8004FC13)."
The same thing happens with Word and Powerpoint, but both those apps need overrides to start up, whereas Excel doesn't.
http://bugs.winehq.org/show_bug.cgi?id=25478
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hans@meelstraat.net
--- Comment #1 from Hans Leidekker hans@meelstraat.net 2010-12-11 02:53:52 CST ---
err:winhttp:netconn_secure_connect couldn't verify server certificate (12038)
Please attach a +winhttp,+crypt trace.
http://bugs.winehq.org/show_bug.cgi?id=25478
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |juan_lang@yahoo.com
--- Comment #2 from Juan Lang juan_lang@yahoo.com 2010-12-11 05:07:58 CST --- Actually, could you make that a +winhttp,+crypt,+chain trace?
http://bugs.winehq.org/show_bug.cgi?id=25478
--- Comment #3 from Rosanne DiMesio dimesio@earthlink.net 2010-12-11 07:13:46 CST --- Created an attachment (id=32447) --> (http://bugs.winehq.org/attachment.cgi?id=32447) +winhttp,+crypt,+chain trying to activate
http://bugs.winehq.org/show_bug.cgi?id=25478
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |crypt32
--- Comment #4 from Juan Lang juan_lang@yahoo.com 2010-12-11 10:08:30 CST --- Here we are with the relevant chain bits:
trace:chain:dump_ssl_extra_chain_policy_para pwszServerName = L"activation.sls.microsoft.com" trace:chain:match_dns_to_subject_dn L"activation.sls.microsoft.com" trace:chain:match_common_name CN = L"*.validation.sls.microsoft.com\0000" warn:chain:match_domain_component domain component L"sls" too short for L"validation" trace:chain:match_common_name returning 0
That is, it's trying to match activation.sls.microsoft.com to *.validation.sls.microsoft.com. This isn't specifically addressed in RFC 2818, which covers HTTP over TLS. From section 3.1:
"Names may contain the wildcard character which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com."
The way I read that, that means *. can't match the lack of a label, and indeed other protocols specifically disallow this. So, in my opinion, Microsoft is doing the wrong thing here. Tests needed, of course.
http://bugs.winehq.org/show_bug.cgi?id=25478
--- Comment #5 from Juan Lang juan_lang@yahoo.com 2010-12-13 14:19:26 CST --- Hm, this case is already covered by existing crypt32 tests. I'm not sure what's going on here. Perhaps native winhttp ignores name mismatches?
http://bugs.winehq.org/show_bug.cgi?id=25478
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|crypt32 |-unknown
http://bugs.winehq.org/show_bug.cgi?id=25478
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |crypt32
--- Comment #6 from Juan Lang juan_lang@yahoo.com 2010-12-14 12:55:47 CST --- I took another look. It turns out the certificate has all of the following common names: CN = sls.microsoft.com CN = activation.sls.microsoft.com CN = *.activation.sls.microsoft.com CN = validation.sls.microsoft.com CN = *.validation.sls.microsoft.com
One of these matches, so I surmise Microsoft accepts certificates if at least one CN matches. Interestingly, firefox rejects https://validation.sls.microsoft.com, as that doesn't match the first CN.
I'll assume it's a crypt32 bug again.
http://bugs.winehq.org/show_bug.cgi?id=25478
--- Comment #7 from Juan Lang juan_lang@yahoo.com 2010-12-14 13:11:28 CST --- Created an attachment (id=32494) --> (http://bugs.winehq.org/attachment.cgi?id=32494) Patch: Accept any matching CN when checking a certificate's name
Does this patch help?
http://bugs.winehq.org/show_bug.cgi?id=25478
--- Comment #8 from Rosanne DiMesio dimesio@earthlink.net 2010-12-14 22:30:43 CST --- It took a little longer, but eventually it failed in the same way.
http://bugs.winehq.org/show_bug.cgi?id=25478
--- Comment #9 from Juan Lang juan_lang@yahoo.com 2010-12-15 09:19:43 CST --- Could you post a +winhttp,+crypt,+chain log of it with the patch applied?
http://bugs.winehq.org/show_bug.cgi?id=25478
--- Comment #10 from Rosanne DiMesio dimesio@earthlink.net 2010-12-15 10:43:18 CST --- Created an attachment (id=32500) --> (http://bugs.winehq.org/attachment.cgi?id=32500) +winhttp,+crypt,+chain with patch
Uploading a log with the patch. The bad news: unlike last night, it failed immediately when I ran this. I can't help but wonder if repeatedly trying to activate might be causing the server to reject it.
http://bugs.winehq.org/show_bug.cgi?id=25478
--- Comment #11 from Juan Lang juan_lang@yahoo.com 2010-12-15 10:52:29 CST --- That could be. There's no certificate chain verification going on here, so something else is definitely the cause this time around.
http://bugs.winehq.org/show_bug.cgi?id=25478
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #32494|0 |1 is obsolete| |
--- Comment #12 from Juan Lang juan_lang@yahoo.com 2010-12-16 12:35:31 CST --- (From update of attachment 32494) I've sent in the patch, with tests that show it's correct.
http://bugs.winehq.org/show_bug.cgi?id=25478
--- Comment #13 from Juan Lang juan_lang@yahoo.com 2010-12-16 12:36:27 CST --- Is there any way you can try again with a different copy/license/on a different machine with the patch applied?
http://bugs.winehq.org/show_bug.cgi?id=25478
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #32500|0 |1 is obsolete| |
--- Comment #14 from Rosanne DiMesio dimesio@earthlink.net 2010-12-16 14:35:08 CST --- Created an attachment (id=32518) --> (http://bugs.winehq.org/attachment.cgi?id=32518) new +winhttp,+crypt,+chain with patch
This is from another working (gets past bug 25476) wineprefix that I had not tried to activate before.
As for getting more logs, I'm always willing to try, but in this case my success rate is likely to be spotty. The workaround I thought I had for bug 25476 doesn't consistently work, and getting past that bug seems completely random.
http://bugs.winehq.org/show_bug.cgi?id=25478
--- Comment #15 from Juan Lang juan_lang@yahoo.com 2010-12-16 15:17:14 CST --- (In reply to comment #14)
Created an attachment (id=32518)
--> (http://bugs.winehq.org/attachment.cgi?id=32518) [details]
new +winhttp,+crypt,+chain with patch
There are no winhttp (or crypt32) errors in this log, so once the patch gets committed, something else is causing the error. This looks suspicious:
err:rpc:I_RpcReceive we got fault packet with status 0x80070424
That's HRESULT_FROM_WIN32(ERROR_SERVICE_DOES_NOT_EXIST). I wonder what service that is?
http://bugs.winehq.org/show_bug.cgi?id=25478
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|crypt32 |-unknown
--- Comment #16 from Juan Lang juan_lang@yahoo.com 2010-12-17 17:14:32 CST --- As of commit 667aeb3ede3ddad63b387fad248b66c03690c5a6, this is no longer a crypt32 bug.
http://bugs.winehq.org/show_bug.cgi?id=25478
--- Comment #17 from Hans Leidekker hans@meelstraat.net 2011-01-28 09:12:26 CST --- (In reply to comment #15)
err:rpc:I_RpcReceive we got fault packet with status 0x80070424
That's HRESULT_FROM_WIN32(ERROR_SERVICE_DOES_NOT_EXIST). I wonder what service that is?
It's looking for the 'PlugPlay' service. Activation fails with a different error if I add a stub implementation of this service and start it beforehand.
This happens right after a call to undocumented ioctl 0x560000. (A quick web search didn't bring up much, except that 0x56 == 'V', which might mean 'Volume').
If I stub this ioctl it proceeds to communicate with the server. After a couple of requests the server responds with an internal server error and a dialog pops up saying I have exceeded the number of activation attempts allowed by the license.
I can still activate under Windows, however, so I guess we're not sending the right data.
http://bugs.winehq.org/show_bug.cgi?id=25478
--- Comment #18 from Hans Leidekker hans@meelstraat.net 2011-01-31 02:34:14 CST --- (In reply to comment #17)
I can still activate under Windows, however, so I guess we're not sending the right data.
Nope, I probably once had office 2010 installed on that vm, since it fails on a different vm, in the same way it fails on wine.
http://bugs.winehq.org/show_bug.cgi?id=25478
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ehoover@mines.edu
--- Comment #19 from Erich Hoover ehoover@mines.edu 2011-01-31 11:40:32 CST --- (In reply to comment #17)
... This happens right after a call to undocumented ioctl 0x560000. (A quick web search didn't bring up much, except that 0x56 == 'V', which might mean 'Volume').
I saw your patch and looked up this bug, as I remembered looking into this at some point a long time ago and it having nothing to do with the problem I was investigating. It would seem to me that this should be added to the FILE_DEVICE_* list in winioctl.h and given a IOCTL_*_BASE alias. The reason you would not find that ioctl in a search is that you really need to be looking for the FILE_DEVICE_VOLUME code (0x00000056, decimal 86): http://www.osronline.com/showThread.CFM?link=113647
I obviously have no idea what the actual ioctl would be called, but you can construct it with the following macro (once you define FILE_DEVICE_VOLUME): CTL_CODE(FILE_DEVICE_VOLUME, 0, METHOD_BUFFERED, FILE_ANY_ACCESS)
http://bugs.winehq.org/show_bug.cgi?id=25478
--- Comment #20 from Erich Hoover ehoover@mines.edu 2011-01-31 11:48:36 CST --- (In reply to comment #19)
... I obviously have no idea what the actual ioctl would be called, but you can construct it with the following macro (once you define FILE_DEVICE_VOLUME): CTL_CODE(FILE_DEVICE_VOLUME, 0, METHOD_BUFFERED, FILE_ANY_ACCESS)
Actually, a quick look at winioctl.h shows that the IOCTL_VOLUME_BASE code is already defined (though as 'V' instead of the hex code) and the ioctl is: IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS
http://bugs.winehq.org/show_bug.cgi?id=25478
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #21 from Hans Leidekker hans@meelstraat.net 2011-02-01 13:24:04 CST --- Fixed by d49134686190c31d5054b6778ffe7af6d3b51bf8 and 2133b6c38d7284a36c14ea24fdbe9b53c5bf1bfd.
http://bugs.winehq.org/show_bug.cgi?id=25478
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #22 from Alexandre Julliard julliard@winehq.org 2011-02-04 13:21:22 CST --- Closing bugs fixed in 1.3.13.
http://bugs.winehq.org/show_bug.cgi?id=25478
Bug 25478 depends on bug 25476, which changed state.
Bug 25476 Summary: MS Office Pro 2010 Trial: setup.exe is started when starting installed apps http://bugs.winehq.org/show_bug.cgi?id=25476
What |Old Value |New Value ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
https://bugs.winehq.org/show_bug.cgi?id=25478
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |d49134686190c31d5054b6778ff | |e7af6d3b51bf8 CC| |focht@gmx.net Component|-unknown |mountmgr.sys
-
wine-bugs＠winehq.org