There's No Yubikey Minidriver for Windows ARM64

This blog post is all about my adventures in trying to code sign on Windows 11 running via Parallels on an M1 MacBook Pro, with the private keys stored on a Yubikey 5. It explains why it doesn't currently work, and a kludge workaround to make it work if this is your build environment and you absolutely need to make it work.

Prior to last-week's adventures, I did our EV Code Signing on Windows via Parallels on my M1 MacBook using my Yubikey with no trouble. So I was surprised when I renewed our EV certificate, with the private keys stored on a new Yubikey, and the certificate no longer populated into Certificate Manager when I connected the Yubikey. This is the only thing I use a Yubikey for, so I wasn't hip to the news that there was an upgrade, and my new keys and certificates came on a Yubikey 5 (instead of the Yubikey 4 the old keys are on.) Little did I know that the new Yubikey 5 models require a device driver (the Yubikey "minidriver") to work properly for slot 9a (PIV Authentication) on Windows, versus our Yubikey 4 current that does not need the minidriver for slot 9a. The Yubikey minidriver is not currently offered for Windows ARM64, only Windows x86 and x64. And x64 emulation on Windows 11 does not work for device drivers.

If you try to sign with the Yubikey 5 connected using signtool, you'll get the error:

SignTool Error: No certificates were found that met all the given criteria.

And if you look at the smart card information using certutil -scinfo you'll get an error like:

Microsoft Base Smart Card Crypto Provider: Missing stored keyset
Microsoft Smart Card Key Storage Provider: Missing stored keyset
CertUtil: - SCInfo command FAILED: 0x80090016 (-2146893802 NTE BAD KEYSET)
CertUtil: Keyset does not exist

(If you see these errors and you're on Windows x64, you may just need to install the minidriver and make sure it's actually being used for the Yubikey in Device Manager.)

Big shout-out to Dhoi over at SSL.com's support for helping me figure out what the problem is and putting up with my wacky ARM64 Windows 11 via Parallels situation. If you're like me and don't have nice things to say about most certificate providers and their customer service, I highly recommend giving SSL.com a try - they've been awesome for all of our EV certificates in the past few years.

I contacted Yubico about an ARM64 minidriver, and from their reply it sounds like it's an open issue for them with no estimate on when the driver will be available.

I happen to still have a Yubikey 4 holding my previous EV Code Signing key, so I could ask SSL.com to reissue the certificate using the old Yubikey 4 once my previous certificate expire. Or, I could decide to switch my primary build environment over to an x64 Windows PC and use the existing keys/certs as is. I'm not excited about either of these options. Since the Yubikey 4 is no longer for sale, if I accidentally break mine, my only option is my back-up build environment and no longer having the convenience of everything on one laptop. (I love my MacBook Pro M1 and I want to use it for everything!)

I'm nothing if not stubborn, and I did notice that my Yubikey 5 works just fine on the host macOS... and Parallels does have some capacity for running apps from the host OS on the client OS... so I decided to experiment to see if I could run the code signing on macOS from inside my Windows 11 client OS on Parallels. And importantly, in the process of making one of our installers using Advanced Installer, we code sign several times, so it has to work in a way that I can point Advanced Installer to this "signing tool" executable that runs without any intervention.

So without further ado, here's the sketch of my working franken-signing setup, which allows me to do the actual code signing on macOS, from inside my client Windows 11 ARM64 via Parallels:

• Homebrew install of osslsigncode on macOS to do the Windows Authenticode code signing.

• Homebrew installs to support osslsigncode on macOS for this use: openssl1.1, libp11 for the PKCS11 engine, and opensc for the PKCS11 module.

• Open the chained certificate from SSL.com to add the certificates to the macOS Keychain.

• Parallels only exposes ".app" applications in the host macOS "Applications" folder to the client Windows environment, so I made an Automator "Application" style document, whose content is a zsh script that runs osslsigncode. This script deals with fact that osslsigncode needs a separate output file from the input file and helps with blocking until the sign finishes.

• One hiccup: The Automator .app application spawns a child process and exits before the actual sign work finishes. The Parallels hook to this app has no way to force it to block until the process finishes, so I wrote a small C++ Windows program to launch the Automator app and force this program to wait until the signing in the zsh script finishes before it exits.

• Now in Advanced Installer I use the C++ program as my code sign tool. Fun :)

I will happily provide the gory details to anyone who wants it, but I'm not yet sure anyone else would want this. So, I'm not adding the scripts and code to this post yet. Please send us an email if you want to know and I'll update the post and/or reply via email. I'm happy to help someone else in this bind.

Here's the command I use to do the Authenticode EV code sign on macOS using osslsigncode - I definitely can imagine that is a more popular need than the Parallels crossover part of things. Your installs locations of osslsigncode, openssl1.1, libp11, opensc will vary. Use brew --prefix if needed to see where your Cellar is.

/opt/homebrew/bin/osslsigncode sign -verbose -pkcs11engine /opt/homebrew/Cellar/libp11/0.4.12/lib/engines-3/pkcs11.dylib -pkcs11module  /opt/homebrew/Cellar/opensc/0.23.0/lib/opensc-pkcs11.so -n "Display Name" -key "pkcs11:id=%01;type=private?pin-value=YOUR_PIN_HERE" -certs ~/yourcerts.chained.crt -h sha256  -ts "http://your-providers-timestamp-server.com" -in "infile.exe" -out "outfile-signed.exe"