Device driver code signing for windows XP 32 bit - code-signing

I have written a device driver for a device but each time I connect the device in windows XP 32 bit, "found new hardware" wizard appears.
I am signing the driver using a Comodo code signing certificate and not using the cross certificate chain to link to microsoft root authority. Nor is the driver wql certified.
So my question is to disable the found new hardware wizard on windows xp:
i) Does my driver needs to be wql certified?
ii) signed with microsoft root certificate using cross certificate from verisign?
iii) or something i missed out in my code which needs to be changed?

did some research and found the answer:
windows XP does not support authenticode driver signing and there are no plans to add it. Only way is to sign using microsoft certificate by using a cross certificate

As far as I know, the only driver signing recognized by Windows XP is a WHQL signature. Cross-signing has nothing to do with it. (Cross-signing allows the Windows Vista kernel driver loader to recognize Authenticode signatures. It has nothing to do with Windows XP driver loading.)
Authenticode signatures, while they would validate with DIFx / DpInst, would fail to validate later when SetupAPI tries to install your device driver out of the driver store.

Related

Signing kernel-mode Windows 10 driver

I've developed a kernel-mode driver for Windows 10. How should I properly sign it? I want my driver to be installable without enabling test-signed drivers installation after sign procedure.

Windows MS signed filter driver doesn't load on Win 7 x64 after updating driver to build with VS2019 / WDK 22000

I recently took on a task to update our filter driver from building with Visual Studio 2015 -> 2019. I also moved to the latest SDK + WDK 22000 (Which is the new Windows 11 one).
Everything seemed to work except that on Win 7 x64 (with secure boot) boxes the driver no longer loads.. It get's:
Load failed with error: 0x80070241
Windows cannot verify the digital signature for this file. A recent hardware or
software change might have installed a file that is signed incorrectly or damaged,
or that might be malicious software from an unknown source.
Our driver was/is attestation signed by Microsoft via the MS Hardware portal and so it's joint signed by both our company and Microsoft with a SHA-2 signature each. Windows 7 doesn't support SHA-2 certs out of the box however, it was previously working provided:
Windows6.1-KB3033929-x64
Was installed. Something seems to have changed though and Windows 7 x64 boxes can't load the new driver even with the latest updates. They load the 2015 built driver just fine even though the certificates on both look identical. The new driver loads just fine on Windows 10 machines.
Is anyone aware of any other changes which might make this combination fail to load?
I had a similar issue a few months ago, when we decided to switch our certificate provider. I'll share my knowledge to you, hope that going to help.
A while ago, Microsoft used cross-certificates to validate trusted certificate authorities (CA), so the only thing you needed to sign a driver is a proper certificate bought from a trusted CA. But recently validating process had changed and starting from Windows 10 20H2 you are forced to sign your driver through Microsoft Partner Center and all the cross-certificates was deprecated. However, you still need to use cross sign process for all your drivers prior to Windows 10, actually cross signed driver will work up to Windows 10 20H1 if to be correct.
Now back to the Visual Studio. To properly sign driver, you had to set up production certificate to field Properties -> Driver Signing -> General -> Production Certificate, that causes Visual Studio to use signtool utility to sign driver after the build done. As I presume, Visual Studio 2019 process do not use cross-certificate and looks something like:
signtool sign /v <trusted_certificate> /tr http://timestamp.digicert.com /td sha256 /fd sha256 /a <sys_driver_filepath>
But Visual Studio 2013 actually must use cross-certificate and the command it uses is:
signtool sign /v /ac <microsoft_cross_certificate> /tr http://timestamp.digicert.com /a <sys_driver_filepath>
So what is cross-certificate is? It's a special trusted Microsoft certificate that tied to certified CA. List of all the cross-certificates available can be found here https://learn.microsoft.com/en-us/windows-hardware/drivers/install/cross-certificates-for-kernel-mode-code-signing#cross-certificate-list. To take the correct one you need to check your company certificate first. Take a look into root of certification path of your cert, open View Properties -> Details and find Issuer, that's your CA. Now you need to find exact match on cross-certificate list and download it. Note the thumbprint doesn't need to match (revealed in related issue). After all use a proper signtool command to sign your file.
P.S. If your certificate issuer not present on the list, that means your CA inappropriate and you need to get/buy another certificate.

Packaging code sign certificate - windows UWP app - not distributed through Microsoft store

Need help on how to package code sign certificate with webapp developed in visual studio.
The application setup/installer will be available for download on public website, so we plan to code sign it so it is smoothly installed on client PC.
(1)
how to package code sign certificate
where to get code sign
certificate at reasonable rate
current focus is windows
platform, in future, we need to prepare installer for other
platforms too (Apple, Linux ... )
You can check comodo code signing certificate

windows phone 8.1 company profile

We are developing the Windows Phone 8.1 app.
The Hockeyapp was chosen for app distribution. To be able to distribute a Windows Phone 8.1 app, it requires to upload the company profile file (.aetx). Which then should be downloaded on Windows Phone and only after that the .xib file signed with the company certificate can be installed.
The problem is that the phone reports the error when trying to install the .aetx file:
Can't add workplace account
We weren't able to set up the workplace account.
Contact your company's support person for help.
The specifics is that the Enterprise Mobile Code Signing Certificate was requested from Symantec from the Mac computer, and the certificates were exported to .p12 format but not .pfx as in case of Windows OS. But the AETGenerator.exe didn't show any error and successfully created the .aet, .aetx and .xml files.
I followed the Company app distribution for Windows Phone, and the steps I have done:
Registered the Company account on Windows Phone Dev Center
On Mac computer applied for Symantec Enterprise Mobile Code Signing
Certificate
On Mac picked up Enterprise Certificate from Symantec
On Mac exported the Enterprise Certificate to .p12 file
On Windows installed the Symantec_Enterprise_Mobile_Root_for_Microsoft.cer
On Windows installed the Symantec_Enterprise_Mobile_CA_for_Microsoft_Cert.cer
On Windows development computer generated the .aetx file using the AETGenerator.exe of the Windows Phone 8.1 SDK tools
Now either installing the .aetx file from email or through Hockeyapp the phone shows the same error and doesn't install the certificate.
I tried installing the .p12 from Mac to Windows, then exporting the .pfx file on Windows with included private certificate, and then generating the .aetx file from this .pfx, the result is the same; phone shows the same error.
If I install all certificates on Windows (downloading Symantec certificates and installing private and public Enterprise certificates from .p12 file), and then trying to pick up the Enterprise Certificate from Symantec on Windows, the browser shows:
Your certificate cannot be installed. Either it has already been installed, or you have removed your private key.
It seems this error is shown when trying to install the public key of certificate not on the same computer from where it was requested.
Can applying for Symantec Enterprise Mobile Code Signing Certificate from Mac and then exporting the certificate be the reason of this problem?
If the Enterprise Mobile Code Signing Certificate was once acquired for the company, is there a way to apply for another certificate for same company from another computer? When enrolling for a certificate, the private key is being created in the browser on the back end, and I am thinking if it is possible to pass the same procedure from Windows but not paying for extra certificate.
This should help.
When we try to generate AET token, it fails with following error? What is cause for this failure?
Unknown Error while generating AET
StartIndex cannot be larger than length of string
Parameter name: StartIndex
http://blogs.msdn.com/b/wsdevsol/archive/2014/04/21/frequently-asked-questions-about-windows-phone-company-hub-apps.aspx

Windows Driver NONPNP Signing

I have tried to run the NONPNP windows driver code. It installs and when I run the nonpnpapp.exe I get a driver signing error.
"windows requires a digitally signed driver"
I am running this on debug mode and release I am test signing it.
Why am I still getting this error?
I do know that x64 machines needs this, I am on windows7 x64.
So we need to do something else.
Visual studio output says that the sys file is successfully signed.
I trace the code. It copies the sys to system32/drivers after it is signed.
Windows device installation uses digital signatures to verify the integrity of driver packages and to verify the identity of the vendor (software publisher) who provides the driver packages. In addition, the kernel-mode code signing policy for 64-bit versions of Windows Vista and later versions of Windows specifies that a kernel-mode driver must be signed for the driver to load.+
Note Windows 10 for desktop editions (Home, Pro, Enterprise, and Education) and Windows Server 2016 kernel-mode drivers must be signed by the Windows Hardware Dev Center Dashboard, which requires an EV certificate. For details, see Driver Signing Changes in Windows 10. https://learn.microsoft.com/en-us/windows-hardware/drivers/install/driver-signing
Two options there;
1) allow test signing
2) disable driver signature enforcement
If you are using a dedicated test machine, I recommend the second option since I think it's more error proof.

Resources