人力有时而穷，记忆力终究还是挡不住时间消磨，期间遇到各种奇葩问题，也是只有亲身经历才能理解。所以现在记下来，防止以后走弯路。

事先准备：

1）.首先你得有一个付费的开发者账号

2）.Mac、iPhone设备得准备好

开始进入正题

第一步：先准备好CSR，CSR又叫.certSigningRequest文件，用于请求证书和描述文件，所以这也叫请求文件。生成方法如下：

1.打开钥匙串

点击如图所示的“从证书颁发机构请求证书……”

图1 获取CSR

2.跳出证书助理，用户电子邮件地址可随意填，但最好填你自己邮箱，请求选择“存储到磁盘”

图2 保存CSR到本地磁盘

3.点击继续后得到CertificateSigningRequest.certSigningRequest文件

第二步：登录developer.apple.com登录你的开发者账号

图3 申请bundle ID

1.如上图所示，先生成APPID既bundleID，点击加号然后生成bundleID，这里没什么难点，主要需要注意的是bundleID命名的规范性

图4 申请推送证书

2.现在生成推送证书，如上图，一般需要生成开发证书和APPStore用的证书，development对应开发证书，production对应APPStore证书

图5  开发者证书选择如上图

点击右上角加号，如果是development则选择如上图所示的Apple Push Notification service SSL (Sandbox)，点击继续，选择我们刚刚生成的App ID也就是bundle ID

图6 申请证书需要上传CSR

接着上传我们生成好的CertificateSigningRequest.certSigningRequest文件，然后点击生成证书，最后一步的时候记得下载证书到桌面，后面会用到到这里tui'son推送证书就生成了，接下来我们生成描述文件provision

3.描述文件生成也大同小异，没什么难点development就选择development，AppStore就选Appstore，也是上传CSR得到描述文件provision，然后download到桌面备用。

第三步：我们回到桌面，安装推送证书，这里有一个坑，最好我们别直接双击安装，否则有可能出现没有专用秘钥的情况，如下图中第一个证书，发现了吗？它是没有展开箭头的，意味着它没有专用密钥。这样是不行的。

图7  错误的证书，缺少专用密钥

在这里我弄了进一个上午，反复删除证书和provision然后重新安装，甚至重新生成bundle ID和provision以及推送证书全部重来一遍，都无效，网上搜索来的方法几乎都试过，还是无果。突然我看到某个论坛有人说了句，直接把证书拖到登录里，一试，果然可以了！真是大坑！

图7  我们得把证书拖入登录这个选项内

如上图，已经有下拉箭头了，说明有专用密钥了。你可能会问，为什么我千方百计要把专用密钥弄出来呢？直接安装证书，然后选好对应provision和bundleID不就好了吗？程序也可以正常运行啊。是的，没错，是可以运行，但是推送证书所需要的p12文件你就倒不出来了！推送需要证书和专用密钥的p12文件！p12文件！P12文件！

接下来我们就可以倒出p12文件了，右键证书选择导出

图8  导出证书

图9  导出证书p12

终于看到了我梦寐以求的p12文件，泪奔

好的，把它放到桌面上，同理，也别忘记了把对应的专用密钥导出来，如下图

图10 导出密钥p12文件

现在我们就得到了development的推送证书和专用密钥的.p12文件，接下来我们需要把它们合成为一个.pem文件，这个才是服务器做APNs推送需要用到的文件。

第四步：生成.pem文件

到此为止，我们已经有了两个.p12文件，把他们放到同一个文件夹(aaa)下，需要把两个.p12文件转换成.pem文件。

a.先打开终端，切换到文件夹aaa下执行

[cpp]view plaincopy

openssl pkcs12 -clcerts -nokeys -out cert.pem -in cert.p12

在执行的时候，将会让输入密码，输入刚才设置的密码即可生成一个cert.pem文件。

b.再执行：

[cpp]view plaincopy

openssl pkcs12 -nocerts -out key.pem -in key.p12

此时要注意在终端中的提示，第一次输入的密码是生成证书时候的密码，第二次第三次输入密码是设置key.pem的新密码。

c.如果需要对key不进行加密，执行下边语句

[cpp]view plaincopy

openssl rsa -in key.pem -out key.unencrypted.pem

d.然后就可以合并两个.pem文件,这个ck.pem就是服务端需要的证书了。

[cpp]view plaincopy

cat cert.pem key.unencrypted.pem > ck.pem

此时，把生成的ck.pem给服务器端的人员即可。

apns-dev-cert.p12和apns-dev-key.p12

第一个是推送证书的p12第二个是专用密钥的p12

图11 pem文件已经生成

这就是我们最终需要的.pem文件，把这文件给服务器就好了，剩下的是服务器端的事情。

等服务器安装好证书及调试后，我们需要测试下推送到底能不能用，所以，我们提供pem文件的同时得提供bundleID和devicetoken。等等，devicetoken？这是什么东东？好的，接下来我们再讲讲这个坑。

通过神奇的百度，我找到了如下资料：

先简单介绍下push的机制

客户端通过

(void)registerForRemoteNotificationTypes:(UIRemoteNotificationType)types

这个函数向APNs（Apple Push Service）注册push，types可标明接收的push的类型，声音，数字等。

(void)application:(UIApplication

*)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData

*)deviceToken;

当app成功注册通知后，会调用这个函数，并把deviceToken返回给应用。

然后我们的程序就会把返回的这个deviceToken以及设备的udid及软件版本（淘宝for iPhone还是淘宝for iPad）及系统版本，用户名等发送到我们的服务器（下图中的provider）上，然后存储在数据库里。整个获取device token的过程可参见下图所示：

在需要发送push时，我们的服务端就会取出要发送的设备的device token，然后以下图所示的结构，组成符合特定结构的字符串，然后将其发送到的APNs

APNs可以根据与APNs建立连接的Provider所使用的证书判断是要哪个app请求发送的notification，继而把这个notification发送到的设备上。

下图为一个简单的从Provider到Device发送push的过程：

device

token到底是什么呢？不同的app的device

token相同么？一个设备会产生多个device token么？一个的device token可能对应多个UDID么？

结论：device token是对APNs来说，设备的标识符，与app无关，所以同一台设备上，不同的app获得的device token是一样的;一个设备可能会产生多个device token,一个device

token也可能对应多个UDID，下面进行解释。

device

token是什么？

文档中如下描述的：

对于APS来说，token是设备的标识符。device token不同于UIDevice的uniqueIdentifier（即UDID），因为出于安全和隐私原因，当设备被擦除后，token必须变化。

所以也就是说，一般情况下，token是不变的，但是在设备被擦除后，token会变的。

今天无心说在我们的服务器上的数据库里，存在同一个UDID对应有多个token的情况，之前是没有考虑到设备擦除的情况，所以就怀疑是不是同一个设备上同时装了taobao4iphone和taobao4ipad，而token是与app关联的，所以产生的这种情况，于是就找了杨匡的ipad来做测试，结果发现taobao4iphone和taobao4ipad收到的token是相同的，所以token应该是与app无关的，而是针对设备的（文档上也是如此描述的），是设备的标识，那除了设备被擦除的情况外，设备的device token应该是相同的，可是杨匡说之前崇厚给他查出来的他的iPad的token和我log出来的device token是不同的，后来就想到了，push是有两套的，development和product，即调试和release，在这两种情况下，服务端使用的push证书是不一样的，而程序使用的证书也不一样，那同一个设备在development和distribution情况下收到的device token是否一样呢，于是就做了实验，实际结果如下

实验设备：iPad 1

可以看出，同一个设备在development和distribution情况下，收到的device token是不同的，而token是与app无关的。

综合文档及上述实验结果可以得到以下结果：

同一个udid对应有不同的device token的情况暂时有如下两种：

设备擦除过，token变化过，老的新的都存储在数据库里

设备同时装过development和distribution的程序

不知道还有没有其它原因造成的同一个设备有不同的device token的情况，大家如果有什么相关的经验，可以补充一下。

Ok，balabala一堆讲完了，我们总结了下，devicetoken类似于令牌，但是又不同于UUID唯一标识符，devicetoken会变化，但是我们只要知道它也是Apple设备的标识符就好了，配合bundleID这样才能给设备准确地推送，OK科普完毕，开始获取devicetoken

//获取DeviceToken成功

- (void)application:(UIApplication*)application

didRegisterForRemoteNotificationsWithDeviceToken:(NSData*)deviceToken

{

NSLog(@"DeviceToken: {%@}",deviceToken);

//这里进行的操作，是将Device Token发送到服务端

UIAlertView* alert = [[UIAlertViewalloc]initWithTitle:nilmessage:[NSStringstringWithFormat:@"DeviceToken:%@",deviceToken]delegate:selfcancelButtonTitle:nilotherButtonTitles:@"确定",nil];

[alertshow];

}

从上面这个方法里，我们就能得到devicetoken，打印出来就OK了，但我们还有一个问题，APPStore版本和development用的是同样的bundleID所以devicetoken是一致的，但是如果是inhouse版本怎么办？其实也很简单，那就是，我们把上面那个方法里得到的devicetoken传递到某个页面，然后用label或者alertview，或者其他可视的控件展示出来就好了，然后抄下来就OK啦！

OK，推送搞定！

接着我们选择对应的证书provision 和 bundleID就可以愉快地开发啦！