Fundamental:
The public key can verify that the signature of the private key is correct.
Apple has a private key A in the background , and iOS has a built-in public key A , which corresponds to the private key A. (A: stands for Apple , that is, Apple )
A pair of public key L and private key L are generated locally , (L: stands for Local, that is, local), the private key L is stored locally , the public key L (that is , the .certSigningRequest file) is transmitted to the apple background , and a certificate is generated after signing . Download to local . The function of the certificate is to verify the signature of the private key. In addition, XCode will also find the corresponding private key through the certificate when signing the app. A certificate corresponds to a private key (because a certificate is a public key and can only correspond to a private key) .
ps : In development, the public key corresponds to the certificate file from the developer's website, and the private key corresponds to the .p12 file
Provision Profile：
The description file, which contains the certificate and related information of the app (such as entitlements, bundle id , list of supported device ids, etc., only the content related to the signature is discussed here ), an embedded .mobileprovison file will be embedded when the app is packaged , this file will be signed by apple with private key A.
So the verification steps for an app to be installed on the iPhone are as follows:
iOS first verifies the correctness of the embedded.mobileprovison file through the built-in public key A. After the verification is passed, the public key L (that is, the certificate certificate) is taken out from the embedded.mobileprovison file to verify whether the app is signed by the private key L. Of course, a The embedded.mobileprovison file may contain multiple certificates. It is presumed that the verification logic at this time is that as long as the app is verified by one of the certificates (that is, as long as it is signed by the private key corresponding to one of the certificates), the app is considered to be signed correctly, and another install At the same time, the system will also synchronously verify other information in embedded.mobileprovison, such as the entitlement file. The basic principle is to verify whether the entitlement permission content after the app is signed is consistent with the entitlement file contained in embedded.mobileprovison (of course, including the verification of the bundle id, only However, only the bundle id in the entitlement permission content is verified here, and the bundle id in the info .plist file is not verified. The iOS app signature will include the entitlement file content, that is, you can specify which permissions this app supports when signing ), so we are in When re-signing the app, you need to re-specify the entitlement permission to make it consistent with the content of the entitlement file in the embedded.mobileprovison file.
Common problems encountered in development: (generally may be encountered in the process of manual signing)
Generally speaking, the embedded.mobileprovision file in development is downloaded from the developer's website, so the correctness of this file is generally no problem, so if an app cannot be installed on the iPhone, a possible reason That is, the certificate (certificate , public key ) corresponding to the private key that signed the app is not in the description file. The solution at this time is to regenerate the description file to include the corresponding certificate (certificate). Another reason related to the signature may be that the certificate (certificate) has expired (meaning that the public key has expired, because the private key corresponds to one of them, so the private key has also expired and needs to be regenerated).
Another common reason is that the entitlement content after the app is signed is inconsistent with the entitlement content in the embedded.mobileprovision file. In this case, the entitlement content of the app signature needs to be modified. The codesign --entitlements parameter is to specify what the app supports when signing. Permissions (ps : To see which permissions are supported before the app is re-signed, use the command codesign -d --entitlements :- Payload/GradleTest.app ).
example:
codesign -f -s "iPhone Distribution: ABC Information Technology Co., Ltd." --entitlements Entitlements.plist Payload/$1.app