开发者证书

最近学习了一下iOS代码签名机制 ,这里做个笔记记录，整理思路，加深理解。
想了解更多iOS签名相关，强烈推荐去看看原文，写的太棒了。原文出处 深度长文：细说iOS代码签名 。

前言

众所周知，iOS设备并不能像 Android 那样任意地安装 app ，app 必须被 Apple 签名之后才能安装到设备上。然而，开发者在开发App的时候，需要频繁地修改代码并安装到设备上进行测试，不可能每次都先上传给Apple进行签名，因此需要一种不需要苹果签名就可以运行的机制。这里就引入了开发者证书及相应的机制。

这个机制的实现方式是：

• 开发者自己持有一套密钥和证书，可以自行对app进行签名
• 由Apple对开发者的身份进行“背书”，让设备间能够接信任开发者自行签名的app，这个“背书”的方式就是后面会提到的Provisioning Profile

生成CSR文件(Certificate Signing Request)

在Keychain菜单栏选择”从证书颁发机构请求证书…”

request.png request_2.png

这个操作会产生一个名为CertificateSigningRequest.certSigningRequest 的签名请求文件，在生成这个文件之前其实Keychain已经自动生成了一对公、私钥。

password.png

CSR文件的内容其实就是个人信息、公钥，以及自签名(使用自己的私钥进行签名)， 可通过openssl命令查看其内容：

$ openssl req -in ~/Desktop/CertificateSigningRequest.certSigningRequest -text -noout
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: emailAddress=test@qq.com, CN=JustTest, C=CN
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:bd:8c:c0:27:9b:17:73:ef:bd:6d:ea:b4:ad:aa:
                    xx:xx:xx:xx:xx:xx:xx:...
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    Signature Algorithm: sha256WithRSAEncryption
         33:82:f9:8a:fe:8a:bd:08:52:04:9f:a2:d0:0e:dd:92:ee:62:
         xx:xx:xx:xx:xx:xx:xx:...

提交给Apple进行签名

在苹果开发者网站，将CSR提交给Apple进行签名，Apple会返回一个签好名的证书文件，后缀名为cer。这个流程对应上一章中证书请求流程。

双击即可将其导入到 Keychain 中，Keychain 会自动把它之前创建CSR时自动生成的密钥归为一组。无论是在证书列表中查看还是在密钥列表中查看，都能看到与之匹配的另一半。

可以从证书中得到几个关键信息：

1. 证书的所有者，这部分信息并非由我们自行指定，而是签发者Apple根据我们的Apple ID账号信息自动生成
2. 证书的签发者，即前文所述的CA
3. 证书的公钥信息，与之前生成的密钥文件及CSR完全一致

现在应该可以理解证书和密钥的关系了，密钥中保存了私钥和公钥，私钥用于签名，而证书里面有且只有公钥，并且是被第三方 CA “认证” 过，用于解密和校验。

这里有一点需要注意：苹果返给我们的证书文件 xxx.cer ，里面只有公钥相关的信息，是用来解密和校验的。所以单纯把 xxx.cer 文件发送给其他开发同学，没有对应的私钥，是无法进行签名的，使用真机调试时会报证书错误等提示。这里需要将私钥和证书一起导出为 p12 文件。

一般我们说使用证书签名，实际上是使用与证书所匹配的私钥进行签名，证书只是作为签名数据的一部分被嵌入到签名结构中。

打开证书可以看到这个证书的签发者是Apple Worldwide Developer Relations Certification Authority，在Keychain中搜索这个名字， 可以看到它的证书详情，如下图：

cer.png

我们会发现，它的类型是中级证书颁发机构(中级CA)，它也包含签名，并且是由另外一个叫做Apple Root CA的根证书颁发机构(根CA)进行签发的，这样就形成了一条证书链。而继续查看Apple Root CA的证书，会发现它是自签名的，因为它会被内置在设备中，设备无条件信任它，也就不需要其他的机构为其背书了。

这样的证书链机制可以简化根证书颁发机构的工作，同时提升证书管理的安全性。将颁发底层证书的工作分散给多个中级证书颁发机构进行处理，根证书颁发机构只需要对下一级机构的证书进行管理和签发，降低根证书颁发机构私钥的使用频率，也就降低了私钥泄露的风险。中级证书颁发机构各司其职，即使出现私钥泄露这样的重大安全事故，也不至于波及整个证书网络。

总结

到这里，我们已经实现了上述机制中的第一点：

• 开发者自己持有一套密钥和证书，可以自行对app进行签名

因为我们的证书是经过苹果CA认证过的，手机上需要解密校验签名的时候，可以通过证书中的CA信息认证公钥是否正确。进一步通过认证后的公钥解密校验签名，从而确定代码及相应资源的完整性等。用通俗的话说，证书确保了，开发者开发的东西确实都是开发者的东西，没有被第三者篡改。

如果我们的app是提交到 App Store ，会有苹果审核，确保你的 app 是安全的，没有包含对应的恶意代码等等。同时 App Store 也会使用苹果的私钥对我们的 app 进行重签名。当设备需要安装 app 时，校验签名，一看证书是苹果自己的证书，且校验没问题，直接正常安装使用。

但是，当我们在开发过程中，使用的是我们自己证书进行的签名。设备在安装 app 时，校验签名，一看证书是一个开发者证书。设备此时不知道，你这个开发者本身的身份如何，你开发的 app 也没有经过审核，会不会有安全问题、会不会窃取设备上敏感信息等。所以设备不能信任你的 app，也就不能正常安装使用。

未来解决上述问题，就用到了 Provisioning Profile 文件，也即上述机制中的第二点：

• 由Apple对开发者的身份进行“背书”，让设备间能够接信任开发者自行签名的app，这个“背书”的方式就是后面会提到的Provisioning Profile

总结一下：

1. 证书保证开发者开发的 app 没有被篡改。即证书保证 app。
2. Provisioning Profile 保证开发者本身的身份，让设备信任开发者签名的 app 。即 Provisioning Profile 保证开发者。