http://bugs.winehq.org/show_bug.cgi?id=16420
Summary: Certificate chaining error trying to use Microsoft signcode tool Product: Wine Version: 1.1.10 Platform: Other OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: Jim.Cooper@sas.com
Using this command:
wine mssign/signcode.exe -i http://www.mycompany.com -t http://timestamp.verisign.com/scripts/timstamp.dll -spc mycredentials.spc -v myprivatekey.pvk unzip.exe
Gets me this error:
Error: Failed to build the certification path as requested Error: Signing Failed. Result = 800b010a, (-2146762486)
This only started happening with recent certificates from VeriSign, and only fails when run under Wine. If I run the same command (minus the 'wine' in front, of course) under Windows, using the same certificate, key, etc., the signing attempt succeeds with no errors.
I am using a plain-vanilla wine install, under the latest Kubuntu Linux.
I can't supply you with the certificate, but would be willing to test whatever you suggest.
http://bugs.winehq.org/show_bug.cgi?id=16420
Jamie Jim.Cooper@sas.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Platform|Other |PC-x86-64
http://bugs.winehq.org/show_bug.cgi?id=16420
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |crypt32
http://bugs.winehq.org/show_bug.cgi?id=16420
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |juan_lang@yahoo.com
--- Comment #1 from Juan Lang juan_lang@yahoo.com 2008-12-09 10:43:16 --- Please attach a +crypt32 log. Do you have a download url for signcode.exe?
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #2 from Jamie Jim.Cooper@sas.com 2008-12-09 10:59:47 --- If you can tell me how to generate the "+crypt32" log, I will be happy to do so.
I found this page for signcode.exe:
http://msdn.microsoft.com/en-us/library/9sh96ycy%28VS.71%29.aspx
I have had my copy "forever"... not sure where I got it from originally, but it has been at least 8 years - before ".NET" became a reality.
The version that comes in the download from that page appears to be the same, and does give the same error.
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #3 from Juan Lang juan_lang@yahoo.com 2008-12-09 11:10:58 --- (In reply to comment #2)
If you can tell me how to generate the "+crypt32" log, I will be happy to do so.
WINEDEBUG=+crypt32 wine mssign/signcode.exe -i (etc etc.) >& log.txt
Then attach log.txt here.
I found this page for signcode.exe: http://msdn.microsoft.com/en-us/library/9sh96ycy%28VS.71%29.aspx
The version that comes in the download from that page appears to be the same, and does give the same error.
Odd, I don't see a download link on that page. Could you tell me where to look? It's also available as part of the Windows SDK, so I'll install that if I have to.
http://bugs.winehq.org/show_bug.cgi?id=16420
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |https://www.cryptguard.com/f | |iles/codesigningx86.exe
--- Comment #4 from Juan Lang juan_lang@yahoo.com 2008-12-09 15:41:15 --- The URL above has a copy of the signcode.exe utility and a few others. Now I need to figure out how to generate a pvk file.
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #5 from Jamie Jim.Cooper@sas.com 2008-12-09 15:41:59 --- Created an attachment (id=17779) --> (http://bugs.winehq.org/attachment.cgi?id=17779) Log from running command with WINEDEBUG=+crypt32
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #6 from Juan Lang juan_lang@yahoo.com 2008-12-09 15:43:13 --- (In reply to comment #5)
Created an attachment (id=17779)
--> (http://bugs.winehq.org/attachment.cgi?id=17779) [details]
Log from running command with WINEDEBUG=+crypt32
Darn, I had a typo and didn't catch it till after you generated the log. I want the crypt channel, not the crypt32 channel (which doesn't exist.) Please use this instead: WINEDEBUG=+crypt wine mssign/signcode.exe -i (etc etc.) >& log.txt
and attach log.txt here.
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #7 from Jamie Jim.Cooper@sas.com 2008-12-09 15:43:35 --- Created an attachment (id=17780) --> (http://bugs.winehq.org/attachment.cgi?id=17780) Microsoft's signcode.exe
This is the same file that is distributed as part of the Microsoft SDK. I don't know if it references any DLLs, etc. that are not part of the WINE distribution. If it does, then you will need the full SDK.
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #8 from Jamie Jim.Cooper@sas.com 2008-12-09 15:53:54 --- Created an attachment (id=17781) --> (http://bugs.winehq.org/attachment.cgi?id=17781) Log from running command with WINEDEBUG=+crypt
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #9 from Austin English austinenglish@gmail.com 2008-12-09 16:24:52 --- (In reply to comment #7)
Created an attachment (id=17780)
--> (http://bugs.winehq.org/attachment.cgi?id=17780) [details]
Microsoft's signcode.exe
This is the same file that is distributed as part of the Microsoft SDK. I don't know if it references any DLLs, etc. that are not part of the WINE distribution. If it does, then you will need the full SDK.
Please don't upload attachments that you don't have the right to do so.
Bugzilla admin, please delete this file.
http://bugs.winehq.org/show_bug.cgi?id=16420
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #10 from Juan Lang juan_lang@yahoo.com 2008-12-09 19:22:18 --- (In reply to comment #8)
Created an attachment (id=17781)
--> (http://bugs.winehq.org/attachment.cgi?id=17781) [details]
Log from running command with WINEDEBUG=+crypt
I'm not seeing the same behavior here. It still fails, but differently. You're seeing a problem with decoding the SPC file:
trace:crypt:CryptQueryObject (00000001, 0x110486, 00000112, 00000002, 00000000, (nil), 0x32fb90, (nil), 0x32fb94, (nil), (nil)) trace:crypt:CRYPT_ReadBlobFromFile L"mycredentials.spc" (snip) trace:crypt:CryptQueryObject returning 0
I generated my own self-signed cert using makecert.exe and the following command: wine makecert.exe -sv juan.pvk -n "CN=Juan Lang" -r juan.cer I converted it to an SPC cert using cert2spc: wine Cert2Spc.Exe juan.cer juan.spc I then ran signcode.exe on an executable using the .spc file and .pvk file generated in the first two steps: wine signcode.exe -spc juan.spc -v juan.pvk -i winehq.org test.exe
This failed, but not in CryptQueryObject. The first failure was the following complaint: Error: The software publishing certificate and private key do not match or do not contain valid information. Error: Signing Failed. Result = 80092009, (-2146885623)
This patch fixed that error: http://www.winehq.org/pipermail/wine-patches/2008-December/065751.html
The next error was a crash to the unimplemented wintrust:WVTAsn1SpcSpOpusInfoEncode. I sent in a patch for this as well: http://www.winehq.org/pipermail/wine-patches/2008-December/065754.html
Currently it fails for me because wintrust:CryptSIPCreateIndirectData is a stub: fixme:wintrust:CryptSIPCreateIndirectData (0x32fcc0 0x32fba0 (nil)) stub Error: Signing Failed. Result = 8000ffff, (-2147418113)
Would you mind attaching your .spc file to help me debug why CryptQueryObject is failing for you?
http://bugs.winehq.org/show_bug.cgi?id=16420
Jamie Jim.Cooper@sas.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #17780|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #11 from Jamie Jim.Cooper@sas.com 2008-12-10 07:38:27 --- Unfortunately, I cannot attach the certificate to an 'open' system such as this, as it is my company's official corporate certificate.
It is a brand new (well, less than a year old) certificate purchased from VeriSign.
I can say that this problem did not occur with an older (long expired) certificate, so it must be something different with the way VeriSign generates certificates these days.
If you cannot debug further without my .spc file, we may be able to work something out via private e-mail.
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #12 from Juan Lang juan_lang@yahoo.com 2008-12-10 09:01:19 --- (In reply to comment #11)
Unfortunately, I cannot attach the certificate to an 'open' system such as this, as it is my company's official corporate certificate.
Oh? Note I'm not asking for the .pvk file. What's of concern in the certificate? It's embedded in every signed executable too, you know.
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #13 from Jamie Jim.Cooper@sas.com 2008-12-10 09:11:58 --- I know that, and you know that.
The bean-counters don't know, or care. They would jump on me so hard the marks would never heal.
They are so paranoid that I had to set up a client/server system so that the .spc/.pvk files would be locked onto a single system (out of the thousands we have), and all signing occurs ONLY on that one system.
The only way anything gets signed is by using the client to send something to the server, which signs it and sends back the signed copy.
Every transaction is logged within an inch of it's life, as well.
That system is locked down to the point that I am the only person (out of 22,000+) able to log into that system.
I can get special dispensation to privately send the file(s) to _one_ person, but posting to an open system like bugzilla? I want to keep my job, thanks.
Corporate mentality... ya gotta live with it, if ya want to work for them.
The good news is that they don't really care what runs on the server as long as things get signed. If I can get a working setup with Linux + Wine, I can nuke Windoze... and be a much happier person.
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #14 from Juan Lang juan_lang@yahoo.com 2008-12-10 10:22:55 --- (In reply to comment #13)
The bean-counters don't know, or care. They would jump on me so hard the marks would never heal.
Ouch!
For starters, how about posting a +crypt,+cryptasn log. That might give me some clue why the decoding is failing without having to see the .spc file. If it's insufficient I'll contact you privately for a look at your .spc file.
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #15 from Jamie Jim.Cooper@sas.com 2008-12-10 13:15:06 --- Created an attachment (id=17809) --> (http://bugs.winehq.org/attachment.cgi?id=17809) Log from running command with WINEDEBUG=+crypt,+cryptasn
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #16 from Juan Lang juan_lang@yahoo.com 2008-12-10 16:52:27 --- I had a look at a the SPC file in question. It turns out to be a base64-encoded version of the asn.1-encoded SPC file, saved as a UTF-16 string. I base64-decoded it and tried signcode.exe, but CryptQueryObject still failed to decode it.
There appear to be several bugs here: 1. CryptQueryObject isn't decoding the file properly. 1.a. It doesn't handle base64-encoded files. 1.b. It's not decoding the base64-decoded version, either. 2. wintrust:CryptSIPCreateIndirectData is unimplemented.
It's a little surprising that CryptQueryObject is expected to decode a base64-encoded file in this case, because of how it's called: trace:crypt:CryptQueryObject (00000001, 0x110486, 00000112, 00000002, 00000000, (nil), 0x32fb90, (nil), 0x32fb94, (nil), (nil))
The fourth argument, dwExpectedFormatTypeFlags, is 2, CERT_QUERY_FORMAT_FLAG_BINARY, rather than CERT_QUERY_FORMAT_FLAG_BASE64_ENCODED. More tests for CryptQueryObject are certainly needed. CryptStringToBinaryW probably needs to implemented as well.
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #17 from Juan Lang juan_lang@yahoo.com 2008-12-11 19:08:56 --- Dumb question: does this SPC cert and this version of signcode.exe work for you under Windows? If so, which version?
I wrote some tests for CryptQueryObject. As I would have expected, CryptQueryObject fails when given a base64-encoded input and the fourth parameter (dwExpectedFormatTypeFlags) doesn't specify CERT_QUERY_FORMAT_FLAG_BASE64_ENCODED. As can be seen in the +crypt log, signcode.exe calls CryptQueryObject with dwExpectedFormatTypFlags set to 2 (CERT_QUERY_FORMAT_FLAG_BINARY). Thus, I'd expect signcode.exe to fail under Windows too.
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #18 from Jamie Jim.Cooper@sas.com 2008-12-12 10:22:03 --- signcode.exe works fine under Windoze XP SP1, Windoze Server 2003, Windoze Server 2008, Windoze Vista, ... with the certificate I have.
One can only assume that Windoze doesn't really pay attention to the flags you are looking at, or they are decoded differently, or... whatever.
The example command line I gave (minus the "wine " prefix) is working fine in a production system on Windoze, that signs many tens of thousands of objects every night... peak for a 24 hour period (so far) is ~40,000 signing transactions. The majority of those are Jar signing transactions, which don't use signcode, but there are still hundreds (to thousands, at peak) uses of signcode every night, with no failures.
The rest of my client/server system is all custom Java code. If I could get rid of signcode altogether, I would be a happy camper. I would be _almost_ as happy if I could run signcode with Wine, and run it all on a Linux server.
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #19 from Juan Lang juan_lang@yahoo.com 2008-12-12 11:22:48 --- (In reply to comment #18)
One can only assume that Windoze doesn't really pay attention to the flags you are looking at, or they are decoded differently, or... whatever.
When I say I wrote some tests, I mean I ran them on Windows. I wrote a test program that calls CryptQueryObject with exactly the same parameters that signcode.exe does, and it fails for me on Windows XP SP3. That's why I'm confused. As far as I can tell, as of today's git Wine's CryptQueryObject works as Windows's does for .spc files. I'll do a little more testing today.
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #20 from Juan Lang juan_lang@yahoo.com 2008-12-12 11:47:09 --- (In reply to comment #19)
When I say I wrote some tests, I mean I ran them on Windows. I wrote a test program that calls CryptQueryObject with exactly the same parameters that signcode.exe does, and it fails for me on Windows XP SP3.
What I didn't realize is that signcode.exe isn't calling CryptQueryObject directly, it's calling CertOpenStore. CertOpenStore is calling CryptQueryObject. Duh.
I'll have a patch for that shortly. It won't fix the bug yet, it'll just fix part 1.a. of the bug (see comment 16).
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #21 from Juan Lang juan_lang@yahoo.com 2008-12-12 15:05:21 --- Part 1.a. of the bug is addressed with this patch: http://www.winehq.org/pipermail/wine-patches/2008-December/065938.html Part 1.b. is addressed with the following patch: http://www.winehq.org/pipermail/wine-patches/2008-December/065945.html
Once these two patches are applied, the next problem is that wintrust:CryptSIPCreateIndirectData is unimplemented. I'll move the component to wintrust once they are applied.
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #22 from Juan Lang juan_lang@yahoo.com 2008-12-19 11:43:31 --- The patches weren't accepted, probably because they require test cases. I'll try to get some written to get these in.
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #23 from Juan Lang juan_lang@yahoo.com 2008-12-19 17:49:18 --- Updated patches for the first two bugs sent: http://www.winehq.org/pipermail/wine-patches/2008-December/066462.html http://www.winehq.org/pipermail/wine-patches/2008-December/066463.html
http://bugs.winehq.org/show_bug.cgi?id=16420
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
http://bugs.winehq.org/show_bug.cgi?id=16420
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|crypt32 |wintrust
--- Comment #24 from Juan Lang juan_lang@yahoo.com 2008-12-20 11:21:04 --- This is now a wintrust bug, as the first two crypt32 problems are fixed as of 1.1.11, and now it's getting stuck because wintrust:CryptSIPCreateIndirectData is unimplemented.
http://bugs.winehq.org/show_bug.cgi?id=16420
Paul Vriens Paul.Vriens.Wine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Vriens.Wine@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=16420
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on| |17084
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #25 from Austin English austinenglish@gmail.com 2009-07-30 11:39:51 --- (In reply to comment #24)
This is now a wintrust bug, as the first two crypt32 problems are fixed as of 1.1.11, and now it's getting stuck because wintrust:CryptSIPCreateIndirectData is unimplemented.
Still present. It's implemented in crypt32. Could the function be forwarded, or the code copied?
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #26 from Juan Lang juan_lang@yahoo.com 2009-07-30 12:20:29 --- (In reply to comment #25)
(In reply to comment #24)
This is now a wintrust bug, as the first two crypt32 problems are fixed as of 1.1.11, and now it's getting stuck because wintrust:CryptSIPCreateIndirectData is unimplemented.
Still present. It's implemented in crypt32. Could the function be forwarded, or the code copied?
No. crypt32's implementation actually calls the wintrust one, or whichever one is registered for the desired SIP.
wintrust:CryptSIPCreateIndirectData needs to create a hash of its input, which is usually a file. This needs some tests to implement. It also probably depends on a decent implementation of ImageGetDigestStream, see bug 17084. See the "depends on" link ;-)
http://bugs.winehq.org/show_bug.cgi?id=16420
Bug 16420 depends on bug 17084, which changed state.
Bug 17084 Summary: .NET 1.0: imagehlp.ImageGetDigestStream needs more flesh (assembly registration fails) http://bugs.winehq.org/show_bug.cgi?id=17084
What |Old Value |New Value ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
http://bugs.winehq.org/show_bug.cgi?id=16420
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |24160
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #27 from Austin English austinenglish@gmail.com 2010-09-07 13:45:43 CDT --- (In reply to comment #26)
wintrust:CryptSIPCreateIndirectData needs to create a hash of its input, which is usually a file. This needs some tests to implement. It also probably depends on a decent implementation of ImageGetDigestStream, see bug 17084. See the "depends on" link ;-)
The 'depends on' bug is fixed :-).
Is this still an issue in current (1.3.2 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #28 from Juan Lang juan_lang@yahoo.com 2010-09-07 14:28:33 CDT --- (In reply to comment #27)
Is this still an issue in current (1.3.2 or newer) wine?
Yes, wintrust:CryptSIPCreateIndirectData is still unimplemented. I took a quick look at it, and it turns out it's not as straightforward as I thought to create the correct hash. There's a Microsoft document that describes how it should be implemented, entitled "Windows Authenticode Portable Executable Signature Format", currently available at: http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac...
I've written a test case for CryptSIPCreateIndirectData, but so far haven't implemented it.
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #29 from Juan Lang juan_lang@yahoo.com 2010-09-23 17:46:40 CDT --- I sent the test patch in so I'm not holding it hostage: http://www.winehq.org/pipermail/wine-patches/2010-September/093645.html
I haven't managed to get this implemented yet.
http://bugs.winehq.org/show_bug.cgi?id=16420
Chris Boyle chris@boyle.name changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |chris@boyle.name
http://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #30 from Austin English austinenglish@gmail.com 2013-11-13 16:50:47 CST --- This is your friendly reminder that there has been no bug activity for 2 years. Is this still an issue in current (1.7.6 or newer) wine? If so, please attach the terminal output in 1.7.6 (see http://wiki.winehq.org/FAQ#get_log).
https://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #31 from Austin English austinenglish@gmail.com --- This is your friendly reminder that there has been no bug activity for 1 year. Is this still an issue in current (1.7.31 or newer) wine? If so, please attach the terminal output in 1.7.31 (see http://wiki.winehq.org/FAQ#get_log).
https://bugs.winehq.org/show_bug.cgi?id=16420
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |ABANDONED
--- Comment #32 from Austin English austinenglish@gmail.com --- (In reply to Austin English from comment #31)
This is your friendly reminder that there has been no bug activity for 1 year. Is this still an issue in current (1.7.31 or newer) wine? If so, please attach the terminal output in 1.7.31 (see http://wiki.winehq.org/FAQ#get_log).
ABANDONED.
https://bugs.winehq.org/show_bug.cgi?id=16420
--- Comment #33 from Jerome Leclanche jerome@leclan.ch --- This is needed for bug 24160 I'm not sure you can close it as abandoned.
https://bugs.winehq.org/show_bug.cgi?id=16420
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #34 from Austin English austinenglish@gmail.com --- Closing.
-
wine-bugs＠winehq.org