Not able to install enterprise build in iOS 15 beta version

@timothy-sutton and @JLJohnson

It would still be great if this could just be documented publicly (see FB9190730).

and

(c) Official documentation on this requirement, similar to the 'Using the Latest Code Signature Format' article that Quinn linked above. I have just submitted a bug report regarding this: FB9318576

Thank you for opening bug reports here. As for the documentation, there is an effort underway to update the existing documentation, but I do not have a timeline for when that is available.

@JLJohnson

Regarding:

(a) Code signing and app distribution isn't required prior to the release of iOS 15.

Could you elaborate a bit more about what you are wanting here with (a)?

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

For anyone having an issue with code signing their app with the --generate-entitlement-der on macOS Catalina, here is what I did today as a workaround:

(1) Built an Ad-Hoc iOS app that targeted iOS 13 on macOS Catalina. I checked the Page size on the signature and saw the missing -7 value:

$ codesign -dvvvvv MyTestApp.app
...
Page size=4096
    -5=7c741a970873bb7f6a05c1ad5b9425f4b5b1ac86645b2cb8c842a57f51818eb5
    -4=0000000000000000000000000000000000000000000000000000000000000000
    -3=f7ddc8d932def2f393dfc1719252e61b1561afeed76d32044ae0cd793e380bc6
    -2=904f563968898c7569794e19bcd9304d46ca5c0b9f09c792081bdb8ec9c04c92

(2) I tried to install this build from macOS Monterey to an iOS 15 device and received the following error message for (The code signature version is no longer supported):

default	11:41:15.649815-0700	installd	0x16be2b000 -[MIInstaller performInstallationWithError:]: Installing <MIInstallableBundle ID=com.dts.MyTestApp.app-mattsignature; Version=1, ShortVersion=1.0>
default	11:41:15.649936-0700	installd	com.dts.MyTestApp-mattsignature:7:5:1:1:Start : Install (New)
default	11:41:15.720695-0700	installd	0x16be2b000 +[MICodeSigningVerifier _validateSignatureAndCopyInfoForURL:withOptions:error:]: 74: Failed to verify code signature of /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.pEXcje/extracted/Payload/MyTestApp.app : 0xe8008029 (The code signature version is no longer supported.)

(3) From here I resigned the MyTestApp.app on macOS Catalina with the --generate-entitlement-der flag:

$ codesign -s "DTS Matt Eaton (xxxxxxxxxx)" -f --preserve-metadata --generate-entitlement-der MyTestApp.app
Warning: default usage of --preserve-metadata implies "resource-rules" (deprecated in Mac OS X >= 10.10)!
MyTestApp.app: replacing existing signature

(4) From here I checked the Page size on the resigned app and saw that -7 is now available.

$ codesign -dvvvvv MyTestApp.app
Executable=/path/to/MyTestApp.app/MyTestApp
Identifier=com.dts.MyTestApp-mattsignature
...
Page size=4096
    -7=915c86eb5653ea2122901068e9735fd3c98d7622ab9aefe478e3c358a9a8ffeb
    -6=0000000000000000000000000000000000000000000000000000000000000000
    -5=7c741a970873bb7f6a05c1ad5b9425f4b5b1ac86645b2cb8c842a57f51818eb5
    -4=0000000000000000000000000000000000000000000000000000000000000000
    -3=6f00b3831b7c1a3ba39fbfe9fc3a4f2267816bbd2c8d77e1aac17fb1726cf9f3
    -2=904f563968898c7569794e19bcd9304d46ca5c0b9f09c792081bdb8ec9c04c92
CDHash=2a38a2b310e7a46c8e88a6f82f50fa31138fd894

(5) From here, I needed to zip up my Payload/MyTestApp.app directory again and then rename it with an ipa extension. (6) After that I was able to install and run MyTestApp.app properly on an iOS 15 device from macOS Monterey.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

I'm still having the same issue even after following all the solutions listed in this thread. After more investigations, I found out that provisioning profile that has <key>DER-Encoded-Profile</key> fails to install on iOS 15 beta.

XCode beta seems to auto-generate the provisioning profile without this key. However, downloading the provisioning profile from Apple's developer portal has this key and does not let me side load the app.

@thiemos

I haven't come across the DER entitlement before. What is about?

I do not have an official answer here, but DER is short fro Distinguished Encoding Rules and is a standard by which ASN.1 structures are transferred. ASN.1 is a standard by which data can be encoded and decoded no matter which platform is being used. ASN.1 in this specific case applies to data encoding rules for cryptographic signatures, and I am assuming for code signing applies to how the entitlements are encoded.

Regarding:

Can we expect this issue to be fixed in the final release of iOS15?

What item are you referring to here that needs to be fixed?

Regarding:

Or do we have to resign all apps and add the entitlement to make the apps work with iOS15?

If you are signing on macOS Big Sur or macOS Monterey then you should be able to sign your apps and install them on an iOS 15 device. At least I have not had an issue doing so, please let me know if you see an issue here.

As for macOS Mojave and Catalina, you will at the moment need to re-sign your iOS app to use the new --generate-entitlement-der argument as I have demonstrated above. I did attempt to test this in Xcode but was not able to make this work. I do have a bug open for this (r. 80574083)

Regarding:

If you have a iOS14 device with some apps already installed with the correct signature version but without the entitlement, will they still work after the update to iOS15?

See my above comment about signing on macOS Big Sur or macOS Monterey.

@haroldt

I'm still having the same issue even after following all the solutions listed in this thread. After more investigations, I found out that provisioning profile that has DER-Encoded-Profile fails to install on iOS 15 beta. XCode beta seems to auto-generate the provisioning profile without this key. However, downloading the provisioning profile from Apple's developer portal has this key and does not let me side load the app.

If you create an Ad-Hoc signed app from macOS Big Sur or macOS Monterey then are you able to side-load onto an iOS 15 device?

If you are attempting to re-sign on Catalina can you walk me through the steps you took here?

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

@meaton

I've made a bit of progress implementing the workaround of setting --generate-entitlement-der during our archive builds on Catalina.

When we perform an archive we also pass -archivePath <path to .xcarchive> and then do an -exportArchive in a subsequent step, and from there we archive the resultant enterprise-signed IPAs for use in development and QA.

I set OTHER_CODE_SIGN_FLAGS=--generate-entitlement-der in both the xcodebuild archive invocation and then the subsequent -exportArchive. The resultant xcarchive produces a .app within Products that does contain 6 and 7. However, the .ipa from the -exportArchive step does not, so I can't install the exported IPA as-is.

I am able to manually create an IPA wrapper for the built product originating from the .xcarchive by copying this .app into a new Payload directory and zip-ing it into a file with a .ipa extension. Installing this manually-cobbled IPA onto an iOS 15 device seems to work fine.

I see from looking at IDEDistributionPipeline.log from the -exportArchive step that there is still a lot of logic to the -exportArchive step. I see when it gets to Processing step: IDEDistributionCodesignStep:

it eventually gets to:

2021-07-20 16:23:18 +0000 [MT] Running /usr/bin/codesign '-vvv' '--force' '--sign' '<scrubbed>' '--entitlements' '/var/folders/6f/tcr7g_ms167blz6vbzctyrth0000gn/T/XcodeDistPipeline.~~~ubOEou/entitlements~~~QfGC1G' '--preserve-metadata=identifier,flags,runtime' '/var/folders/6f/tcr7g_ms167blz6vbzctyrth0000gn/T/XcodeDistPipeline.~~~ubOEou/Root/Payload/<scrubbed>.app'

..so I can see it has re-signed the top-level .app bundle without the additional flags we had specified from the original archive build.

Is there some other way we can tell the archive export stage about the --generate-entitlement-der flag? For example, defining it in the export options?

Given there is so much additional logic I see in the IDEDistributionPipeline.log steps I'm hesitant to try and do our own IPA repackaging by simply copying the .app out of the xcarchive and into an IPA zipfile, given that all of this is stopgap work for us until we upgrade to Big Sur. We're still blocked on upgrading all of our release build machines to Big Sur due to FB9363703 and FB9006786.

@timothy-sutton

Thank you for the update here.

Regarding:

However, the .ipa from the -exportArchive step does not, so I can't install the exported IPA as-is.

I opened a bug (r. 80574083) for a similar workflow using --generate-entitlement-der directly in Xcode with the OTHER_CODE_SIGN_FLAGS set in the build setting.

Regarding:

Is there some other way we can tell the archive export stage about the --generate-entitlement-der flag? For example, defining it in the export options?

The only other way that I can see to workaround this at the moment would be to complete the export and then open the IPA and perform the re-sign on the .app after the export. So, it would almost be like a 3rd step in your build process, i.e., archive, export, resign.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

for example I'm not sure whether this process is any different if the .app contains app extension but now I see from CI logs that our "real" apps need our usual (42-ish) number of codesign invocations

Yeah, my re-sign example in this thread is very basic because I am signing a flat iOS app without any framework dependencies or app extensions. During the re-sign process these extensions and dependencies would also have to be taken into account. Lastly, make sure there are not any static frameworks embedded in the application as these cannot take on the new code signature format.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Hello, did you get it fixed? I have the same problem and none of the solutions here or other places help. The project refuses to install on physical device but works in on simulators. This started happening yesterday after updating to Big Sur to 11.5.1. My device was using iOS14.5 for some times and there were no problem installing. I'm not sure if updating the OS automatically update Xcode since I don't remember what version I was using, but the problem occurs instantly after the OS update and mac restarts. Any advice from anyone is appreciated.

Some info:

• physical device now uses iOS14.7
• Xcode version is 12.5.1
• project was first created in 2019
• frameworks are installed through Carthage, they are xcframework files and are not embed
• I use 2 simulators with iOS12.3 and iOS14.4, they currently work fine
• Unlike post owner's app, this project is not an enterprise app

What I tried:

• Tried to resign code as instructed by meaton, -2 to -7 all have values
• Cleared derived data, cleared Carthage cache, clean build, restarted phone and mac, rebuild frameworks

@jpudding

Since this is an iOS 14.7 installation issue I suspect you may be seeing a slightly different problem. Can you confirm a few things for me:

Create a distribution Ad-Hoc build of your app and try to install it on your device. What is the installation failure message you see in the Console.app for the device? Is it the same message being recorded on this thread, i.e., "The code signature version is no longer supported.?"

If it is this same message then you may want to also checkout the signature on those embedded frameworks, and each extension in your app bundle. You can check these executables with the same procedure I described above, using this command:

$ codesign -dvvvvv MyTestApp.app/Contents/path/to/framework/executable
$ codesign -dvvvvv MyTestApp.app/Contents/path/to/extension/executable

However, this time make sure you are looking at the paths to each executable embedded in your bundle. For example, any framework or extension executables. If you see any of these executables with an old signature format then you will have to re-sign them also.

If this is not the same message then I suspect you have something else going on here and you can do one of two things; you could create a new post describing your problem on the Code-Signing tag, or you could open a TSI and one of my colleagues will take a deeper look at this situation.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Hello Matt, thank you for your quick reply and detailed instruction.

No problem at all.

Regarding:

I followed it and found out which framework was causing the problem. Now the app can be installed normally.

Yep, this has been known to be a common issue for anyone running into re-signing or old code signature format issues. For anyone reading this, please make sure to check all of the executables inside your main app bundle to see if they also need to be re-signed as this may be causing problems as well.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

@meaton

I'm still facing issue on watch app eventhough i'm on bigsur after re-signing also it still shows CodeDirectory v=20400 so in which case this will change to 20500 ?

Also even i'm on bigsur so if i try to export archive and install it still fails so when i looked into pagesize flag -7 is missing, is it the expected issue even on bigsur after exporting archive?

ps: After export iOSApp.app seems to be contained 7, but extension like watchApp missing 7 but before export it seems to be fine any idea?

@kumar.pavan

Also even i'm on bigsur so if i try to export archive and install it still fails so when i looked into pagesize flag -7 is missing, is it the expected issue even on bigsur after exporting archive? ps: After export iOSApp.app seems to be contained 7, but extension like watchApp missing 7 but before export it seems to be fine any idea?

Thanks for reporting. I am assuming it is, but make sure that your embedded watchOS app is also signed during the iOS export process in Big Sur. After the export, check the hash slot entitlement for -7 on the watchOS executable and if it's missing you will need to re-sign everything. The same goes for other extension executables in your app bundle.

NOTE, do not try to just resign the watchOS embedded executable only. This could invalidate the outer signature on your iOS app. If you need to, re-sign the embedded executable for the watchOS app and then re-sign the outer iOS app to make sure the signatures are all valid.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

@meaton

Thanks for reporting. I am assuming it is, but make sure that your embedded watchOS app is also signed during the iOS export process in Big Sur.

Yes during export process it's resigning watchapp but still it's missing -7 and -6 flags on bigsur i believe this must be Xcode issue will it resolve before final release of iOS15?

Just curios to know is there way to specify --generate-entitlement-der during exportArchive command else resigning app and extensions is like tedious process since we have many nested extensions internally?

@kumar.pavan

Yes during export process it's resigning watchapp but still it's missing -7 and -6 flags on bigsur i believe this must be Xcode issue will it resolve before final release of iOS15?

Not sure, but you are signing with the latest version of Xcode on Big Sur, and you can confirm that the DER hash slot is not available then you should open a bug report. You will need to re-sign in this case to workaround this.

Regarding:

Just curios to know is there way to specify --generate-entitlement-der during exportArchive command else resigning app and extensions is like tedious process since we have many nested extensions internally?

There is not a way that I know of to integrate the command for --generate-entitlement-der into the xcodebuild process because xcodebuild is handling the codesign commands for you. You could try to add this argument to your build settings, but in my tests this did not work as expected. You would need to re-sign after the export.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

As a general point of advice for anyone that may be reviewing this thread I did want to point out an additional debugging technique if you are re-signing, your signature contains the DER hash slot for (-7), but you are still experiencing issues. Check to make sure that your Provisioning profile complies with the new Provisioning profile updates described here.

Please make sure that the new Provisioning profile that you are re-signing with contains the key for DER-Encoded-Profile. It will look something like this:

<key>DER-Encoded-Profile</key>
<data>MIIOUwYJKoZIhvcNAQcCoIIORDCCDkACAQExD....</data>

You can check this in your Provisioning profile by converting your profile to a plist and looking for this key:

$ security cms -D -i embedded.mobileprovision -o Profile_Dist_iOS.plist
$ /usr/libexec/PlistBuddy -c "Print :DER-Encoded-Profile:" Profile_Dist_iOS.plist
..... lots of data .....

If your Provisioning Profile does not contain this key then you will need to go to the Developer Portal and create a new provisioning profile and then this profile should contain this updated key.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com