信頼されていない証明書を使用した SSL の構成

基本概念

認証局 (CA)

証明書を発行するエンティティーです。CA は、他の証明書または他の CA 証明書 (中間 CA 証明書) を発行 (署名) できます。

Public Key Infrastructure (PKI) では、証明書はトラストの階層型チェーンによって検証されます。 このツリーの最上位にある証明書がルート CA 証明書です。

証明書は、公開インターネット CA から購入するか、独自のプライベート (ローカル) CA を構築して、ユーザーおよびアプリケーションのためのプライベート証明書を発行することができます。CA は、クライアントによって十分信頼される機関である必要があります。ほとんどの商用 CA は、ほとんどの Web ブラウザーおよびモバイル・プラットフォームによって自動的に信頼される証明書を発行します。プライベート CA を使用するということは、ユーザーのルート CA によって署名された証明書を、クライアントが確実に信頼するための特定のアクションを実行しなければならないことを意味します。

証明書は、ご使用のモバイル・プラットフォームで認知されている多くのパブリック CA の 1 つによって、プライベート CA によって、またはそれ自体によって署名 (発行) できます。

自己署名証明書

自己によって署名され、その妥当性を保証する CA がない証明書です。

自己署名証明書の使用は、ほとんどのモバイル・プラットフォームでサポートされないため、推奨されません。

自己署名 CA

自己によって署名された CA。これは、証明書であり CA です。これはツリー内の最上位の証明書なので、ルート CA でもあります。

セキュリティー上の理由から、プライベート CA によって署名された証明書をインターネットに接続している外部サーバー上で実動で使用することは推奨されません。 ただし、そういった証明書は、コストが低いため、開発環境およびテスト環境では優先的な選択肢になることがあります。 また、デプロイメントを迅速かつ容易に行えるため、多くの場合、内部 (イントラネット) サーバーに適しています。

さまざまなモバイル・プラットフォームによってサポートされている証明書タイプ

iOS によってサポートされている証明書タイプ

自己署名証明書と自己署名 CA

モバイル・クライアントを扱っているときは、 自己署名証明書を使用することは推奨されません。 なぜなら、モバイル・プラットフォームでは、このようなタイプの証明書をデバイスのトラストストアにインストールすることが許可されないからです。 この制限により、クライアントがサーバーの証明書を信頼することは不可能になります。自己署名証明書は、開発目的およびテスト目的に推奨されることがよくありますが、クライアントがモバイル・デバイスの場合は機能しません。

代替方法は、自己署名証明書の代わりに自己署名 CA 証明書を使用することです。自己署名 CA 証明書は取得が簡単であり、さらに費用効率の高いソリューションです。

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt -reqexts v3_req -extensions v3_ca

openssl x509 -in certificate.crt -text -noout

クライアントでの信頼の確立

モバイル・ブラウザーで Web ページを開くか、または HTTPS ポートで MobileFirst Server に直接接続すると、クライアントは SSL ハンドシェークでサーバー証明書を受け取ります。その後、クライアントは、信頼を確立するために、既知のトラステッド CA のリストを使用してサーバー証明書を評価します。各モバイル・プラットフォームには、SSL 証明書の発行に信頼できるトラステッド CA のセットが含まれています。 サーバー証明書が、既にデバイスによって信頼されている CA によって署名されている場合、信頼が確立されます。信頼が確立されると、SSL ハンドシェークが正常に実行され、ブラウザー上で Web ページを開いたり、サーバーに直接接続したりすることが許可されます。

ただし、クライアントが認識していない CA によって署名されている証明書がサーバーで使用されている場合は、信頼は確立されず、SSL ハンドシェークは失敗します。クライアント・デバイスがサーバーの証明書を信頼するようにするためには、クライアント・デバイスにトラスト・アンカー証明書 (ルート CA) をインストールする必要があります。

iOS については、iOS へのルート CA のインストールを参照してください。

Android については、Android へのルート CA のインストールを参照してください。

Windows Phone については、Windows Phone へのルート CA のインストールを参照してください。

Windows 8 については、Windows Phone へのルート CA のインストールを参照してください。

Android の構成

android:debuggable="true"

実稼働環境でのこのフラグの使用は推奨されません。クライアント・デバイスによって信頼されている CA によって署名された証明書を使用してサーバーを正しく構成した場合、これは必要ありません。

証明書チェーンの処理

サーバー自体によって署名されていないサーバー証明書を使用している場合は、サーバーがクライアントに完全な証明書チェーンを送信していることを確認する必要があります。

クライアントが証明書パスを検証するためには、証明書チェーン全体へのアクセス権限を持っている必要があります。 クライアントが、中間証明書を含めて完全な証明書チェーンにアクセスできるようにするには、チェーン内のすべての証明書がサーバー・サイドの鍵ストア・ファイルに含まれていることを確認してください。

WebSphere® Application Server Liberty については、証明書チェーンを使用するための鍵ストアおよび Liberty プロファイル構成の更新を参照してください。

証明書拡張機能の処理

RFC 5280 (およびその先行 RFC) は、証明書に関する追加情報を提供する数多くの証明書拡張を定義しています。証明書拡張は、基本となる X.509 証明書の情報の標準を拡張する手段を提供します。

X.509 証明書に拡張が指定されている場合、その拡張は、それが重大な拡張か重大でない拡張かを指定する必要があります。クライアントが認識していない、またはクライアントが処理できない重大な拡張を持つ証明書を処理しているクライアントは、その証明書を拒否する必要があります。重要でない拡張は、認識されない場合、無視することができます。

すべてのモバイル・プラットフォームが、特定の証明書拡張を同様に認識または処理するわけではありません。この理由により、できるだけ厳密に RFC に従う必要があります。すべてのターゲット・モバイル・プラットフォームが、証明書拡張を予期したとおりに処理できることが判明している場合以外は、証明書拡張の使用を避けてください。

CRL サポート

証明書が証明書取り消しリスト (CRL) をサポートしている場合は、CRL URL が有効かつアクセス可能であることを確認してください。 そうでない場合、証明書チェーンの検証は失敗します。

サーバー証明書の検証に使用するツール

証明書パス検証の問題をデバッグするには、openssl s_client コマンド・ライン・ツールを実行します。 このツールは、SSL 問題をデバッグする際に役立つ有益な診断情報を生成します。

openssl s_client -CApath $HOME/CAdir -connect hostname:port

openssl x509 -in certificate.crt -text -noout

信頼された認証局によって署名されていないサーバー証明書の問題のトラブルシューティング

basicaConstraints = CA:TRUE

basicConstraints = CA:TRUE