Thisblog 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.
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 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.
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.
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.
Our primary business is making our Decipher Tools software and solving iPhone problems, but occasionally while writing a tutorial, we find a solution that involves recommending buying an item, like a cable or case. We take external product recommendations very seriously, and we only link to products that we have actually tested ourselves.
iPhone, iPad, iPod, iTunes and Mac are trademarks of Apple Inc., registered in the U.S. and other countries. Windows is a trademark of Microsoft Corporation. Our software is not developed by or affilated with Apple Inc. or Microsoft Corporation.
I installed the remote desktop hosts role on the remote machine and now when I RDP to the machine I see Smart Card Readers appear with Microsoft Usbccid Smartcard Reader (WUDF) but no Smart Card. I can go to add Legacy Hardware and install Smart Cards and choose YubiKey Smart Card Minidriver but the card is not "properly" detected by the yubikey manager. What I mean by properly is that I can remove and insert the yubikey device into the host machine and the remote machine will detect it, Microsoft Usbccid Smartcard Reader (WUDF) will appear and disappear accordingly.
Finally, if I examine the YubiKey Smart Card Minidriver in Device Manager under device status - it says the device is working properly but the location is value is "unknown". It should say scfilter, I have confirmed the scfilter driver is started on the remote machine when the yubikey is inserted so there is some detection.
Sorry if this was long but it may help someone, again this cannot be a unique use case? If I could find a offical (MS) article that says the smart card enrolment machine has to be physical I will accept it.
Did you use the instructions in the Bonus Step section of this article? When you export your key from the YubiKey Manager it should be in the correct format for use with other YubiKeys. Also, did you make sure that you entered the password set in step 6 correctly?
Not that this should make a difference, but which type of YubiKey are you using? I have tested this on 5Ci and 5NFC. As best I can tell anything in the 4 or 5 series should be ok. I see they have a few other products though.
Sounds like either the certificate that was generated is not compatible with BitLocker or the certificate was not properly imported to the YubiKey. If the certificate was generated incorrectly, regenerating the certificate may work (steps 2, 5 to 7). The first time I tried getting things working I had to repeat the steps and that worked for whatever reason. I guess something must have been slightly off on my first attempt. If you used a different OID in steps 2 and 4 I would recommend using the one in the article (also recommended by Microsoft). I have also posted a screenshot of what it looks like in my YubiKey Manager in the Certificates screen. You must use the Slot 9e certificate from everything I have found.
The private key is simply to verify the authenticity of your smart card (or in this case YubiKey). The actual authentication is part of the smart card system itself, so you still need to have a smart card with the key loaded. That said, if you were to export the private key and load it on to another YubiKey, that key could then be used to unlock your BitLocker drive. The important thing here is that when the key pair is imported into Windows, the private key is not marked as exportable. The method to import the key pair used in this guide does not allow exporting afterwards.
I talked with some people at yubico a while back on this topic and while they do have software to help with domain provisioning, it is only available with the YubiEnterprise subscription service. That service has a minimum requirement of 750 users, so for small and medium companies it just is not affordable.
During that call they did direct me to one of their partners AuthLite. In this case, we ended up giving their product a try and it is definitely something that I would recommend. Their product provides the ability to manage MFA for all domain users without the need to install additional software on client machines (just one lightweight app to install on Domain Controllers). Typically, just appending the MFA code to the username field is all that is required. This also works for integrated services such as VPNs (can confirm that Cisco AnyConnect works with AuthLite). Best of all, AuthLite will not break the budget!
Hey, very nice tutorial! I did not find FVE in step 3, so I created it myself. Bitlocker still says it cannot find a usable certificate.. I am guessing it is because of this? What could be the reason for the missing node?
I am not sure why the FVE key would be missing; upon checking my current PC, I am also missing the FVE key. I would suggest to right-click on the Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft and select New -> Key. Then name this Key FVE. After this you will be able to perform step 3.
Just got a few yubikeys (5Ci) in and wanted to start utilizing them for things. In my case Step 3 and 4 were reversed. Once I completed Step 4 then the FVE directory in regedit appeared with the correct OID versioning.
After following these steps, would I be able to mount the encrypted drive on another, unmodified Windows Pro computer using the Yubikey? Would the other computer likely need configuration changes before I could unlock the drive?
You may need to install the YubiKey Smart Card Minidriver mentioned in Step 1 on the target machine. As for the Bitlocker requirements there should be no issue. Although, if memory serves correctly, I believe when I set up my current laptop I was able to unlock the drives without any extra setup.
Or, if you have another PC available that you have administrative rights to, you could use that one for the configuration of the BitLocker drives (assuming it is not an internal drive on the PC in question). You can still use the domain PC to unlock the drives, just complete Step 1 so that the domain PC has the required drivers for the YubiKey.
3a8082e126