Appxmanifest Identity Publisher contains ST=Oregon instead of S=Oregon

%3CLINGO-SUB%20id%3D%22lingo-sub-1907751%22%20slang%3D%22en-US%22%3EAppxmanifest%20Identity%20Publisher%20contains%20ST%3DOregon%20instead%20of%20S%3DOregon%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1907751%22%20slang%3D%22en-US%22%3E%3CP%3EI%20am%20trying%20to%20use%20the%26nbsp%3B10.0.19041.0%20makeappx.exe%20using%20a%20certificate%20I%20can%20not%20change.%26nbsp%3B%20The%20issue%20is%20that%20the%20publisher%20subject%20lines%20contains%20ST%3DOregon%20instead%20of%20S%3DOregon%20and%20I%20get%20the%20following%20error%3A%3CBR%20%2F%3E%3CBR%20%2F%3EMakeAppx%20%3A%20error%3A%20Error%20info%3A%20error%20C00CE169%3A%20App%20manifest%20validation%20error%3A%20The%20app%20manifest%20must%20be%20valid%20as%20per%20schema%3A%20Line%206%2C%20Column%2045%2C%20Reason%3A%20'C%3DUS%2C%20ST%3DOregon%2C%20L%3DPortland%2C%20O%3DAcme%20Inc%2C%20CN%3DAcme%20Inc'%20violates%20pattern%20constraint%20of%20'(CN%7CL%7CO%7COU%7CE%7CC%7CS%7CSTREET%7CT%7CG%7CI%7CSN%7CDC%7CSERIALNUMBER%7CDescription%7CPostalCode%7CPOBox%7CPhone%7CX21Address%7CdnQualifier%7C(OID%5C.(0%7C%5B1-9%5D%5B0-9%5D*)(%5C.(0%7C%5B1-9%5D%5B0-9%5D*))%2B))%3D((%5B%5E%2C%2B%3D%22%26lt%3B%26gt%3B%23%3B%5D)%2B%7C%22.*%22)(%2C%20((CN%7CL%7CO%7COU%7CE%7CC%7CS%7CSTREET%7CT%7CG%7CI%7CSN%7CDC%7CSERIALNUMBER%7CDescription%7CPostalCode%7CPOBox%7CPhone%7CX21Address%7CdnQualifier%7C(OID%5C.(0%7C%5B1-9%5D%5B0-9%5D*)(%5C.(0%7C%5B1-9%5D%5B0-9%5D*))%2B))%3D((%5B%5E%2C%2B%3D%22%26lt%3B%26gt%3B%23%3B%5D)%2B%7C%22.*%22)))*'.%3CBR%20%2F%3EThe%20attribute%20'Publisher'%20with%20value%20'C%3DUS%2C%20ST%3DOregon%2C%20L%3DPortland%2C%20O%3DAcme%20Inc%2C%20CN%3DAcme%20Inc'%20failed%20to%20parse.%3CBR%20%2F%3E%3CBR%20%2F%3EIf%20I%20set%20S%3DOregon%20it%20packages%20fine.%20However%2C%20it%20then%20cannot%20be%20signed%20because%20the%20subject%20line%20in%20the%20certificate%20has%20ST%3DOregon%20and%20it%20doesn't%20match.%20Is%20there%20a%20way%20to%20get%20around%20this%20other%20then%20getting%20a%20new%20certificate%20created%3F%26nbsp%3B%3CBR%20%2F%3E%3CBR%20%2F%3Ethanks%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1928815%22%20slang%3D%22en-US%22%3ERe%3A%20Appxmanifest%20Identity%20Publisher%20contains%20ST%3DOregon%20instead%20of%20S%3DOregon%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1928815%22%20slang%3D%22en-US%22%3E%3CP%3EHi%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F875052%22%20target%3D%22_blank%22%3E%40dmondou%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ECan%20you%20try%20passing%20in%20the%20%3CSTRONG%3E%2Fnv%3C%2FSTRONG%3E%20flag%20to%20MakeAppx%20when%20packaging.%20This%20should%20skip%20semantic%20validation.%20You'll%20have%20to%20verify%20that%20your%20package%20installs%20successfully%20after%20it's%20created.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ECheers%2C%3C%2FP%3E%0A%3CP%3ETanaka%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1934042%22%20slang%3D%22en-US%22%3ERe%3A%20Appxmanifest%20Identity%20Publisher%20contains%20ST%3DOregon%20instead%20of%20S%3DOregon%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1934042%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F875052%22%20target%3D%22_blank%22%3E%40dmondou%3C%2FA%3E%26nbsp%3BThis%20seems%20to%20be%20a%20possible%20bug%20in%20regexp%20validation%20of%20makeappx.exe.%20According%20to%20RFC%204519%2C%20ST%20should%20be%20a%20valid%20token%20(%3CA%20href%3D%22https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc4519%23section-2.33%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noreferrer%22%3ERFC%204519%20-%20Lightweight%20Directory%20Access%20Protocol%20(LDAP)%3A%20Schema%20for%20User%20Applications%20(ietf.org)).%3C%2FA%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ENow%20while%20this%20does%20not%20help%20with%20the%20original%20problem%2C%20here%20is%20a%20weird%20thing.%3C%2FP%3E%3CP%3EI%20tried%20to%20test%20it%20myself%2C%20and%20tried%20to%20first%20create%20a%20test%20code%20signing%20certificate%20using%20your%20subject%20name.%20Invoking%20the%20following%20two%20commands%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CPRE%20class%3D%22lia-code-sample%20language-powershell%22%3E%3CCODE%3E%24certificate%20%3D%20New-SelfSignedCertificate%20-Type%20Custom%20-KeyUsage%20DigitalSignature%20-Subject%20%22C%3DUS%2C%20ST%3DOregon%2C%20L%3DPortland%2C%20O%3DAcme%20Inc%2C%20CN%3DAcme%20Inc%22%20-FriendlyName%20%22AcmeTest%22%20-CertStoreLocation%20'Cert%3A%5CCurrentUser%5Cmy'%3B%0A%0A(Get-ChildItem%20-path%20%22Cert%3A%5CCurrentUser%5Cmy%22%20%7C%20%3F%20%7B%20%24_.Subject.IndexOf(%22Oregon%22)%20-ne%20-1%20%7D).Subject%3C%2FCODE%3E%3C%2FPRE%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESeems%20to%20output%3A%3C%2FP%3E%3CP%3E%3CSTRONG%3EC%3DUS%2C%20%3CFONT%20color%3D%22%23FF0000%22%3ES%3C%2FFONT%3E%3DOregon%2C%20L%3DPortland%2C%20O%3DAcme%20Inc%2C%20CN%3DAcme%20Inc%3C%2FSTRONG%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20same%20if%20you%20use%20makecert.exe%2C%20ST%20gets%20somehow%20replaced%20with%20S.%20No%20idea%20why%2C%20but%20seems%20to%20partially%20explain%20the%20choice%20of%20the%20regexp%20used%20by%20makeappx.exe.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1956539%22%20slang%3D%22en-US%22%3ERe%3A%20Appxmanifest%20Identity%20Publisher%20contains%20ST%3DOregon%20instead%20of%20S%3DOregon%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1956539%22%20slang%3D%22en-US%22%3E%3CP%3E%3CSPAN%3EHello%26nbsp%3B%3C%2FSPAN%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F387730%22%20target%3D%22_blank%22%3E%40Tanaka_Jimha%3C%2FA%3E%2C%3CBR%20%2F%3E%3CBR%20%2F%3EIs%20there%20an%20update%20on%20this%20issue%3F%20as%20it%20is%20a%20blocker%20for%20us%20in%20trying%20to%20deploy%20our%20app.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThanks%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EDavid%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1965387%22%20slang%3D%22en-US%22%3ERe%3A%20Appxmanifest%20Identity%20Publisher%20contains%20ST%3DOregon%20instead%20of%20S%3DOregon%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1965387%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F875052%22%20target%3D%22_blank%22%3E%40dmondou%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EDid%20you%20confirm%20that%20signing%20fails%20when%20you%20set%20S%3DOregon%20in%20the%20manifest%3F%20I%20chatted%20with%20the%20team%20and%20they%20said%20the%20validation%20uses%20this%20CertNameToStr%20function%20-%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fapi%2Fwincrypt%2Fnf-wincrypt-certnametostra%3Fredirectedfrom%3DMSDN%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3ECertNameToStrA%20function%20(wincrypt.h)%20-%20Win32%20apps%20%7C%20Microsoft%20Docs%3C%2FA%3E%26nbsp%3Band%20it%20says%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CEM%3E%22The%20string%20representation%20follows%20the%20distinguished%20name%20specifications%20in%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fwww.ietf.org%2Frfc%2Frfc1779.txt%22%20data-linktype%3D%22external%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%22%3ERFC%201779%3C%2FA%3E%26nbsp%3Bexcept%20for%20the%20deviations%20described%20in%20the%20following%20list%3A%3C%2FEM%3E%3C%2FP%3E%0A%3CUL%3E%0A%3CLI%3E%3CEM%3EThe%20X.500%20key%20name%20for%20stateOrProvinceName%20(2.5.4.8)%20OID%20is%20%22S%22.%20This%20value%20is%20different%20from%20the%20RFC%201779%20X.500%20key%20name%20(%22ST%22).%20%22%3C%2FEM%3E%3C%2FLI%3E%0A%3C%2FUL%3E%0A%3CP%3EUnfortunately%20it%20looks%20like%20ST%3DOregon%20will%20not%20work%2C%20and%20you'll%20need%20a%20subject%20name%20with%20S%3DOregon.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1991793%22%20slang%3D%22en-US%22%3ERe%3A%20Appxmanifest%20Identity%20Publisher%20contains%20ST%3DOregon%20instead%20of%20S%3DOregon%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1991793%22%20slang%3D%22en-US%22%3E%3CP%3EHi%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F875052%22%20target%3D%22_blank%22%3E%40dmondou%3C%2FA%3E%26nbsp%3B%2C%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EDid%20signing%20fail%20with%20ST%3DOregon%3F%3C%2FP%3E%0A%3CP%3EI've%20added%20this%20request%20to%20our%20backlog%2C%20so%20that%20using%20ST%3DOregon%20would%20be%20supported%20by%20default.%20I'm%20sorry%20it%20doesn't%20work%20currently%20and%20it's%20causing%20issues%20for%20you.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThanks%2C%3C%2FP%3E%0A%3CP%3ETanaka%3C%2FP%3E%3C%2FLINGO-BODY%3E
Occasional Contributor

I am trying to use the 10.0.19041.0 makeappx.exe using a certificate I can not change.  The issue is that the publisher subject lines contains ST=Oregon instead of S=Oregon and I get the following error:

MakeAppx : error: Error info: error C00CE169: App manifest validation error: The app manifest must be valid as per schema: Line 6, Column 45, Reason: 'C=US, ST=Oregon, L=Portland, O=Acme Inc, CN=Acme Inc' violates pattern constraint of '(CN|L|O|OU|E|C|S|STREET|T|G|I|SN|DC|SERIALNUMBER|Description|PostalCode|POBox|Phone|X21Address|dnQualifier|(OID\.(0|[1-9][0-9]*)(\.(0|[1-9][0-9]*))+))=(([^,+="<>#;])+|".*")(, ((CN|L|O|OU|E|C|S|STREET|T|G|I|SN|DC|SERIALNUMBER|Description|PostalCode|POBox|Phone|X21Address|dnQualifier|(OID\.(0|[1-9][0-9]*)(\.(0|[1-9][0-9]*))+))=(([^,+="<>#;])+|".*")))*'.
The attribute 'Publisher' with value 'C=US, ST=Oregon, L=Portland, O=Acme Inc, CN=Acme Inc' failed to parse.

If I set S=Oregon it packages fine. However, it then cannot be signed because the subject line in the certificate has ST=Oregon and it doesn't match. Is there a way to get around this other then getting a new certificate created? 

thanks

9 Replies

Hi @dmondou 

 

Can you try passing in the /nv flag to MakeAppx when packaging. This should skip semantic validation. You'll have to verify that your package installs successfully after it's created.

 

Cheers,

Tanaka

 

 

Hello @Tanaka_Jimha ,

With the /nv flag it does try to package up the files but then throws the following error:


MakeAppx : error: Error info: error C00CE169: App manifest validation error: The app manifest must be valid as per schema: Line 6, Column 45, Reason: 'C=US, ST=Oregon, L=Portland, O=Acme Inc, CN=Acme Inc' violates pattern constraint of '(CN|L|O|OU|E|C|S|STREET|T|G|I|SN|DC|SERIALNUMBER|Description|PostalCode|POBox|Phone|X21Address|dnQualifier|(OID\.(0|[1-9][0-9]*)(\.(0|[1-9][0-9]*))+))=(([^,+="<>#;])+|".*")(, ((CN|L|O|OU|E|C|S|STREET|T|G|I|SN|DC|SERIALNUMBER|Description|PostalCode|POBox|Phone|X21Address|dnQualifier|(OID\.(0|[1-9][0-9]*)(\.(0|[1-9][0-9]*))+))=(([^,+="<>#;])+|".*")))*'.
The attribute 'Publisher' with value 'C=US, ST=Oregon, L=Portland, O=Acme Inc, CN=Acme Inc' failed to parse.

 

Without the /nv flag it doesn't try to package anything it just throws the error right away.

Thanks,
David

@dmondou This seems to be a possible bug in regexp validation of makeappx.exe. According to RFC 4519, ST should be a valid token (RFC 4519 - Lightweight Directory Access Protocol (LDAP): Schema for User Applications (ietf.org)).

 

Now while this does not help with the original problem, here is a weird thing.

I tried to test it myself, and tried to first create a test code signing certificate using your subject name. Invoking the following two commands:

 

 

$certificate = New-SelfSignedCertificate -Type Custom -KeyUsage DigitalSignature -Subject "C=US, ST=Oregon, L=Portland, O=Acme Inc, CN=Acme Inc" -FriendlyName "AcmeTest" -CertStoreLocation 'Cert:\CurrentUser\my';

(Get-ChildItem -path "Cert:\CurrentUser\my" | ? { $_.Subject.IndexOf("Oregon") -ne -1 }).Subject

 

Seems to output:

C=US, S=Oregon, L=Portland, O=Acme Inc, CN=Acme Inc

 

The same if you use makecert.exe, ST gets somehow replaced with S. No idea why, but seems to partially explain the choice of the regexp used by makeappx.exe.

 

Hello @Tanaka_Jimha,

Is there an update on this issue? as it is a blocker for us in trying to deploy our app.

 

Thanks,

 

David

Thanks for digging further into this.

Hi @dmondou 

 

Did you confirm that signing fails when you set S=Oregon in the manifest? I chatted with the team and they said the validation uses this CertNameToStr function - CertNameToStrA function (wincrypt.h) - Win32 apps | Microsoft Docs and it says

 

"The string representation follows the distinguished name specifications in RFC 1779 except for the deviations described in the following list:

  • The X.500 key name for stateOrProvinceName (2.5.4.8) OID is "S". This value is different from the RFC 1779 X.500 key name ("ST"). "

Unfortunately it looks like ST=Oregon will not work, and you'll need a subject name with S=Oregon.

Hi @Tanaka_Jimha ,

Using S=Oregon does work, however our certificate is through Digicert and we discussed with them or issuing a cert with S=Oregon and they won't do it. Any chance of getting ST=Oregon changed in MSIX?

Thanks,

David  

Hi @dmondou ,

 

Did signing fail with ST=Oregon?

I've added this request to our backlog, so that using ST=Oregon would be supported by default. I'm sorry it doesn't work currently and it's causing issues for you.

 

Thanks,

Tanaka

@Tanaka_Jimha 

 

Signing does fail with ST=Oregon

Thanks,

 

David