既然用户已经认证成功, 现在我们假设用户在这个认证请求中注册了设备. 在设备注册过程中, 应用必须存储认证服务返回来的证书. 如下
证书数据的成功的服务层响应
上述代码片段中返回的证书数据被编码成了 PKCS #12(.p12) 文件格式, 这是由 RSA Laboratories 发布的一种常用标准, 用于与客户端应用交换证书数据.
解码 Base 64 .p12 数据, 提取出标识与证书信息, 并将它们存储起来以供后续的认证请求使用
在检索服务返回的 .p12 证书数据中的身份与证书时可能会出现异常.
使用 Security Framework 中的 SeePKCS12Import() 函数导入身份和信任, 然后提取出证书的过程
作为服务器与客户端 SSL 握手的一部分, willSendRequestForAuthenticationChallenge: 会在服务器信任与客户端证书认证挑战的过程中收到多个回调. 你需要确定应用该处理哪个挑战. 如下代码示例是对代码清单 6-1 的扩展, 用于确定应用是否应该发出客户端证书或是标准的用户凭证来进行认证:
在服务层, 可以通过 openssl_x509_parse() 函数检索到证书的属性. 在获取到证书属性后, 你还可以使用服务层的很多认证选项. 其中一个选项是验证请求发起人, 然后从已知的私钥列表中查找该用户. 另一个选项是在应用中使用 PIN 机制, 从而在向认证挑战发出客户端证书之前进行验证
NSURLConnection 会拦截带有不受信任证书的服务器响应, 这包括自签的 SSL 证书. 如果使用自签的 SSL 证书来测试本章介绍的认证机制, 那么大多数基于网络的代码都将无法执行. 不过, 将服务器证书 (.cer 文件扩展) 以邮件的形式发送给设备上配置好的 E-Mail 账户, 就可以单击并安装证书了. 安装完毕后, NSURLConnection 请求就会将服务器证书看作受信的证书并会继续处理
