AutomaticallyManageSigning(AMS)

1.Xcode自动生成的证书是简化版(权限存在次数限制)
2.AutomaticallyManageSigning(AMS)自动管理签名(管理账号开发者中心的签名证书(通过自构默认配置文件))
3.开发者中心的签名证书采用签名自动管理过程：
1.Xcode会在本地电脑端的本地钥匙串中寻找开发team团队进行真机调试/发布所需签名证书。若从本地钥匙串中顺利查找到相应的签名证书则直接加载使用。若本地钥匙串中无法查找到相应的签名证书则进入账号开发者中心寻找相关签名证书，若开发者中心签名证书查找失败则触发中心平台上的签名证书构建机制自动构建出相对应的签名证书并下载打开存入到本地端钥匙串中供使用。
4.通过签名证书自动管理机制(AMS)自动构建出的开发者签名证书默认名称携带有电脑名称。
处理方式：
(1)前往开发者中心证书管理页面下载本地项目工程所需证书导入本地端钥匙串链内。
(2)直接采取revoke(废除)方式原有的签名证书将被覆盖失效同时profile配置文件若只包含1个失效证书则对应的配置文件也失效。自动生成1个新的签名证书及相应的配置文件。
5.配置provisioning供给：
供给配置文件profile缓存在本地端路径下
/用户/xxx/资源库/MobileDevice/ProvisioningProfiles
若顺利查找到对应的profile文件则直接使用；若路径查找失败则构建1个新的provisioningprofile文件配置工程项目且缓存在如上路径下。

发布签名证书采用自动管理流程：

1.手机主页内App应用本质为IPA压缩包解析内容布入环境平台。
2.通过iTools工具将IPA压缩包解析布入手机平台环境内。
3.Archive归档过程与证书的类型无关。
4.当我们导出IPA压缩包或上传IPA压缩包至AppStore云库时需要发布签名证书。
5.Xcode自动加载发布签名证书流程：Xcode会从本地电脑端的本地钥匙串中查找苹果账号对应的发布签名证书，若顺利查找到则引入项目工程中加载进入。若未能从本地钥匙串中顺利查找到则前往开发者中心云平台寻找对应的发布签名证书若依旧查找失败则自动构建出1个全新的发布签名证书并下载数据至本地钥匙串中加载进入。

方法一：去开发者中心下载（前提是发布签名证书是本机生成(知道私钥)，如果是其他机器生成(不知私钥)，下载也没用，只能去其他人的电脑端钥匙串中导出p12配置文件）
方法二：选择reset，然后try again就可以。但reset慎重，reset有可能会导致Provisioning无效导致别人端的签名证书无效。
下一步：
Xcode正确加载发布签名证书后，根据appid去profiles下载Provisioning，有则下载，无则自动创建一个(绑定当前app id和发布签名证书)并下载，在这一步并不会检查Provisioning有无效。
结束：
此加载发布签名证书和Provisioning配置描述文件的加载过程完成。
工程其他配置的问题导致接下来出现错误，比如引入多个工程或者pod有可能产生的问题。
——————————————————————————
证书和秘钥的关系
正确的开发证书都是有相应的秘钥而且使用的是RSA加密算法。在开发者中心新建证书之前是要先在本地电脑钥匙串证书助理内先新建一个CA证书权限请求文件以请求获取权限证书，再用权限证书去申请开发或发布签名证书。（https://baike.baidu.com/item/ca证书/10028741?fr=aladdin）CA权限证书文件(证书的证书)
用CA申请权限证书文件去申请开发、发布签名证书以验证开发、发布签名证书是否有效。不同电脑revoke、reset前后的签名证书不一样，同一台电脑revoke、reset前后的签名证书也是不一样。
——————————————————————————
导入其他电脑生成的开发签名证书（缺少秘钥）不能使用。

Xcode申请的签名证书（开发发布签名、测试真机签名证书）都跟电脑的秘钥绑定(秘钥存储于电脑本地)，想用签名证书得先有秘钥文件配对。想用其他电脑的签名证书必须将对应的秘钥p12文件导出。

关于Provisioning：
APPID、证书、device、Provisioning的关系：
Provisioning配置描述文件最终打包进入ipa压缩包(相关数据存储在Provisioning配置描述文件内(Provisioning文件包含appid/device/singing))。appid/device/singing证书-》Provisioning-〉成功打包或上传app。

为什么说revoke和reset会导致Provisioning错误呢？
Provisioning配置描述文件会无效会有两种情况，要么过期了，要么不含有有效签名证书了，在开发者中心Provisioning Profiles页面会显示invalid无效。
假如开发者中心原本空白，当在macA打包上传时，开发者中心查找失败后会为该开发者创建关联macA的开发签名证书和发布签名证书，并且自动生成了appid和Provisioning，此时的Provisioning就是关联了macA的开发签名证书和发布签名证书。例如

macA就成功打包上传。后期需要在macB打包上传，因为macB是没有发布签名证书的，自然会提示reset，如果macB进行了reset，那么Xcode自动为macB创建B发布签名证书会覆盖macA之前签名证书，原a证书没了，Provisioning原绑定的Certificates就会变成0 total，从而变成invalid，无效了。但macB继续打包上传，在Xcode从开发者中心信息中寻找Provisioning时根据APPID查找，因为含有同样的AP ID的Provisioning已经存在，所以Xcode不会再为开发者重新创建一个新Provisioning配置描述文件，而是直接加载已存在的provisioning文件而这个文件恰好是无效！
——————————————————————————————
在开发者中心APPIDs有Wildcard AppID概念，使用通配符的AppID可通配一系列符合的APPID；如定义Wildcard App ID：com.，这个AppID可以统配所有以com.开头的bundle identifier项目，xcode不会生成相同名字的AppID。在第一次使用com. App ID时，Xcode会为com. App ID新建Provisioning配置描述文件，Provisioning对应AppID是com.，再有新项目bundle identifier以com.开头，Xcode不会再创建新Provisioning文件根据AppID访问已存在的Provisioning配置描述文件进行测试发布，就是所有公用com. APPID的应用共用一个Provisioning配置描述文件。

如果开发者中心已经有与新项目的bundle identifier标识相同的APP ID标识符则不创建新的APP ID，如果没有与新项目的bundle identifier标识相同的APP ID标识符则会看有没有适合的Wildcard App ID可适用，如果有也不创建新的APP ID标识符，如果依旧没有则最后创建新的与项目bundle identifier标识符相同ID的App ID标识符(对应新的Provisioning配置描述文件)。