On ARM Win 11 pro version, when we trying to upload the INF File, we are not able to install the user mode driver as we are facing the issue "Error 0xe0000242: The publisher of an Authenticode(tm) signed catalog has not yet been established as trusted.".
would appreciate if you could help us in resolving this issue.
Can you provide more details? How is this driver signed? What is the scenario you're trying to do here?
We have an old Unidrv printer driver that we migrated forward to VS2022 in order to try working as a native ARM64 driver to use on the Surface Pro Windows 11 Operating system. We have the migrated driver installing and working as expected on Windows x64 platforms and installing and working under Test Signing mode on the Windows ARM64 platform. We are using a Sectigo EV Code signing certificate that we have been using for several years on Windows x64 without any problems.
The issue we are facing is that in Regular Mode on Windows ARM64 it will not let us install the driver and exits with the "Printer driver was not installed" Error. The "publisher of an Authenticode signed catalog has not yet been established as trusted" message.
On Windows x64 we get the 'Publisher not trusted. Do you still want to install?' dialog displayed and allows the user to say "Yes" to complete the driver install successfully. Are we missing some setting that is needed on the ARM 64 for signing, might there be a Group Policy that needs to be set or is there something else we missed?.
We are aware of the Protected Print Mode that Windows is moving towards and tried Enabling then Disabling it to see if that might kick something loose, but it only prevented selecting a driver with Have a Disk.
We are also aware of the suggestion of getting a WHQL signed certificate, however Windows End of Servicing plan for legacy third party printer drivers, that is going to disappear in the next few months and is not a viable option.
We are using the Manual "Add a Printer" process that Windows has gone back to and when the printer driver selection dialog is displayed it shows our driver has a valid Authenticode signature.
As explained earlier when we click Next on Windows x64 the 'Not trusted …Do you still want to install?' dialog is displayed for the User. However, on Windows ARM64, instead of the 'Do you still want to Install" dialog, we immediately get the following " Printer driver was not installed message:"
We have got an Error message as "Printer Driver was not Installed" and " Error 0xe0000242: The publisher of an Authenticode(tm) signed catalog has not yet been established as trusted"
Below is the Windows x64 SetupAPI.dev.log sections showing the 'signed in Authenticode', then 'untrusted publisher' that leads to the 'Do you still want to install…?', followed by the successful install>
{FILE_QUEUE_COMMIT - exit(0x00000000)} 02:22:50.867
** sto: {DRIVERSTORE IMPORT VALIDATE} 02:22:50.867**
** sig: Driver package catalog is valid.**
** sig: {_VERIFY_FILE_SIGNATURE} 02:22:50.867**
** sig: Key = xxx.inf**
** sig: FilePath = C:\WINDOWS\System32\DriverStore\Temp{a075b6b7-b224-6a4d-96e2-72f2aae21fb7}\xxx.inf**
** sig: Catalog = C:\WINDOWS\System32\DriverStore\Temp{a075b6b7-b224-6a4d-96e2-72f2aae21fb7}\xxx64.cat**
! sig: Verifying file against specific (valid) catalog failed.
! sig: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
** sig: {_VERIFY_FILE_SIGNATURE exit(0x800b0109)} 02:22:50.899**
** sig: {_VERIFY_FILE_SIGNATURE} 02:22:50.899**
** sig: Key = xxx.inf**
** sig: FilePath = C:\WINDOWS\System32\DriverStore\Temp{a075b6b7-b224-6a4d-96e2-72f2aae21fb7}\xxx.inf**
** sig: Catalog = C:\WINDOWS\System32\DriverStore\Temp{a075b6b7-b224-6a4d-96e2-72f2aae21fb7}\xxx64.cat**
** sig: Success: File is signed in Authenticode(tm) catalog.**
** sig: Error 0xe0000242: The publisher of an Authenticode(tm) signed catalog has not yet been established as trusted.**
** sig: {_VERIFY_FILE_SIGNATURE exit(0xe0000242)} 02:22:50.930**
! sig: Driver package signer is unknown, but user trusts signer.
** sig: Driver package certificate was successfully installed.**
Below is the Log of the same Windows ARM64 SetupAPI.dev.log sections showing the 'signed in Authenticode', then 'untrusted publisher' that results in the "Driver package signer is unknown, and Code Integrity is enforced" and failure to install.
flq: {FILE_QUEUE_COMMIT - exit(0x00000000)} 22:54:51.910
sto: {DRIVERSTORE IMPORT VALIDATE} 22:54:51.910
sig: Driver package catalog is valid.
sig: {_VERIFY_FILE_SIGNATURE} 22:54:51.923
sig: Key = xxxx.inf
sig: FilePath = C:\Windows\System32\DriverStore\Temp{7e98b93f-2b8c-1844-9ab3-1a3b58ca013b}\xxx.inf
sig: Catalog = C:\Windows\System32\DriverStore\Temp{7e98b93f-2b8c-1844-9ab3-1a3b58ca013b}\xxxARM64.cat
! sig: Verifying file against specific (valid) catalog failed.
! sig: Error 0x800b0109: A certificate chain processed but terminated in a root certificate which is not trusted by the trust provider.
sig: {_VERIFY_FILE_SIGNATURE exit(0x800b0109)} 22:54:51.965
sig: {_VERIFY_FILE_SIGNATURE} 22:54:51.965
sig: Key = xxx.inf
sig: FilePath = C:\Windows\System32\DriverStore\Temp{7e98b93f-2b8c-1844-9ab3-1a3b58ca013b}\xxx.inf
sig: Catalog = C:\Windows\System32\DriverStore\Temp{7e98b93f-2b8c-1844-9ab3-1a3b58ca013b}\xxxARM64.cat
sig: Success: File is signed in Authenticode(tm) catalog.
sig: Error 0xe0000242: The publisher of an Authenticode(tm) signed catalog has not yet been established as trusted.
sig: {_VERIFY_FILE_SIGNATURE exit(0xe0000242)} 22:54:52.006
!!! sig: Driver package signer is unknown, and Code Integrity is enforced.
!!! sig: Driver package failed signature validation. Error = 0xE0000242
sto: {DRIVERSTORE IMPORT VALIDATE: exit(0xe0000242)} 22:54:52.006
!!! sig: Driver package failed signature verification. Error = 0xE0000242
!!! sto: Failed to import driver package into Driver Store. Error = 0xE0000242
sto: {Stage Driver Package: exit(0xe0000242)} 22:54:52.010
<<< Section end 2025/02/23 22:54:52.014
<<< [Exit status: FAILURE(0xe0000242)]
We tried looking at the Code Integrity event log, but do not see anything related to the printer driver installation.
If it is of any help here is the specific target platform we are using in development:
Device Name: DESKTOP - 8571g7;
PROCESSOR : Snapdragon(R) X 10-core X1P64100 @ 340 GHx 342 GHz
Installed RAM : 16.0 GB
System Type: 64 Bit Operating system ARM Based Processor
Edition: Windows 11 Pro with Version as 24H2.
We appreciate your patience wading through all the details. Does anyone have any guidance or suggestions about what we might look at next?
Thanks.
Unless you are in "test" mode, or have the kernel debugger attached, all drivers must be signed by Microsoft. Self-signing is no longer possible.
You'll need a Windows Hardware Dashboard account so you can submit for attestation signing.
User mode is different. I just tested this out on win11 x64, and an EV cert signing works fine, although you have to ack it. Like release signing in the better old days, you can likely just install the cert in trusted certs and avoid the popup. I haven't tested self sign certs without being in test mode, but I suspect they will also work. The MSFT docs are ambiguous. They also do not say anything at all about ARM64.
ARM64 is more strict and does not allow you to use your own cert unless you're in test mode
So... Zadig is broken for ARM? Oh no.
What is the reason for that?
This is the mechanism bind devices to existing drivers, and is widely used, for example by libusb and others WinUsb users. It is recommended by Microsoft:
as well as by OSR:
and poses absolutely no thread.
Requiring Microsoft signature on the INF files which are merely used to bind the device to Microsoft driver will create lots of problem for anyone who uses INF files this way.
At the same time, it doesn't add any security benefits.
May be Microsoft may re-consider this decision and make an exception for such INF files?
What is the reason for that?
Because they WANT to implement that policy universally, but can't because of the existing installed base. There is no "installed base" for ARM64, so they could start afresh.
Requiring Microsoft signature on the INF files which are merely used to bind the device to Microsoft driver will create lots of problem for anyone who uses INF files this way.
Sure, just like it did when they started requiring it for regular INF files in Windows 10.
At the same time, it doesn't add any security benefits.
Save your breath. We argued this when Windows 10 introduced the requirement, to no avail.
The benefit here is legal liability. If your driver goes awry and causes damage that results in a lawsuit, Microsoft has a concrete paper trail back to the identification you provided when you created your dashboard account.
Then a company called CrowdStrike, by the nature of their business, cannot wait a week for Microsoft signature. So they create a solution for that. Their driver reads instructions from a file and executes them in the Kernel mode - some sort of a backdoor, which is happily signed by Microsoft. Then the system malfunctions which causes billions of dollars losses across the globe. Arguably, this would never happen if CrowdStrike could sign their drivers by themselves. Unintended consequences ...
Unlike general driving signing which prevents installation of unsigned drivers, the ARM64 policy change doesn't really prevent anything - you still can associate any device with an existing driver. Therefore it has zero chance of protecting anything. It just creates inconveniences.
crowd strike is a poor example. Probably they would have delivered the same bad code one way or anther no matter what the rules.
The legal argument still applies - even if it makes no difference to the reliability of the software produced by large companies, and certainly makes it harder for smaller ones
For one thing, it allows enforcement of policies about what your driver does or doesn't do.
Winusb.sys is a Microsoft's driver and therefore Microsoft already have full control over what it does or doesn't do.
Winusb.sys was designed to allow access to USB devices without drivers and this worked well for 20+ years, with many software and hardware vendors rely upon.
The binding between Winusb.sys and USB devices is done through the .INF files and this is used by many, such as Zadig, libusb etc. Microsoft's new signature requirement for ARM64 breaks this binding mechanism, which I believe is an unintended consequence.
Perhaps Microsoft could use a different mechanism for policy enforcement which does not break anything, or perhaps Microsoft could make exceptions, for example removing the signature requirement for Winusb.sys and select drivers alike?
It doesn't break the binding mechanism, it just requires that the INF go through HDC for a WHQL signature. There are, for example, WHQL-signed versions of libusb (not sure about zadig) that can be used. Besides that, you can manually associate the device with winusb (device manager, DiInstallDevice), or enable test signing for development scenarios.
I am aware this requirement adds a headache to the process, but the security concern here is not only the sys file, but the INF itself.
The problem is that the INF must include VID and PID, so you cannot just a grab a ready-made INF made by a software vendor and use it with your device - you need to re-sign it. Which makes it the same as if I wrote my own driver.
I actually did write a driver, tested it ... But the Microsoft verification system happened to be very buggy - missing buttons, pink error messages etc. The support personal was absolutely useless and recommend really crazy things - like "I remind you that to create an account in hardware program it must be a personal email, it can't be work /school like the email should be (@gmail, Hotmail, etc.)". I could not get through this. Therefore, signing it through Microsoft is not an option, not for a small businesses like mine anyway.
So, I decided to look at WinUSB instead. It is not as good as my own driver, but I can live with it.
WinUSB solves the problem of using the same driver for arbitrary VID and PID. It was specifically designed to work as a driver for any USB device. It still works fine with EV signatures everywhere except ARM64. That's a bummer.
Well. I cannot really tell customers to enable test signing to use my products. DiInstallDevice() is not a great solution neither because it works for device instances, while DiInstallDriver() works for all devices whether plugged in or not.
You can restrict INF files signed by Authenticode signatures to a small subset of sections/statements which you believe are safe. You can then require Microsoft signature for anything else. This will solve the problem and preserve safety.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.