使用fastlane match自动和手动管理证书

之前总结写了关于 fastlane match 命令，当时只是说了一下match是什么，match的一些常用命令等。本次是写进一步了解match命令之后的总结。

上一次了解了match后，发现match有比较多的局限，主要问题在于证书和配置文件必须重新生成，不能使用原有的证书和配置文件，由于公司的证书和配置文件已经生成好了，并且不能随便销毁和删除，所以希望沿用现有的证书。通过查阅资料，还是找到了手动上传配置文件和证书的方法。

自动生成证书和配置文件

先来回顾下自动生成的方案：

1. 准备一个全新的远端仓库，用来存储生成的证书和配置文件

2. 在开发者网站上创建需要生成证书和配置文件的App ID（这一步不太确定是否必须做，使用高权限的开发者账号match可能会自动创建App ID）

3. 在主项目的工程目录下，初始化生成Matchfile文件，当然首先需要安装好fastlane

   fastlane match init
   复制代码

4. 在Matchfile中写入如下配置

   git_url("https://gitee.com/xxxx/xxxxxxx.git") //新建一个项目,将地址复制到这里
   type("development") # 默认match所同步的类型,可不管
   app_identifier("bundle Id")  #bundleId,若同工程下有多个,则用["bundleId1","bundleId2"]
   username("user@fastlane.tools")  #苹果开发者账号
   复制代码

5. 配置好后，在主项目工程目录下执行：

   fastlane match development --verbose
   复制代码

   运行这个命令过程中会让输入一个 passphrase 的密码，记住这个密码，在别的机器上同步证书和配置文件时会用到。运行过程中还会遇到很多问题，多百度基本可以搞定。

6. 成功生成证书和配置文件之后，使用命令在别的设备上安装证书：

   fastlane match development -- readonly --verbose
   复制代码

7. 如果需要更新证书，使用下面的命令会删除开发者账号下面的所有development证书，同时删除仓库中的证书，然后就可以从step 2开始重新生成证书和配置文件了。

   fastlane match nuke development --verbose
   复制代码

手动上传证书和配置文件

查阅了参考文档[1][2]后，发现match命令是结合了cert命令和sigh命令生成证书和配置文件的，生成过程中会判断仓库中是否有合适的证书和配置文件，我们就可以通过这个机制来手动构造类似match仓库的文件结构，并且手动生成好合适的证书和配合文件，放到相应的目录中，再推到仓库中。

1. 构造证书仓库的目录结构

   match的证书仓库目录结构为：

    

2. 找到现有证书的cert id

   使用 ruby 脚本读取开发者账号中的所有证书，找到对应证书的Cert id，ruby脚本为：

   require 'spaceship'
   
   Spaceship.login('xxxxxx@xxx.com') #输入对应的苹果账号
   Spaceship.select_team
   
   Spaceship.certificate.all.each do |cert| 
     cert_type = Spaceship::Portal::Certificate::CERTIFICATE_TYPE_IDS[cert.type_display_id].to_s.split("::")[-1]
     puts "Cert id: #{cert.id}, name: #{cert.name}, expires: #{cert.expires.strftime("%Y-%m-%d")}, type: #{cert_type}"
   end	
   复制代码

   其中打印出来的 cert 对象是证书对象，一个inHouse类型的证书对象其结构为：

   <Spaceship::Portal::Certificate::InHouse 
   id="GF0ZY66W6D", 
   name="iOS Distribution", 
   status="Issued", 
   created=2017-12-19 02:52:11 UTC, 
   expires=2020-12-18 02:42:11 UTC, 
   owner_type="team", 
   owner_name="Communications Corporation Limited", 
   owner_id="12GF5VQGBX", 
   type_display_id="9RQEK7MSXA", 
   can_download=true>
   复制代码

   这里寻找哪个证书还是挺麻烦的，开发者账号中的证书太多了，我也没有仔细想方法，就是按照日期和owner_id来寻找的。

3. 加密证书和配置文件

   从Apple Developer中下载现有的证书及mobileprovision文件，将证书导入到钥匙中，并生成p12文件。得到的证书和配置文件还不能被match识别，需要通过加密命令加密后才符合match的验证要求，其中使用到的命令有：

   • 加密证书

     openssl pkcs12 -nocerts -nodes -out key.pem -in {证书}.p12
     openssl aes-256-cbc -k {密码} -in key.pem -out {cert_id}.p12 -a
     openssl aes-256-cbc -k {密码} -in {证书}.cer -out {cert_id}.cer -a
     

   • 加密配置文件

     {Development/ADHoc/AppStore/InHouse}_bundleId.mobileprovision
     openssl aes-256-cbc -k {密码} -in xxxx.mobileprovision -out Development_yyyy.mobileprovision -a
     

   注意加密证书和配置文件的密码必须一致，在其他设备同步证书和配置文件的时候需要输入这个密码

4. 将加密好的证书和配置文件放到对应目录中，并提交上传仓库

   以上加密过的cer文件和p12文件放到对应的certs目录下对应的文件夹中，加密的mobileprovision文件放到profiles目录下对应的文件夹中，提交commit到远端证书仓库

5. 使用命令验证证书有效性

   在对应工程目录执行：

   fastlane match development --verbose
   复制代码

   如果成功，说明创建的证书没问题。

6. 在其他设备使用证书

   在其他设备上使用命令同步证书和配置文件：

   fastlane match development --readonly --verbose
   复制代码

   需要输入上面加密的密码，之后同步成功。

其他的局限性

解决了match手动同步证书问题，但也意识到match的其他局限性：

• 使用match手动同步证书有什么意义？

  手动同步操作比较麻烦，这样做的好处其实和自己管理证书仓库的区别不大，管理证书人员的工作量基本上没有减少，主要好处在于其他人使用的时候更加方便，不用克隆仓库也不用手动安装证书和配置文件，使用一个命令就可以实现自动安装证书的目的。

  个人认为match的初衷还是推荐使用match自动创建证书的，但确实不太明白nuke命令的设计初衷，并且证书更新也是很大的问题，后面会讲到更新证书的问题。可能match更加适合证书变动不太频繁的情况使用。

• nuke命令很危险

  一听这个单词就很可怕，用核武器攻击，我本来打算尝试使用nuke命令注销证书和配置文件的，但看到命令提示还是怂了， ==执行nuke命令是会注销账号下面所有的证书和配置文件== ，不是只注销对应bundleId的证书和配置文件，要是自己的开发者账号还能玩玩，对于公司开发者账号来说还是算了（没有尝试运行这个命令）。 

• 更新证书和配置文件比较麻烦

  我理解nuke命令其实主要是用来更新证书用的，说是更新其实是重置，命令比较危险。在现有的证书情况和开发人员管理情况下，distribution的证书和配置文件比较稳定，因为大家共用一个证书，配置文件基本也没什么修改的余地，除了有过期风险；而development的证书和配置文件改动就比较多了，一旦添加或注销设备都需要更新证书和配置文件，如果还是用match命令自动生成，就得先nuke，然后重新创建，或者手动重新上传证书和配置文件。

  能想到的比较好的方案就是，不使用邀请开发者的模式，development和distribution的证书和配置文件都由一个账号统一生成并且分配使用，添加设备也由账号管理者统一添加，更改之后可以根据变动大小决定使用nuke还是手动更新证书和配置文件，这个方案主要针对development情况，当然distribution的证书和配置文件也可以使用这个方案更新。

总结

个人认为match也不是特别完美的管理证书的解决方案，还需要根据实际情况分析是否适合使用，如何使用。另外，文章中有什么不对的地方还请读者指出，大家共同进步，谢谢！

参考文档

1. Fastlane证书管理（一）：cert、sigh
2. Fastlane证书管理（二）：match
3. iOS 用fastlane进行团队证书管理
4. fastlane match 运用在现有的证书环境下