ios签名:平常具体的操作和概念


如果别的Mac也要编译签名这个App,怎么办?答案是把私钥导出给其他Mac使用,在keychain里面导出私钥,就会存成.p12文件,其他Mac打开后就导入私钥。 第4步都是在苹果网站上操作,配置……。 Provisioning Profile:包含了 证书/Entitlements 等数据,并由苹果后台私钥签名的数据包。 其他发布方式 前面以开发包为例子说了签名和验证的流程,另外两种方式In-House企业签名和AD……-Hoc流程也是差不多的,只是企业签名不限制安装的设备数,另外需要用户在iOS系统设置上手动点击信任这个企业才能通过验证。 而AppStore的签名验证方式有些不一样,前面我们说到最简单的签名方式,苹果在……,7,0,0,我们平常具体的操作和概念是这样的:

第1步对应的是keychain里的“从证书颁发机构请求证书”,这里就本地生成了一对公私钥,保存的CertificateSigningRequest就是公钥,私钥保存在本地电脑里。

第2步苹果自己处理,我们不用管。

第3步对应把CertificateSigningRequest传到苹果后台生成证书,并下载到本地。这时本地有两个证书,一个是第1步生成的,一个是这里下载回来的,keychain会把这两个证书关联起来,因为它们的公私钥是对应的,在Xcode选择下载回来的证书的时,实际上会找到keychain里面对应的私钥去签名。这里私钥只有生成它的这台Mac才有,如果别的Mac也要编译签名这个App,怎么办?答案是把私钥导出给其他Mac使用,在keychain里面导出私钥,就会存成.p12文件,其他Mac打开后就导入私钥。

第4步都是在苹果网站上操作,配置AppID、权限、设备等,最后下载Provisioning Profile文件。

第5步Xcode会通过第3步下载回来的证书(存着本地公钥),在本地找到对应的私钥(第1步生成的),用本地私钥去签名App,并把Provisioning Profile文件命名为embedded.mobileprovision一起打包进去。这里对App的签名数据保存分为两部分,Mach-O可执行文件会把签名直接写入这个文件里,其他资源文件则会保存在_CodeSignature目录下。

第6、7步的打包和验证都是 Xcode 和 iOS 系统自动做的事。

这里再总结一下这些概念:

证书:内容是公钥或私钥,由其他机构对其签名组成的数据包。

Entitlements:包含了App权限开关列表。

CertificateSigningRequest:本地公钥。

.p12:本地私钥,可以导入到其他电脑。

Provisioning Profile:包含了 证书/Entitlements 等数据,并由苹果后台私钥签名的数据包。

其他发布方式

前面以开发包为例子说了签名和验证的流程,另外两种方式In-House企业签名和AD-Hoc流程也是差不多的,只是企业签名不限制安装的设备数,另外需要用户在iOS系统设置上手动点击信任这个企业才能通过验证。

而AppStore的签名验证方式有些不一样,前面我们说到最简单的签名方式,苹果在后台直接用私钥签名App就可以了,实际上苹果确实是这样做的,如果去下载一个AppStore的安装包,会发现它里面是没有embedded.mobileprovision文件的,也就是它安装和启动的流程是不依赖这个文件,验证流程也就跟上述几种类型不一样了。

据猜测,因为上传到AppStore的包苹果会重新对内容加密,原来的本地私钥签名就没有用了,需要重新签名,从AppStore下载的包苹果也并不打算控制它的有效期,不需要内置一个embedded.mobileprovision去做校验,直接在苹果用后台的私钥重新签名,iOS安装时用本地公钥验证App签名就可以了。

那为什么发布AppStore的包还是要跟开发版一样搞各种证书和Provisioning Profile?猜测因为苹果想做统一管理,Provisioning Profile里包含一些权限控制,AppID 的检验等,苹果不想在上传AppStore包时重新用另一种协议做一遍这些验证,就不如统一把这部分放在Provisioning Profile里,上传AppStore时只要用同样的流程验证这个Provisioning Profile是否合法就可以了。

所以 App 上传到AppStore后,就跟你的证书 / Provisioning Profile都没有关系了,无论他们是否过期或被废除,都不会影响AppStore上的安装包。

到这里 iOS 签名机制的原理和主流程大致说完了,希望能对理解苹果签名和排查日常签名问题有所帮助。

 

企业签名QQ:281442504

分享到