57.阐明iOS证书和provision文件

Any iOS developer will tell you that one of the most confusing parts of developing for iOS is getting the app to actually run on real devices, because of all the work involved getting certificates working. Even for those who understand how certificates in general work, it's still kind of weird to get everything to work correctly. This is going to be a long post, but hopefully it'll be used for some of you.

To better understand why we need to go thru all this, you need to always remember the main reason behind it:

Apple, and only Apple, can really allow a hardware device to run a piece of software, period.

Yes, this is a very strict rule, many people don't like it, but Apple really enforces with an iron fist. This rule is enforced in software using cryptographic signatures, and every time an app starts up, the app is checked to make sure it was signed by Apple and that you have permission to run it. There are ways to override this by jailbreaking a device and then hacking the software, but that's really not a good option for most people.

Apple Digital Certificates

Ok, so if only Apple can run software, how can developers run software for testing? The short answer is that Apple basically trusts you to allow apps on Apple's behalf. The long answer is long, and here's where everything starts.

When you're registered in the iOS Developer program, Apple allows you to request one very special certificate that can be used to sign things (and apps) on Apple's behalf. You do that by creating a Certificate Signing Request (CSR) using the Keychain Access app. When you go thru the "Request a Certificate from a Certificate Authority" assistant two things happen:

1. First, Keychain app will create a public and a private key for you automatically. They can be seen in the "Keys" category in Keychain. These keys are REALLY important: they are basically used to tell Apple who YOU are. Do not EVER loose these files, unless you want to want to go thru this process again. Make backups, etc.
2. Finally, Keychain uses those keys to create a certSigningRequest file that you send to Apple. That file basically contain your name, email, and public key, and is signed using your private one, so that Apple knows for sure you created it.

Now, you'll upload that CSR to Apple, and Apple will confirm everything is ok and then issue you a development certificate. You can download the "developer_identity.cer"  file to your system, and then drag-and-drop it to Keychain Access. This new certificate will now show in the "My Certificates" category. Double-click it and you'll see the details: this is a simple certificate, issued by Apple, that simply says that they really trust who you are. This will be used later on when signing apps.

Provisioning Files

So the first step is complete: you have a certificate from Apple, saying who you are and that can be used to sign apps. Is that it, though? No. Your iPod/iPhone or iPad still doesn't know that it can trust you and not Apple, and that's where the provisioning files come in.

When you create a provision file, you're basically associating the iOS devices you have listed in the Provisioning Portal with the certificate signed by Apple in the previous step. The result of that is a .provision file, that is used during the compilation process of an iOS app, and also needs to be deployed to the device. To install this provision file, simply download it and double-click it: x-code will automatically add it to the list of provisioning profiles in the Organizer.

You can have multiple provision files, one for each project you work on, or use just one provision file for all your apps. If you have just started a new app, or still are in early stages of development, the simple thing to do is to just use one provision for development. Eventually, though, you might need to create specific provision files for each app, because the AppId added in the provisioning portal is compared to what is configured in the app, and you'll have to set the AppId on your app to submit to the store.

Building an App and Running It

So lets recap: you already have your private and public keys that define who you are, the certificate from Apple saying it knows who you are, and a provision file saying that code built by you is allowed to run on your devices. Now its time to build the app.

I won't explain in details here how to set up Xcode or MonoTouch to build the app, there's a million tutorials for that out there. The only thing I'll mention is that you'll have to tell your build tool to use both your signed certificate and the provision file.

When you run the build, using either MonoTouch or Objective-C, all you're doing is creating a directory that contains all the things your app needs inside. If you right-click on the final app and show the contents of the directory, besides all the normal project files and resources you'll also see two other things:

• The actual provision file. This is just a straight copy of the file you already have.
• A directory called "_CodeSignature". This is the interesting one. Inside it there's one file called "CodeResources"; it's a simple plist file, but it contains cryptographic hashes of all the other files in the solution.

When the application is finally installed, iOS does a lot of things: first, it makes sure the provision file is signed by Apple. Then, it compares each one of the hashes in the CodeResources against the real files, using the provision key, to make sure the files haven't been modified since the build. If there are any problems, the app won't be installed.

The last check happens when you run the app. iOS checks that the app hasn't been modified, and that you still have a provision file that matches the app you're trying to run. If you do not have one anymore, the app will crash.

Other Deployments

Ad-hoc deployment works pretty much the same way as written above. You still register all of your users devices, and everything works the same way.

Enterprise deployment though, is a bit different. When you're a big company with thousands of iPhone users, Apple tends to like you and they trust you a lot more: they basically give you a certificate that allows you to re-sign your application as if you were really Apple. For all purposes, all iOS devices will automatically recognize you and will run the app with no problem, so you don't need to register devices in the provision file. Other than that, everything else is the same.

Finally, there's App Store deployment. Like the enterprise deployment, there's no need to register devices in the provision file. The difference though, is that the signature in the provision file you get from Apple doesn't allow you to run anywhere! You won't be able to run the application build for the AppStore anywhere; the only thing you can do with it is submit it for the AppStore approval.

When Apple receives your App, it's been already signed by you and contain the provision file, so they know you're really the correct person submitting the app, and that the App is the one that should be approved. After its reviewed, they finally re-sign the app with their own signature that can run on any phone.

--

Writing this post has actually helped me understand better the entire process, and I hope it help others as well. I hope everything here is correct, but if you see any problems please leave a message and I'll fix it!

译：阐明iOS证书和provision文件

 

许多iOS开发人员都会和你说在iOS开发很困惑的问题之一，将app真正运行在真实的设备（iPhone iPad而不是模拟器），因为所有的这些都会涉及从苹果获得证书，甚至那些知道证书的一般流程的，仍会感觉有些奇怪一切是如何运行的，这将是一个长期的过程，但我希望本文将对你有用。

为了更好的理解我们需要去了解这些的理由，你需要谨记这背后最大的原因：

     苹果，只有苹果，只允许硬件设备在有限的时间内（develop id 一年的时间）运行指定的软件

是的，这是一个非常严格的规则，很多人不喜欢它，但是苹果用铁腕强制推行，这条规则强制软件使用密码签名，每一次app启动时，系统将检查app，以确保它被苹果和开发者允许运行，通过设备越狱和软件破解，可以绕过这些，但对大多数人这不是一个好选择。

 

苹果数字签名

如果只有苹果可以运行软件，那开发者如何测试软件？（这是不可能的）简短的答案是苹果只相信符合苹果利益的app，长的答案很长，可以从以下几点开始：

当你注册成为iOS开发者，苹果允许你去申请一个特别的证书，用来以苹果的方式去签名app或者其他，你通过使用keychain创建一个Certificate Signing Request (CSR)，当你从“证书中心请求一个证书”(Request a Certificate from a Certificate Authority) 两件事情发生:

1 首先，keychain 将为你自动创建一个公钥和私钥，在keys的目录下，可以看见它们。这些keys是非常重要的：它们用来告诉苹果你是谁，不要丢失这些文件，除非你想重做这些流程，可以做个备份。

2 最后，keychain使用keys创建一个certSigningRequest文件去苹果公司，这些文件包含了你的名字、email、公钥、并且使用私钥签名，从而Apple确保是你创建的。

现在，你要上传CSR给Apple，Apple将确认一切是否正常，然后发给你一个开发者证书（development certificate）,你可以下载“developer_identity.cer”文件到你的系统，然后拖到keychain中（双击该文件也可以）。这个新的证书将在“My Certificates”目录中显示，双击它，可以查看它的内容：这是一个简单的证书，由Apple发布，说明Apple相信你是谁，将会在签名app时使用到。

 

Provisioning Files（配置文件）

你的第一完成了，你有了一个来自Apple的说明你是谁的和签名app的证书，就这样么？不，你的iPod/iPhone仍然不知道它是否可以信任你，这里就需要配置文件登场了。

当你创建了配置文件，你在Provision Portal使用上一步苹果颁发给你的证书，关联了iOS设备，结果就是一个用来记录iOS app的过程（即该app是否开启push功能等这些信息）和一个部署到设备所需要的.provision的文件。下载它，并双击安装，Xcode自动将配置文件添加到Organzier.

 

你可以在一个工程下有数个配置文件，也可以对所有的app使用一个配置文件。如果你创建一个新app，或者继续开发先前的，一个简单方法是对开发使用一个配置文件。最后，你需要创建一个特别配置文件为每个app，因为AppId添加了在Provision Portal比较该app的设置信息（如是否开启push等）。完成这些，你可以设置AppId提交到app store。

 

编译App并运行

让我们复习一下，有已经有了用来定义你是谁的公钥和私钥，从Apple颁发的证书说明了它知道你谁，配置文件说明了你的项目可以运行在你的设备上，现在是生成执行文件的时候。

我将不在解释设置Xcode或者Mono Touch去编译app，网上有许多教程。我唯一提醒的是你要使用你的这个证书和配置文件设置编译工具。

当你运行编译的app，所做的是创建一个包含所有你的app需要的文件的目录，如果你右键点击最终的app，选择显示目录下的内容，除了所有正常工程文件和资源，你将发现还有两个东西：

1 实际的配置文件，是你已经配置文件的直接拷贝。

2 一个叫“_CodeSignature”的目录，这个很有趣，里面有一个"CodeResources"的文件，这是一个简单的plist文件，包含了该包内所有其他文件的加密hash值。

当app被安装后，iOS做了很多事情：第一，它确保配置文件（provison file）是由苹果签发的，然后它使用provision key比较每一个真实文件的hash值和在CodeResources下hash值，去确保这些文件从编译开始一直未被该改变，如果有任何问题，app是不会安装的。

最后一次检查发生在当你运行app时，iOS检查app未被改变，你拥有一个与尝试运行app相匹配的配置文件，如果没有，app将crash。

 

其他部署

Ad-hoc部署工作与上文写的相似，你仍然要注册你的设备，所有的事情都一样。

企业开发有些不一样，当你有一家数千台iPhone使用者的大公司，Apple表现得更喜欢你和信任你多一些，他们给你一个允许你像apple公司一样的重签名的证书，为了所有的iOS设备将自动识别你并且可以运行app，所以你不需要在配置文件里注册设备，除了这一点，其他的都一样。

最终，部署到App Store，像企业部署一样，不需在配置文件里注册设备，不同的是，在从Apple的的的配置文件中的签名不允许你到处运行，你不可以运行app除了在AppStore里，你唯一能做的事就是提交到AppStore等待许可。

当苹果接受到你的App，已经被你签名过并包含配置文件，所以他们知道你是一个提交app的正确的人，并且App是一个应该被许可的，在检查回顾过之后，他们最终用他们自己的可以运行在任何设备的签名重新签名app。

 

写的这些能在官方文档之外帮助到我，我也希望能帮助到其他人，我希望没有谬误，如果有任何问题，请留言，我将解决它。