ACME

When I use codesign with deep option to sign my app and includeded frameworks, codesign verifies as good.codesign --verbose=4 --deep -s Acme, Inc. ${appFolder} my-usb-ev-tokencodesign --verify --verbose=4 ${appFolder}.........app/TSR.app/Contents/PlugIns/printsupport/libcocoaprintersupport.dylib--validated:/Users/edward3/Documents/projects/build-tsr-Desktop_Qt_5_5_0_clang_64bit-Release/tsr-app/TSR.app/Contents/PlugIns/printsupport/libcocoaprintersupport.dylib/Users/edward3/Documents/projects/build-tsr-Desktop_Qt_5_5_0_clang_64bit-Release/tsr-app/TSR.app: valid on disk/Users/edward3/Documents/projects/build-tsr-Desktop_Qt_5_5_0_clang_64bit-Release/tsr-app/TSR.app: satisfies its Designated Requirementspctl --verbose --***** --type execute -v TSR.app/TSR.app/: rejectedorigin=Acme, Inc.I am distributing my app in a dmg for distribution outside the Mac app store.Any tips or suggestions on how to properly codesign is much appreciated,-EdOS X 10.10.5XCode 6.4

When testing the iOS 9 Beta with MobileIron, we discovered a very problematic change in the device's behavior.When opening a Webclip, which refers to a websitre requesting a client certificate, there shows up a prompt to explicitly choose the client certificate to authenticate with.The website requests a client certificate issued by a specific certificate authority, for instance CN=CA1/O=Acme (this is part of the TLS handshake).The device does only have one client certificate issued by this CA (subprofile of a MDM profile).The prompt to choose appears, even as the list does only contain this single client certificate.In iOS 8 the device does automatically authenticate with the matching client certificate.Therefore this feature is widely used for securing and authenticating access to corporate websites, and in regards of MobileIron for the Enterprise AppStore.If this is no bug, and will remain in final iOS 9 release, we will be seeing immense user impact.Please provide us with clarity on whether this

We are a UK-based company who are in the process of renewing an iOS Distribution certificate using the Member Center. We are using 'Keychain Access' to generate a Certificate Signing Request, and submitting that CSR to the Member Center. We intend to use the resulting certificate to provision apps using 'Enterprise' distribution.The CSR generated by Keychain Access contains the 'GB' country code in the 'Subject' field of the CSR. However, the certificate we receive back from Member Center appears to have the 'Country' field set to 'US'. The same behaviour is observed with both 'Development' and 'Production' certificates. The machine used to generate the CSR is correctly configured in System Preferences to use the 'English' language and 'United Kingdom' region. We have replicated this issue on multiple machines.Since our old certificate (the one we're trying to renew) has the 'Country' code set to 'GB', we are concerned that the change of country code might affect our ability to provision apps correctly using