Not able to install enterprise build in iOS 15 beta version

Do I need to take any action to resolve this issue?

Yes, if you are distributing an app through an Enterprise Distribution method then you need to take a look at the information on this thread to make sure you are ready for the changes to the signature requirements coming in iOS 15.

Starting in iOS 15, iPadOS 15, tvOS 15, and watchOS 8 the system requires the new, more secure, signature format that uses DER to embed entitlements into your app's signature. For more on DER, or Distinguished Encoding Rules, see DER discussed in RFC 5280 (https://datatracker.ietf.org/doc/html/rfc5280#section-4.1) for Basic Certificate Fields.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Matt, can you clarify? You wrote "Starting in iOS 15, iPadOS 15, tvOS 15, and watchOS 8 the system requires the new, more secure, signature format that uses DER to embed entitlements into your app's signature." However https://help.apple.com/developer-account/#/dev2ab310a57 says "In iOS, iPadOS, and tvOS 15 or later, some entitlements without “com.apple.developer“ in the entitlement key may require the DER-encoded version to be included in the provisioning profile" -- which is not the same thing.

The official docs are too vague: some entitlements ... may require? We need a complete list of the new requirements, so someone can inspect a given Provisioning Profile to determine compatibility with iOS 15, without having to test an install. My company supports customers who sometimes have literally 100's of in-house apps, and asking them to test re-installing each one -- with only a few weeks before iOS 15 drops -- is not feasible.

Also, earlier you had mentioned official documentation was still forthcoming. Is the help.apple.com link above what we were waiting for, or is there something else we can refer our customers to? Referring them to a developer forum thread seems a bit sketchy.

@c l i f f

Matt, can you clarify? You wrote "Starting in iOS 15, iPadOS 15, tvOS 15, and watchOS 8 the system requires the new, more secure, signature format that uses DER to embed entitlements into your app's signature." However https://help.apple.com/developer-account/#/dev2ab310a57 says "In iOS, iPadOS, and tvOS 15 or later, some entitlements without “com.apple.developer“ in the entitlement key may require the DER-encoded version to be included in the provisioning profile" -- which is not the same thing.

You are correct, these are not the same thing. There are two requirements being outlined here. The first requirement that I was speaking of is regarding, "the system requires the new, more secure, signature format that uses DER to embed entitlements into your app's signature," and this is a new DER hash slot that is added to the actual signature of your app during code signing. This new DER hash slot is identified by the addition of -7 in the code signature:

$ 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

This is done when re-signing using the flag for --generate-entitlement-der:

$ 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

Now, you should not need to add this new DER hash slot to your signature on Big Sur or Monterey, these versions of macOS should do the right thing.

The link for the Provisioning profile updates means that if your app's signature has the DER hash slot that I described above, but you are still having issues installing the app on iOS 15 then there is a good chance you will need to generate a new provisioning profile to make sure it contains the key for:

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

Using a new profile with the DER-Encoded-Profile key and the new DER hash slot in your signature should put you in a good place.

Also, earlier you had mentioned official documentation was still forthcoming. Is the help.apple.com link above what we were waiting for, or is there something else we can refer our customers to? Referring them to a developer forum thread seems a bit sketchy.

The previous link that I post for the new Provisioning Profile updates was not the documentation updates that I had previously mentioned. There is a documentation effort still underway.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Any chance these requirements could be postponed to iOS 15.1+?

Right, as mentioned, I do not have control over this. My role here is to try and explain the situation, and help out where possibly, so that Development teams can assess how this impacts their situation as they prepare for the release of iOS 15.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

This worked for my enterprise app: 0) downloaded latest xCode

1. Created new provisioning profile, last one was 11/2020, so it was due anyway, reused the same certificate, just to make it easy.
2. Re-signed the app using the new provisioning profile and Matt’s information, codesign -s “certificate in keychain” etc, including the generate-entitlement-der flag
3. codesign-dvvvvv still shows version 20400, but the -7 and -6 are there now.
4. re-package and redeploy app.

@c l i f f

Matt, if any docs have been published yet, can you please share the link?

I am working on the documentation right now. I will share the link when I have it.

@Sabeeb1

Is it because of the Enterprise Prov Profile or Mac system versions used to sign and wrap the App?. Signed with Xcode 12.2 Intune Wrapped with mac system Version of MACOSX is 10.14.6 Version of XCode installed is Xcode 11.3.1 —

It could be both of these things causing you issues. Take a look through the previous posts on this thread, but you will need to make sure that you have the DER hash slot for (-7) in your signature as well as you will need to sign your app with a provisioning profile with the key for DER-Encoded-Profile. The simplest path here would be to generate a new provisioning profile and build and sign your app from macOS Big Sur using Xcode 12.5 or later.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

We have same issue with azure devops MacOS Catalina agent and build with Xcode 12.4 command line. The app builded and distributed with enterprise provisioning profile not worked for iOS 15 devices. Creating new provisioning profile for enterprise distribution and set OTHER_CODE_SIGN_FLAGS=--generate-entitlement-der not enought and got same error for iOS15. Finally, after we upgrated MacOS agent to BigSur and build with new provisioning profile, Xcode 12.4 than start working for iOS 15.

I've been following this thread, having a similar issue with our watch extension app that suddenly stopped working when our testers updated their iOS device to iOS 15 and watch to Watch OS 8.

So far I've recreated new provisioning profiles, verified that the codesign looks similar to what is suggested, seen that there's a DER-profile entry in the provisioning profile and also tried adding --generate-entitlement-der to build settings. Still, building the app for enterprise and installing it works on the iOS device but the embedded watch app does not. When you try to install it from the iOS watch.app, then it fails with "could not install the app at this time"

And the error we get is: 0x170053000 -[ACXInstallQueue _onQueue_deQueueNextOperation]_block_invoke_2: Failed to install app my.test.app (p = N, ui = Y) : Error Domain=ACXErrorDomain Code=17 "Got error 17 in install done from remote side (MI error ApplicationVerificationFailed ; Extended 0xe8008029 ; Desc Failed to verify code signature of /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.y3l1mI/extracted/Payload/Watch.app : 0xe8008029 (The code signature version is no longer supported.))" UserInfo={SourceFileLine=646, NSLocalizedDescription=Got error 17 in install done from remote side (MI error ApplicationVerificationFailed ; Extended 0xe8008029 ; Desc Failed to verify code signature of /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.y3l1mI/extracted/Payload/Watch.app : 0xe8008029 (The code signature version is no longer supported.)), FunctionName=-[ACXServerInstallOperation receivedDictionaryOrData:]}

Which indicates that the wrong provisioning profile is used but that doesn't seem to be the case.

Our page size: Page size=4096 -7=8d48d5d98df3b77ce25ac0b1ad03b1d4f50e23d7e377979e409b107324e18266 -6=0000000000000000000000000000000000000000000000000000000000000000 -5=4146cb67c2b6ce380836b0f27ac5760098b8a1af18608163202fd0a9d961d29d -4=0000000000000000000000000000000000000000000000000000000000000000 -3=e722d3b1b52761052da2177e2b81de694bec9d06dab31ad57519afca738d4e6e -2=4b1957d850c9cd59d4a501d12adc7db5ffc46fd3a68f0f7cb7665edc2be308dd

CodeDirectory v=20400

Like I mentioned, the iOS app works fine, it's only the watch extension app that doesn't launch.

I've tried to build the app on Xcode 12.5.1 and Xcode 13 and the machine is running Mac OS Big Sur.

I am not sure what else to try, any ideas?

I wanted to mention that the official documentation that I have been referring to on this thread did get published last night. Please refer to Using the Latest Code Signature Format for all of the officially documented details that have been discussed on this thread.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

@OliverTrifork

Still, building the app for enterprise and installing it works on the iOS device but the embedded watch app does not. When you try to install it from the iOS watch.app, then it fails with "could not install the app at this time"

This sounds like your watchOS bundled executable is not getting the DER entitlements for some reason. However, I would have expected that Xcode 12.5.1 an Xcode 13 would be doing the right thing here. Also regarding:

Our page size: Page size=4096 
-7=8d48d5d98df3b77ce25ac0b1ad03b1d4f50e23d7e377979e409b107324e18266 -6=0000000000000000000000000000000000000000000000000000000000000000 -5=4146cb67c2b6ce380836b0f27ac5760098b8a1af18608163202fd0a9d961d29d -4=0000000000000000000000000000000000000000000000000000000000000000 -3=e722d3b1b52761052da2177e2b81de694bec9d06dab31ad57519afca738d4e6e -2=4b1957d850c9cd59d4a501d12adc7db5ffc46fd3a68f0f7cb7665edc2be308dd

If the above is the hash slot output from the signature of your bundled watchOS executable then you should open a TSI so I can take a look at this situation in more detail. If the above is the hash slot output from the signature of your iOS app, then take a look at your watchOS app and confirm that -7 is there too. If not, then I suspect this is your problem and you will need to re-sign your app from the inside out.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

@meaton

I am facing exactly same issue which one @OliverTrifork faced. I can able to install my app in all iOS 15 devices but its not installed in watch OS 8.

I checked my app page size and CodeDirectory CodeDirectory **v=20400 **

page size is

**Page size=4096

    -7=06475d1765dfc11c70d05f2cc4b31d16c49442fc81b07fba2411a492fe696ea6

    -6=0000000000000000000000000000000000000000000000000000000000000000

    -5=627bc89b3daaaceea7274123e434b0b71eed2c30c3fdb42939bac462ac3c6650

    -4=0000000000000000000000000000000000000000000000000000000000000000

    -3=040742e532e2adff2af765f976ff83e64eabf3a9c05e907d130e6b1ee075ac3a

    -2=734bcba99334852efc4e73c0b65c680cb77c90e7640f9b8cee6aa10f4057dbd3**

Looks like valid signature.

The I tried to check page size of my watch app. I am getting below

**Page size=4096

    -5=3f24f91dba33893a034e70ead571e68df75ad6ec7411ad6222171b41c2ac7914

    -4=0000000000000000000000000000000000000000000000000000000000000000

    -3=a6cf7974ca6d700e37e621d978129162ccc94f2365909650ecd8af34255a2b5d

    -2=06b64bd8b69e0816298afe0398435dd6270b40de237bd2e406500acb5c48008b

CDHash=db4c46254c8c2748ae0ad3d96b1f528d63d849ad

Signature size=4821**

here -6 and -7 is missing, that means I needs to resign my app?

Even I tried to resign my app using below command line but I am getting error like 'No Such job'

% codesign -s "Your Codesign Identity" -f --preserve-metadata --generate-entitlement-der /path/to/MyApp.app

Below which one I tried.

% codesign -s "iPhone Distribution: My Company Name" -f --preserve-metadata --generate-entitlement-der /Users/Ponlee/Desktop/Payload/myapp.app

I want to know "Codesign Identity" is correct or not? I copied the name of distribution certificate stored in my keychain. is this correct? Please help to to fix this issue.

Thanks in advance.

Eagerly waiting for your positive and quick response.

Regards Ponlingam

@mjlee

Just to confirm - if I am on Catalina, to distribute ad hoc, after building an .ipa I will always need to go through the resign process?

Yes, Catalina did not have the machinery built into it to create a signature with the DER hashed entitlements. You will need to resign in this case. Follow the steps here.

@sponlingam

The I tried to check page size of my watch app. I am getting below **Page size=4096 -5=3f24f91dba33893a034e70ead571e68df75ad6ec7411ad6222171b41c2ac7914

here -6 and -7 is missing, that means I needs to resign my app?

This is common issue. What you will need to do is sign any framework or executable inside your app and then sign your main app last as to make sure you do not corrupt the outer signature. Signing everything inside out. Look at the following folder structure:

MyApp.ipa 
 Payload/
   MyApp.app/ (Need to be re-signed last)
      (Many files)
      _CodeSignature/
      Info.plist
      Frameworks/
        FrameworkA/ (Need to be re-signed 1st, CANNOT have entitlements)
        FrameworkB/ (Need to be re-signed 1st, CANNOT have entitlements)
      Watch/
        MyAppWatch (Need to be re-signed 1st, can have entitlements)
      Plugins/
        MyExtension.appex (Need to be re-signed 1st, can have entitlements)

If you have any frameworks, watchOS executables, or app extensions then you will need to sign them first and then your main app last.

Regarding:

I copied the name of distribution certificate stored in my keychain. is this correct?

Yes, this is the name of the signing identity in the Keychain. Moreover, it's actually the name of signing certificate that is visible when click on the item in Keychain Access.

So in my case it would be: iPhone Distribution: Apple Inc. - DTS Matt Eaton (XXXXXXXXXX)

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

@meaton I tried below command for code signing my app, But I got error " No Such job"

% codesign -s "iPhone Distribution: Dubai Electricity And Water Authority" -f --preserve-metadata --generate-entitlement-der /Users/Ponlee/Desktop/Payload/Myapp.app/Watch/WatchMyapp.app

-bash: fg: %: no such job

Please correct me if anything wrong on above command.

Please guide me how can I do sign. I am using macOS Big Sur Version 11.4 and Xcode 12.5.1

what are the ways to sign or resign app?

@sponlingam

-bash: fg: %: no such job Please correct me if anything wrong on above command.

It looks like you are trying to use zsh while in a Bash terminal. For example, if I am in a Bash terminal, denoted by $, and I hit % codesign or just % I will get:

myComputerName:~ muUser$ % codesign
-bash: fg: %: no such job

Switching to zsh should fix this issue, or you can copy the command without %. After you are in zsh you should be able to run the following command:

myComputerName:~ muUser $ zsh
myComputerName:~ muUser % codesign
Usage: codesign -s identity [-fv*] [-o flags] [-r reqs] [-i ident] path ... # sign
       codesign -v [-v*] [-R=<req string>|-R <req file path>] path|[+]pid ... # verify
       codesign -d [options] path ... # display contents
       codesign -h pid ... # display hosting paths

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

@meaton After taking a closer look, I see the same as @sponlingam, except we build on big sur, so I'd expect it to sign the watch properly, since it does it correctly for the iOS app. The watch and extension does not have 6-7 signature.. why though? is this an xcode bug? if so.. when can we expect to see this fixed?

This is what the watch signature looks like after archiving through both xcode 12.5.1 and xcode 13:

Page size=4096    
    -5=b913d5b0ef9ff48816f16a42342ab0037740a6153282266b7935458e6f55d9ab
    -4=0000000000000000000000000000000000000000000000000000000000000000
    -3=4f2a93c3945beb4b402e6bcad790b4b4c2cff641a50a758b6f3b37ca28a89e6a
    -2=516af77f9e299974d68307536ce805fdd9619a4c0cfd8c53d978f6b2bbbce81b   
Signature size=4821

After I run codesign manually though, it looks correct... so I suspect that Xcode is for some reason not adding all the relevant params to the watch and extension.

I even tried to force the same params in xcode and from what I can see, it does the same... Taken from the build log:

/usr/bin/codesign --force --sign <redacted> --preserve-metadata --generate-entitlement-der --preserve-metadata=identifier,entitlements /path/to/*.framework

Yet the signature is still wrong, however if I paste the exact same into terminal after archiving, then it seems to sign it properly.

I guess the next step would be to create a dummy project and see if I can reproduce, so I can make a proper TSI...