I’m trying to understand the Windows codesigning process for signing exported applications using Godot 4.x. Following the Godot Windows export tutorial I think I understand the setup needed in Godot for setting the path to Signtool and my signing certificate.
However, when reading the linked microsoft description for how to generate a certificate (at least for testing) it mentions as one of the first points that the Publisher name in the certificate must match the publisher information in your AppxManifest.xml (some application package?). And I assume this is the same if you purchase a certificate from a certificate authority.
In the Godot export process, where/how is this AppxManifest.xml publisher information set so that the exact same information can be used in the signing certificate?
The Godot windows export docs also warn that “If you export for Windows with embedded PCK files, you will not be able to sign the program as it will break.” . Is this still true, or is this information outdated? And “break” in what way?
Since the point of code signing is to prevent tampering with distributed content (at least warn the user about it) and all scripts for the exported project are stored in the PCK as I understand it signing the .exe with the pck embedded seems like the natural way to do it?
AppxManifest is a UWP thing; it isn’t used in Win32 applications like Godot. In Win32 applications, the publisher field is set in the executable (you can do this on export after setting up rcedit in Godot).
And yes, PCK embedding still can’t be used with codesigning as of 4.3.dev3.
Where you can set things like Company name, version etc? This looks like it sets some fields in StringFileInfo for the application, the Win32 version of the AppxManifest? Since this standard doesn’t seem to have a “Publisher” field, does this mean that there’s nothing that needs to match the certificate when signing a win32 application?
Regarding the embedded PCK breaking codesigning, is this due to the content of the pck changing for some reason when the application is run on the user system? If signing the pck isn’t possible, are there any other checks in place to detect if the .pck has been modified?
That said, I don’t know if there’s actually a strict need to have this match the name in the certificate. Back in the days of Certum open source code signing certificates, there were lots of certificates with “, Open Source Developer” publishers in the certificate, but the publisher field in the installer/executable was completely different.
Ok, thanks for the answers. I’ll leave this open in case someone else with experience in doing this has more information to share. Otherwise I’ll just have to do some trial and error, and if/when I figure it out and get it working I can make a proposal for the export docs to document how to set this up.
Regarding the PCK signing it’s good this is being worked on, but this looks like a cross-platform solution with a lot of extra steps needed. Like setting up and managing separate keys and making a custom build of the engine. Perhaps the main use case is for linux if there’s no OS system there for signing? But it seems redundant on macOS where there’s already notarization of the entire package and on windows there is SignTool and that you need to use for signing the executive with SignTool as well anyway. If SignTool can’t sign the .exe with the pck embedded, getting the separate pck file signed with SignTool and the same certificate, and then using that to verify the signature seems like it would be a lot easier?
I was told by bruvzg that PCK embedding and codesigning should work at the same time if the PCK is embedded before the binary is signed (I don’t know if Godot currently does it in this order).
Great, thanks for looking into it. And I think this would then be a good reason to do the signing last if this is not the case today.
If signing with embedded pck was supported I think it would be a great improvement especially for non-game development with Godot where code-signing will be more or less required as you’re not distributing via Steam or such and distributing as a single .exe package will be desirable.
Hi, did you have any success with code signing with purchased certificate?
I am getting ready to publish my game on MS Store which requires code signing with certificate from certification authority, and as you mentioned, the linked microsoft description of how to generate ceritifcate is making me worry.
What about that matching of the publisher information from the Appxmanifest file?
Hello, not yet unfortunately. I did look into it some more. But seeing how it was expensive and uncertain if it would work I’ve been putting it off, hoping/waiting for some clarifications on the embedded .pck .exe signing in Godot.
I’m however now also getting a little closer to a first release of my project with a first round of external testing under way, so I was just getting back to it. Basically I’m planning on just buying a certificate from one of the certificate authorities, and hope that in that process I will be able to set publisher info there that I can match in the export settings. Regarding the Appxmanifest file I’ll just have to trust the reply above then that it’s not relevant for Win32 apps and only used/exists for UWP windows apps.
I’ll the also see if I can get it to work with signing the app with embedded .pck and see if I can get that to work as I’d really like to distribute the application as a single .exe file on windows for simple installation. If it doesn’t work I guess I can fall back to not embedding the .pck file on windows and see if that works instead until this is supported.
If you’re doing something similar, please share how it worked out for you.
We are at similar situation. I am about to start public testing. And as I am planning on realeasing my game on MS Store, I thought I’d use it to distribute the testing version too. But than I got into Code Signing Certificates, their insane prices and the necessity to get them on some usb stick, uncertainty about the signing process (and me trying to do it on Linux, actually) and then I got here
The embedded PCK issue is not my concern, as MS Store requires me to distribute my app as an installer anyway. However, from what I learned so far, there should be no issue with distribution of the single exe file. You just make sure you codesign it after the PCK file got embedded. And you don’t even have to rely with that on Godot itself. You can make Godot do it’s thing with embedding, and then sign the exe file manually ensuring you got it signed at right moment. Don’t you think?
My next steps are to play with self signed certificate, see what I can achieve with them and probably, in the nearest days, order some cheap CSC. The cheapest 1 year option I found so far is this: https://cheapsslsecurity.com/fastssl/code-signing-certificate.html for 264USD with token and shipping.
Yeah, I work primarily on macOS and all my previous experience with distributing apps is for macOS and iOS, so the whole experience with exporting and distributing for windows (and linux) is a bit foreign to me. This is also why I’d like to use the Godot built-in exporting signing features as far as possible, to reduce the risk of me making mistakes.
But you’re right that if signing the .exe during Godot export with embedded .pck doesn’t work I should be able to do it using SignTool myself afterwards on the exported .exe, even if that does add another step to the export process.
As for signing certificates there are also (slightly cheaper) options at https://codesigningstore.com/ and https://signmycode.com/ I’ve looked at. I feel like there’s no way to determine if any of these suppliers are more trustworthy than others, so if you’ve found one you think looks good go for that.
Another tip I found during research is to make sure you submit your builds preemptively to Microsoft Malware checks Submit a file for malware analysis - Microsoft Security Intelligence to at least reduce the chance of getting the warnings dialogues about your app even when it’s signed.
Looking into this again it turns out that Microsoft actually seems to have finally figured out how crazy and overpriced the certificate process for code signing has become and have just now started providing their own internal service for it (now in public preview):
It requires you to be using their Azure cloud services (or at least have an microsoft azure account), but there seems to be a free “pay for what you use” account type that (might?) get you access to these integrated code signing certificate services without requiring you to actually be using or paying for any of the Azure cloud services.
Just an Update: I finally managed to get Windows code signing to work via Microsoft Azure Trusted Signing. It’s very complicated to set up, but once you get it done it’s a lot less expensive (at about $10 per month compared to third party alternatives of $400-500 per year depending on your location for basic signing that still gets you a warning on launch) and much easier to use requiring no encrypted special USB dongle to keep track of or additional suspicious third party software you need to install.
The official documentation on how to get it set up:
Is however, very lacking. But there are other better guides, like for example:
With this set up I just export normally for windows in Godot, with embedded pck into a .exe for windows but no code signing in the export settings. And then after that I use a terminal command to run the Microsoft Sign Tool, which after setup automatically gets/generates a certificate from Azure Trusted Signing and uses this to sign the .exe.
