前提 :

1.當(dāng)前iOS 官方文檔沒有明確檢驗是否安裝描述文件的直接使用方法,都是間接檢測(以安裝mdm的描述文件為例,官方文檔好像提到了通過每隔一段時間輪詢設(shè)備 /或者嘗試發(fā)送mdm推送查看服務(wù)器 查看是否有反饋 來檢測某個設(shè)備是否安裝描述文件),

圖片 2.png

2.如果當(dāng)前設(shè)備安裝的描述文件中,必須包含一個自簽名的證書(即非蘋果內(nèi)嵌的信任的CA機構(gòu)頒發(fā)的CA證書,無法直接在蘋果系統(tǒng)直接就通過認證,),我們可以自己做一個簽名文件,一起放到描述文件中,輔助我們完成這個功能

                iOS 中HTTPS的攜帶的證書是否信任檢測機制

1.安裝iOS系統(tǒng)的時候 ,iOS系統(tǒng)中會包含很多知名的的CA機構(gòu)頒發(fā)的CA根證書,不同的iOS版本 包含的機構(gòu)不同,具體查看下面的鏈接
參考鏈接 :https://support.apple.com/zh-cn/HT204132

2. 當(dāng)客戶端或者iOS系統(tǒng)去訪問一個https的服務(wù)器(以Server替代)時,Server會返回一個數(shù)字證書,數(shù)字證書包含當(dāng)前Server的公鑰,當(dāng)前證書的簽發(fā)機構(gòu)(包含簽發(fā)機構(gòu)的信任鏈),當(dāng)前證書的有效期,序列號等等信息

image.png

image.png

3.當(dāng)客戶端收到服務(wù)器給的返回的證書(此處只討論信任鏈模塊的檢測,先不討論具體的通信的校驗),去校驗證書的有效性,分為兩種情形:

A : 當(dāng)前證書的信任鏈的根證書 在當(dāng)前系統(tǒng)的可信任列表中
服務(wù)器會根據(jù)證書中包含的信息(有效期等待)簡單判斷是否在有效期,如果在有效期,在查看證書的信任鏈,找到該證書的上級頒發(fā)機構(gòu),如果找到,再去找當(dāng)前頒發(fā)機構(gòu)的上級機構(gòu),一直往上找,直到找到該CA機構(gòu)頒發(fā)的根證書(自己給自己簽名的證書),如果該根證書的CA頒發(fā)機構(gòu)在當(dāng)前系統(tǒng)的頒發(fā)機構(gòu)的信任列表中(即上面提到那個系統(tǒng)植入的所有的信任機構(gòu)),然后根據(jù)根證書的公鑰,再一級一級的將下級信任鏈上的公鑰一一解密,(通過上級簽發(fā)機構(gòu)的公鑰解密下級機構(gòu)的公鑰),直到解密到當(dāng)前證書的公鑰,查看與當(dāng)前證書的公鑰是否一致,如果一致,可以信任. 否則,不可以信任,如果是瀏覽器,會提示有證書不可信等等警示信息(不同于自簽名的提示),如果是app,應(yīng)該會主動中斷鏈接,網(wǎng)絡(luò)報errcode -999,被取消.

image.png

B : 當(dāng)前證書的信任鏈的根證書 不在當(dāng)前系統(tǒng)的可信任列表中

服務(wù)器會根據(jù)證書中包含的信息(有效期等待)簡單判斷是否在有效期,如果在有效期,在查看證書的信任鏈,找到該證書的上級頒發(fā)機構(gòu),如果找到,再去找當(dāng)前頒發(fā)機構(gòu)的上級機構(gòu),一直往上找,直到找到該CA機構(gòu)頒發(fā)的根證書(自己給自己簽名的證書),如果該根證書的CA頒發(fā)機構(gòu)在當(dāng)前系統(tǒng)的頒發(fā)機構(gòu)的信任列表中(即上面提到那個系統(tǒng)植入的所有的信任機構(gòu)),如果該根證書不在系統(tǒng)的信任列表中(自簽名類型),如果是瀏覽器,瀏覽器會給出提醒,如果是我們自己開發(fā)的app,就會進入證書挑戰(zhàn)(在<NSURLSessionTaskDelegate>和<NSURLSessionDelegate>這兩個代理中,didReceiveChallenge這個方法中,前者比后者的方法多了一個task,系統(tǒng)會優(yōu)先調(diào)用后者,后者沒有實現(xiàn),會去調(diào)用前者),我們可以在這個方法中處理當(dāng)前證書的校驗(以AFNetworking的代碼為例):
注意綠色框 框出的方法,是處理域名校驗的處理

image.png

                                    域名校驗的部分代碼

image.png

我們需要在這里面處理我們的挑戰(zhàn),根據(jù)我們的策略,一般都是在我們bundle里面嵌入證書,處理是否和我們自簽名的一致,如果直接就返回可以信任的話,會有風(fēng)險,這就是好多自簽名的服務(wù)器,一般客戶端bundle中會包含這個證書,專門處理這個挑戰(zhàn),
ps:其實客戶端處理這個挑戰(zhàn),信任的時候 就是將這個證書臨時加入了系統(tǒng)信任的根證書里面,到時候我們的正式校驗就通了,就相當(dāng)于走了A情形了.

                         關(guān)于描述文件是否安裝的檢驗邏輯

當(dāng)客戶端安裝描述文件的時候,描述文件會獲取用戶的授權(quán),描述文件中如果包含自簽名的證書,如果用戶同意了安裝并且安裝,該自簽名的正式理論上也是被系統(tǒng)信任的了,所以系統(tǒng)的信任列表中會包含該證書,一旦用戶卸載了描述文件,該系統(tǒng)中的信任列表中,該自簽名的證書的也會被移除,基于這個機制,我們可以通過判斷該證書是否被系統(tǒng)信任,來判斷當(dāng)前是否按照描述文件,下面是校驗代碼,通過bundle中的描述文件,來判斷當(dāng)前設(shè)備是否受系統(tǒng)信任
客戶端讀取證書信息(可以是多個證書),生成證校驗對象,并且設(shè)置信任策略,根據(jù)
證書當(dāng)前的OSStatus的值來判斷是否受系統(tǒng)信任,注意區(qū)別上面的域名信任的時候的那個設(shè)置方法,方便理解.

image.png

iOS11之前,這樣判斷就可以

image.png

iOS 11就需要這樣了,對于信任的枚舉值類型 增加了一個 (但是這個不太靠譜,正在評估)
2017.09.20更新

到此.描述文件是否本地安裝的校驗機制就走完了,這是我的理解,有錯誤請指出,共同學(xué)習(xí),謝謝