08-03-2018 02:00 PM
08-03-2018 02:00 PM
1) I have a valid (paid for) code signing certificate from a well known CA that has a password so I can't use the in tool signing (which is something you should support!).
The 17134 SDK is present. So I pulled the command out of the log file and modified as follows (but with the proper password):
"C:\Program Files (x86)\Windows Kits\10\bin\10.0.17134.0\x64\signtool.exe" sign /a /v /debug /fd SHA256 /f "C:\Users\Admin\Desktop\strongname.pfx" /p "xxxThePasswordxxx" "C:\Users\Admin\Desktop\TMEdit\Setup_TMEdit.msix"
Which fails. The relevant output being:
08-07-2018 12:59 AM
just to clarify:
This is the structure of my PKI:
CN=Johannes Freundorfer, OU=MyCustomOU, OU=MyOrg, DC=MyDomain, DC=dom
Applied to your case:
is "TMurgent Technologies, LLP" really your explicit Subject name (Including the "," character )?
My current best guess is, that his can't match the schema.
08-07-2018 02:48 AM
According to MSFT docs comma (",") is a reserved character that must be escaped, as show in their examples from the linked article.
It seems that using "\," is still not considered correct by the GUI of MSIX packaging tool, but it does not complain when using the hex value for comma, i.e. "CN=TMurgent Technologies \2C LLP".
I don't have a test certificate at hand with a command in the publisher name to fully test it, but according to their docs it should work.
08-07-2018 06:38 AM
Escaping in the dialog box as Bogdan suggested does indeed work.
But the GUI of the tool should just accept the comma and escape it behind the scenes.
In addition, when there is documentation on all of this, the documentation should be clear about what to include in this field. There will be confusion on if OU= parts should be included. Just make it clear in the documentation, especially for people that don't deal in certificates regularly.
08-07-2018 07:31 AM
I spoke too soon...
Entering the escape works to get past the UI dialog and makes a package if you don't sign it. The AppXManifest ends up with the \2C in the publishing field, but then the signtool errors (8007000b) against it. I'm not sure if the fault on that is the PackagingTool or signtool.
I would think that the least confusing solution for everyone is to let the PackagingTool accept the comma (and other escape-worthy characters) and place them in the Publishing field as is, and then fix the signtool to understand and escape if necessary.
Of course the best solution might be to let me point to the certificate earlier in the PackagingTool and have it extract what it needs rather than allow us to mess this all up. Probably still need to fix signtool, but the more of this that can be automated the better.