Search Results

Search found 3 results on 1 pages for 'winverifytrust'.

Page 1/1 | 1 

  • WinVerifyTrust API problem

    - by Shayan
    I'm using WinVerifyTrust API in windows XP and I don't want any kind of user interaction. But when I set the WTD_UI_NONE attribute, although it doesn't show any dialog boxes, but it waits for a long time on the files that in fact wanted user interaction (I mean files which without mentioning the NO UI it will ask the user for that file). This is my code: WINTRUST_FILE_INFO FileData; memset(&FileData, 0, sizeof(FileData)); FileData.cbStruct = sizeof(WINTRUST_FILE_INFO); wchar_t fileName[32769]; FileData.pcwszFilePath = fileName; FileData.hFile = NULL; FileData.pgKnownSubject = NULL; /* WVTPolicyGUID specifies the policy to apply on the file WINTRUST_ACTION_GENERIC_VERIFY_V2 policy checks: 1) The certificate used to sign the file chains up to a root certificate located in the trusted root certificate store. This implies that the identity of the publisher has been verified by a certification authority. 2) In cases where user interface is displayed (which this example does not do), WinVerifyTrust will check for whether the end entity certificate is stored in the trusted publisher store, implying that the user trusts content from this publisher. 3) The end entity certificate has sufficient permission to sign code, as indicated by the presence of a code signing EKU or no EKU. */ GUID WVTPolicyGUID = WINTRUST_ACTION_GENERIC_VERIFY_V2; WINTRUST_DATA WinTrustData; // Initialize the WinVerifyTrust input data structure. // Default all fields to 0. memset(&WinTrustData, 0, sizeof(WinTrustData)); WinTrustData.cbStruct = sizeof(WinTrustData); // Use default code signing EKU. WinTrustData.pPolicyCallbackData = NULL; // No data to pass to SIP. WinTrustData.pSIPClientData = NULL; // Disable WVT UI. WinTrustData.dwUIChoice = WTD_UI_NONE; // No revocation checking. WinTrustData.fdwRevocationChecks = WTD_REVOKE_NONE; // Verify an embedded signature on a file. WinTrustData.dwUnionChoice = WTD_CHOICE_FILE; // Default verification. WinTrustData.dwStateAction = 0; // Not applicable for default verification of embedded signature. WinTrustData.hWVTStateData = NULL; // Not used. WinTrustData.pwszURLReference = NULL; // Default. WinTrustData.dwProvFlags = WTD_REVOCATION_CHECK_END_CERT; // This is not applicable if there is no UI because it changes // the UI to accommodate running applications instead of // installing applications. WinTrustData.dwUIContext = 0; // Set pFile. WinTrustData.pFile = &FileData; // WinVerifyTrust verifies signatures as specified by the GUID // and Wintrust_Data. lStatus = WinVerifyTrust( (HWND)INVALID_HANDLE_VALUE, &WVTPolicyGUID, &WinTrustData); printf("%x\n", lStatus);

    Read the article

  • VS 2010 SP1 installation error: Generic Trust Failure

    - by guybarrette
    I tried to install VS SP1 from the ISO (not the Web Installer) on a machine and ended up with a non successful install with the following error: Generic Trust Failure.   The log file said: Possible transient lock. WinVerifyTrust failed with error: 2148204800 [3/9/2011, 10:6:29]Possible transient lock. WinVerifyTrust failed with error: 2148204800 [3/9/2011, 10:6:30]C:\Dev\VSSP1\VS2010SP1\VC10sp1-KB983509-x86.msp - Signature verification for file VC10sp1-KB983509-x86.msp (C:\Dev\VSSP1\VS2010SP1\VC10sp1-KB983509-x86.msp) failed with error 0x800b0100 (No signature was present in the subject.) [3/9/2011, 10:6:30] C:\Dev\VSSP1\VS2010SP1\VC10sp1-KB983509-x86.msp Signature could not be verified for VC10sp1-KB983509-x86.msp [3/9/2011, 10:6:30]No FileHash provided. Cannot perform FileHash verification for VC10sp1-KB983509-x86.msp [3/9/2011, 10:6:30]File VC10sp1-KB983509-x86.msp (C:\Dev\VSSP1\VS2010SP1\VC10sp1-KB983509-x86.msp), failed authentication. (Error = -2146762496). It is recommended that you delete this file and retry setup again. Since I didn’t want to download the 1.5GB ISO a second time, I tried the Web installer and this time it worked like a charm.  Was the problem with a corrupt download or a file missing a signature I can’t say. var addthis_pub="guybarrette";

    Read the article

  • Verify Authenticode signature as being from our company for automatic updater

    - by James Johnston
    I am implementing an automatic update feature and need some advice on how to do this securely using best practices. I would like to use the downloaded file's Authenticode signature to verify that it is safe to run (i.e. originates from our company and hasn't been tampered with). My question is very similar to question #2008519. The bottom-line question: what's the best, most secure way to check Authenticode signatures for an automatic update feature? What fields in the certificate should be checked? Requirements being: (1) check signature is valid, (2) check it's my signature, (3) old clients can still update when my certificate expires and I get a new one. Here's some background information / ideas from my research: I believe this could be broken into two steps: Verify that the signature is valid. I believe this should be easy using WinVerifyTrust as outlined in http://msdn.microsoft.com/en-us/library/aa382384(VS.85).aspx - I don't expect problems here. Verify that the signature corresponds to our company, and not another company. This seems to be a more difficult question to answer: One possibility is to check some of the strings in the signature. Could be obtained via code at MS KB article #323809, but this article doesn't make recommendations on what fields should be checked for this type of application (or any other, for that matter). Question #1072540 also illustrates how to get some certificate info, but again doesn't recommend what fields to actually check. My concern is that the strings might not be the best check: what if another person is able to obtain a certificate with the same name, for example? Or if there's a valid reason for us to change the strings in the future? The person at question #2008519 has a very similar requirement. His need for a "TrustedByUs" function is identical to mine. However, he goes about doing the check by comparing public keys. While this would work in the short-term, it seems like it won't work for an automatic update feature. This is because code signing certificates are only valid for 2 - 3 years max. Therefore, in the future, when we buy a new certificate in 2 years, the old clients wouldn't be able to update any more due to the change in public key.

    Read the article

1