您好,登錄后才能下訂單哦!
這篇文章主要為大家展示了“iOS如何基于AFNetworking下自簽名證書配置”,內容簡而易懂,條理清晰,希望能夠幫助大家解決疑惑,下面讓小編帶領大家一起研究并學習一下“iOS如何基于AFNetworking下自簽名證書配置”這篇文章吧。
自從https推出以后,客戶端對網絡安全的要求程度也越來越高。甚至在iOS9之后,蘋果強制要求必須支持https請求。
https是什么呢?它又是如何保證數據安全的呢?
簡單來說,https就是http+TLS/SSL。就是在http上又加了一層處理加密信息的模塊。服務端和客戶端的信息傳輸都會通過TLS進行加密,也就說傳輸中的數據都是加密的,如果不知道私鑰,是無法真正知道傳輸內容的真正意思的。
整個https單向驗證流程簡單總結如下:
就是用戶發起請求,服務器響應后返回一個證書,證書中包含一些基本信息和公鑰。
用戶拿到證書后,去驗證這個證書是否合法,不合法,則請求終止。
合法則生成一個隨機數,作為對稱加密的密鑰,用服務器返回的公鑰對這個隨機數加密。然后返回給服務器。
服務器拿到加密后的隨機數,利用私鑰解密,然后再用解密后的隨機數(對稱密鑰),把需要返回的數據加密,加密完成后數據傳輸給用戶。
最后用戶拿到加密的數據,用一開始的那個隨機數(對稱密鑰),進行數據解密。整個過程完成。
當然這僅僅是一個單向認證,https還會有雙向認證,相對于單向認證也很簡單。僅僅多了服務端驗證客戶端這一步。
那么在AFNetworking中,我們要完成自簽名證書配置:
// 自簽名證書在路徑 NSString *certFilePath = [[NSBundle mainBundle] pathForResource:@"service" ofType:@"cer"]; // 自簽名證書轉換成二進制數據 NSData *certData = [NSData dataWithContentsOfFile:certFilePath]; // 將二進制數據放到NSSet中 NSSet *certSet = [NSSet setWithObject:certData]; /* AFNetworking中的AFSecurityPolicy實例化方法 第一個參數: AFSSLPinningModeNone, //不驗證 AFSSLPinningModePublicKey, //只驗證公鑰 AFSSLPinningModeCertificate, //驗證證書 第二個參數:存放二進制證書數據的NSSet */ AFSecurityPolicy *policy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate withPinnedCertificates:certSet]; // shareManager 是繼承自AFHTTPSessionManager的一個類的實例對象 sharedManager.securityPolicy = policy;
這樣在請求時,如果服務器要校驗自簽名證書就會調用AFSecurityPolicy類中以下方法
- (BOOL)evaluateServerTrust:(SecTrustRef)serverTrust forDomain:(NSString *)domain
AFNetworking就是在這個方法中進行的單向驗證。如果有需要雙向驗證的也需要重寫這個方法,以實現雙向驗證。(雙向驗證在銀行類等app中使用的較多)
在該方法中使用自簽名證書可能會出現的一個問題就是
復制代碼 代碼如下:
[pinnedCertificates addObject:(__bridge_transfer id)SecCertificateCreateWithData(NULL, (__bridge CFDataRef)certificateData)];
這行代碼有可能數組中添加了nil,即自簽名證書沒有獲取到。
解決方法:
將后端發過來的.crt證書,修改后綴.cer,導入鑰匙串。
再從鑰匙串導出該證書,拉到項目里直接使用
其本質原因是后端的自簽名證書需要進行base64反編碼才能使用。
以上是“iOS如何基于AFNetworking下自簽名證書配置”這篇文章的所有內容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內容對大家有所幫助,如果還想學習更多知識,歡迎關注億速云行業資訊頻道!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。