MSIX Packageing Tool / signtool certificate issues

%3CLINGO-SUB%20id%3D%22lingo-sub-224217%22%20slang%3D%22en-US%22%3EMSIX%20Packageing%20Tool%20%2F%20signtool%20certificate%20issues%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-224217%22%20slang%3D%22en-US%22%3E%3CP%3E1)%20I%20have%20a%20valid%20(paid%20for)%20code%20signing%20certificate%20from%20a%20well%20known%20CA%20that%20has%20a%20password%20so%20I%20can't%20use%20the%20in%20tool%20signing%20(which%20is%20something%20you%20should%20support!).%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%2017134%20SDK%20is%20present.%26nbsp%3B%20So%20I%20pulled%20the%20command%20out%20of%20the%20log%20file%20and%20modified%20as%20follows%20(but%20with%20the%20proper%20password)%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%22C%3A%5CProgram%20Files%20(x86)%5CWindows%20Kits%5C10%5Cbin%5C10.0.17134.0%5Cx64%5Csigntool.exe%22%20sign%20%2Fa%20%2Fv%20%2Fdebug%20%2Ffd%20SHA256%20%2Ff%20%22C%3A%5CUsers%5CAdmin%5CDesktop%5Cstrongname.pfx%22%20%2Fp%20%22xxxThePasswordxxx%22%20%22C%3A%5CUsers%5CAdmin%5CDesktop%5CTMEdit%5CSetup_TMEdit.msix%22%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWhich%20fails.%26nbsp%3B%20The%20relevant%20output%20being%3A%3C%2FP%3E%3CDIV%3EAfter%20EKU%20filter%2C%201%20certs%20were%20left.%3CBR%20%2F%3EAfter%20expiry%20filter%2C%201%20certs%20were%20left.%3CBR%20%2F%3EAfter%20Private%20Key%20filter%2C%201%20certs%20were%20left.%3CBR%20%2F%3EThe%20following%20certificate%20was%20selected%3A%3CBR%20%2F%3E%26nbsp%3B%26nbsp%3B%26nbsp%3B%20Issued%20to%3A%20TMurgent%20Technologies%2C%20LLP%3CBR%20%2F%3E%26nbsp%3B%26nbsp%3B%26nbsp%3B%20Issued%20by%3A%20COMODO%20RSA%20Code%20Signing%20CA%3CBR%20%2F%3E%26nbsp%3B%26nbsp%3B%26nbsp%3B%20Expires%3A%26nbsp%3B%26nbsp%3B%20Mon%20Jun%2021%2019%3A59%3A59%202021%3CBR%20%2F%3E%26nbsp%3B%26nbsp%3B%26nbsp%3B%20SHA1%20hash%3A%20A5CD580A89C438FB9B87753BB05F383560EB366F%3C%2FDIV%3E%3CDIV%3E%3CBR%20%2F%3EThe%20following%20additional%20certificates%20will%20be%20attached%3A%3CBR%20%2F%3E%26nbsp%3B%26nbsp%3B%26nbsp%3B%20Issued%20to%3A%20COMODO%20RSA%20Code%20Signing%20CA%3CBR%20%2F%3E%26nbsp%3B%26nbsp%3B%26nbsp%3B%20Issued%20by%3A%20COMODO%20RSA%20Certification%20Authority%3CBR%20%2F%3E%26nbsp%3B%26nbsp%3B%26nbsp%3B%20Expires%3A%26nbsp%3B%26nbsp%3B%20Mon%20May%2008%2019%3A59%3A59%202028%3CBR%20%2F%3E%26nbsp%3B%26nbsp%3B%26nbsp%3B%20SHA1%20hash%3A%20B69E752BBE88B4458200A7C0F4F5B3CCE6F35B47%3C%2FDIV%3E%3CDIV%3EDone%20Adding%20Additional%20Store%3CBR%20%2F%3ESignTool%20Error%3A%20An%20unexpected%20internal%20error%20has%20occurred.%3CBR%20%2F%3EError%20information%3A%20%22Error%3A%20SignerSign()%20failed.%22%20(-2147024846%2F0x80070032)%3C%2FDIV%3E%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%3E%232%20Reading%20up%20on%20this%20we%20get%20to%20cause%20of%20issue%20number%202%3A%26nbsp%3B%20The%20name%20of%20the%20publisher%20in%20CN%20form%20in%20the%20manifest%20(input%20from%20the%20MSIX%20Manifest%20tool)%20must%20exactly%20match%20that%20of%20the%20certificate%3A%3C%2FDIV%3E%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%3EInside%20the%20certificate%2C%26nbsp%3B%20The%20publisher%20name%20is%3C%2FDIV%3E%3CDIV%3E%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20CN%3DTMurgent%20Technologies%2C%20LLP%3C%2FDIV%3E%3CDIV%3Ewhich%2C%20unfortunately%2C%20is%20the%20legal%20name%20of%20the%20entity%20so%20that%20isn't%20changing!%3C%2FDIV%3E%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%3EThe%20MSIX%20Package%20Tool%20does%20not%20allow%20a%20comma%20in%20the%20input%20field.%26nbsp%3B%3C%2FDIV%3E%3CDIV%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-center%22%20style%3D%22width%3A%20450px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Fgxcuf89792.i.lithium.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F38954iF75A57BD2D4FD231%2Fimage-size%2Flarge%3Fv%3D1.0%26amp%3Bpx%3D999%22%20alt%3D%22Capture.PNG%22%20title%3D%22Capture.PNG%22%20%2F%3E%3C%2FSPAN%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FDIV%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-225212%22%20slang%3D%22en-US%22%3ERe%3A%20MSIX%20Packageing%20Tool%20%2F%20signtool%20certificate%20issues%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-225212%22%20slang%3D%22en-US%22%3E%3CP%3EI%20spoke%20too%20soon...%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EEntering%20the%20escape%20works%20to%20get%20past%20the%20UI%20dialog%20and%20makes%20a%20package%20if%20you%20don't%20sign%20it.%20The%20AppXManifest%20ends%20up%20with%20the%20%5C2C%20in%20the%20publishing%20field%2C%20but%20then%20the%20signtool%20errors%20(8007000b)%20against%20it.%26nbsp%3B%20I'm%20not%20sure%20if%20the%20fault%20on%20that%20is%20the%20PackagingTool%20or%20signtool.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20would%20think%20that%20the%20least%20confusing%20solution%20for%20everyone%20is%20to%20let%20the%20PackagingTool%20accept%20the%20comma%20(and%20other%20escape-worthy%20characters)%20and%20place%20them%20in%20the%20Publishing%20field%20as%20is%2C%20and%20then%20fix%20the%20signtool%20to%20understand%20and%20escape%20if%20necessary.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EOf%20course%20the%20best%20solution%20might%20be%20to%20let%20me%20point%20to%20the%20certificate%20earlier%20in%20the%20PackagingTool%20and%20have%20it%20extract%20what%20it%20needs%20rather%20than%20allow%20us%20to%20mess%20this%20all%20up.%20Probably%20still%20need%20to%20fix%20signtool%2C%20but%20the%20more%20of%20this%20that%20can%20be%20automated%20the%20better.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-225183%22%20slang%3D%22en-US%22%3ERe%3A%20MSIX%20Packageing%20Tool%20%2F%20signtool%20certificate%20issues%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-225183%22%20slang%3D%22en-US%22%3E%3CP%3EEscaping%20in%20the%20dialog%20box%20as%20Bogdan%20suggested%20does%20indeed%20work.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EBut%20the%20GUI%20of%20the%20tool%20should%20just%20accept%20the%20comma%20and%20escape%20it%20behind%20the%20scenes.%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIn%20addition%2C%20when%20there%20is%20documentation%20on%20all%20of%20this%2C%20the%20documentation%20should%20be%20clear%20about%20what%20to%20include%20in%20this%20field.%26nbsp%3B%20There%20will%20be%20confusion%20on%20if%20OU%3D%20parts%20should%20be%20included.%26nbsp%3B%20Just%20make%20it%20clear%20in%20the%20documentation%2C%20especially%20for%20people%20that%20don't%20deal%20in%20certificates%20regularly.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-225168%22%20slang%3D%22en-US%22%3ERe%3A%20MSIX%20Packageing%20Tool%20%2F%20signtool%20certificate%20issues%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-225168%22%20slang%3D%22en-US%22%3E%3CP%3EThanks%20Bogdan%20-%20I'll%20give%20that%20a%20try.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-225093%22%20slang%3D%22en-US%22%3ERe%3A%20MSIX%20Packageing%20Tool%20%2F%20signtool%20certificate%20issues%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-225093%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20Tim%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fprevious-versions%2Fwindows%2Fdesktop%2Fldap%2Fdistinguished-names%22%20target%3D%22_self%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3EAccording%20to%20MSFT%20docs%3C%2FA%3E%20comma%20(%22%2C%22)%20is%20a%20reserved%20character%20that%20must%20be%20escaped%2C%20as%20show%20in%20their%20examples%20from%20the%20linked%20article.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIt%20seems%20that%20using%20%22%5C%2C%22%20is%20still%20not%20considered%20correct%20by%20the%20GUI%20of%20MSIX%20packaging%20tool%2C%20but%20it%20does%20not%20complain%20when%20using%20the%20hex%20value%20for%20comma%2C%20i.e.%20%22CN%3DTMurgent%20Technologies%20%5C2C%20LLP%22.%3CBR%20%2F%3E%3CBR%20%2F%3EI%20don't%20have%20a%20test%20certificate%20at%20hand%20with%20a%20command%20in%20the%20publisher%20name%20to%20fully%20test%20it%2C%20but%26nbsp%3Baccording%20to%20their%20docs%20it%20should%20work.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-225060%22%20slang%3D%22en-US%22%3ERe%3A%20MSIX%20Packageing%20Tool%20%2F%20signtool%20certificate%20issues%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-225060%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20Thimothy%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3Ejust%20to%20clarify%3A%3C%2FP%3E%3CP%3EThis%20is%20the%20structure%20of%20my%20PKI%3A%3C%2FP%3E%3CP%3ECN%3DJohannes%20Freundorfer%2C%20OU%3DMyCustomOU%2C%20OU%3DMyOrg%2C%20DC%3DMyDomain%2C%20DC%3Ddom%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EA%3CSPAN%3Epplied%20to%20your%20case%3A%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3Eis%20%22T%3C%2FSPAN%3E%3CSPAN%3EMurgent%20Technologies%2C%20LLP%22%20really%20your%20explicit%20Subject%20name%20(Including%20the%20%22%2C%22%20character%20)%3F%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3EMy%20current%20best%20guess%20is%2C%20that%20his%20can't%20match%20the%20schema.%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E
MVP

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:

After EKU filter, 1 certs were left.
After expiry filter, 1 certs were left.
After Private Key filter, 1 certs were left.
The following certificate was selected:
    Issued to: TMurgent Technologies, LLP
    Issued by: COMODO RSA Code Signing CA
    Expires:   Mon Jun 21 19:59:59 2021
    SHA1 hash: A5CD580A89C438FB9B87753BB05F383560EB366F

The following additional certificates will be attached:
    Issued to: COMODO RSA Code Signing CA
    Issued by: COMODO RSA Certification Authority
    Expires:   Mon May 08 19:59:59 2028
    SHA1 hash: B69E752BBE88B4458200A7C0F4F5B3CCE6F35B47
Done Adding Additional Store
SignTool Error: An unexpected internal error has occurred.
Error information: "Error: SignerSign() failed." (-2147024846/0x80070032)
 
#2 Reading up on this we get to cause of issue number 2:  The name of the publisher in CN form in the manifest (input from the MSIX Manifest tool) must exactly match that of the certificate:
 
Inside the certificate,  The publisher name is
          CN=TMurgent Technologies, LLP
which, unfortunately, is the legal name of the entity so that isn't changing!
 
The MSIX Package Tool does not allow a comma in the input field. 
Capture.PNG

 

 

5 Replies

Hi Thimothy,

 

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.

 

 

 

 

Hi Tim,

 

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.

Thanks Bogdan - I'll give that a try.

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.

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.