TLS証明書を手動で検証する（ios objective-c）

Question

TLSを使用してWebサーバーと通信するiOSアプリケーションを作成しています。 Webサーバーにアクセスすると、デバイスに証明書が提示され、信頼できることを検証したいと考えています。

xcodeプロジェクトにderファイルとしてルート証明書が組み込まれています。私は今までNSURLConnectionの認証チャレンジのデリゲート関数で両方の証明書のNSStringバージョンを取得しています。

手動で検証する方法はありますか？私はこの記事があなたの目的を解決するためだと思う

- (void)connection:(NSURLConnection *)connection willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge { 
NSLog(@"Certificate challenge"); 
if (self.stageNum==0) { 
    id <NSURLAuthenticationChallengeSender> sender=challenge.sender; 
    NSURLProtectionSpace *protectionSpace=challenge.protectionSpace; 
    SecTrustRef trust=[protectionSpace serverTrust]; 

    //Get server certificate 
    SecCertificateRef certificate=SecTrustGetCertificateAtIndex(trust, 0); 
    NSData *serverCertificateData=(__bridge NSData *)SecCertificateCopyData(certificate); 
    NSString *serverBase64Certificate=[serverCertificateData base64EncodedStringWithOptions:0]; 

    //Get our certificate 
    NSData *certData1 = [[NSData alloc] initWithContentsOfFile:[[NSBundle mainBundle] pathForResource:@"SUMOSRoot" ofType:@"der"]]; 
    NSString *certBase64=[certData1 base64EncodedStringWithOptions:0]; 

    //Heres where I need to compare the certificates 
    // 
    // 

    [sender useCredential:[NSURLCredential credentialForTrust:protectionSpace.serverTrust] forAuthenticationChallenge:challenge]; 
} 
} 

Answer 1

：

は、ここに私の現在のコードです。美しく書かれ/説明されています。リンクを開くのが面倒です

http://www.techrepublic.com/blog/software-engineer/use-https-certificate-handling-to-protect-your-ios-app/

人々は、私はポストからこっち、いくつかの説明を追加します。

Answer 2

私はあなたがNSString表現を取得したいと思います理由はわかりません。 SecTrustRefを取得したら、SecTrustCopyPublicKeyに電話して公開鍵をSecKeyRefにコピーし、それを元の鍵データ（生のバイト）と比較することができます。公開鍵が一致する場合は、証明書を受け入れる必要があります。

このテクニックは「証明書のピン設定」と呼ばれ、その用語を検索すると完全なコードサンプルを提供できるStack Overflowにはおそらく多くの回答があると確信しています。

証明書を比較することもできますが、証明書は定期的に期限切れになり更新する必要があるため、おそらくあなたがしたいことではありません。鍵を比較すると、証明書を再生成しても（鍵を同じ秘密鍵/公開鍵のペアで再生成したと仮定しても）、鍵は比較され続けます。

また、特定の長命プライベートルート証明書に結びつけたい場合は、信頼できるアンカーのリストにその証明書を追加して、信頼オブジェクトを再評価して、そのプライベートルート証明書は失効します。一方、鍵を固定すると、何らかの理由で秘密鍵を変更する必要が生じた場合には破損しますので、それはトレードオフです。

もちろん、可能な場合は、実際のCA証明書を取得し、チェーン検証のいずれかを混乱させないようにするのが最も一般的ですが、これは不可能であると想定していますサーバが.localドメイン、インターネットアクセスなしで独自の証明書を生成する物理デバイス、またはその他の同様の理由で） .localネットワーク上の任意のハードウェアとの安全な通信のようなものでは、鍵の固定が最善の方法です。キーが一致しない場合は、ユーザーに新しいキーなどを追加するように要求します。