N1 Service Provisioning System 5.1 は、自己署名付き証明書と認証局によって署名される証明書をサポートします。次の 2 種類のキーストアがあります。
プライベートキーストア – アプリケーションがほかのアプリケーションに接続する際にそれ自体の認証に使用する公開 / 非公開鍵ペアが格納されます。
トラストキーストア – キーストアによって信頼されアプリケーションへの接続が許可されるその他のアプリケーションの公開鍵が、自己署名付き証明書の形で格納されます。
「クライアントとサーバーの相互認証」で SSL を有効にした場合は、有効にした各アプリケーションに、SSL が使用する 2 つのキーストアを構成する必要があります。その 1 つは、SSL がほかのアプリケーションに対しそれ自体を認証するためのキーストアで、もう 1 つはほかのアプリケーションを認証するためのキーストアです。
「サーバーのみの認証」で SSL を有効にした場合は、SSL サーバーとして機能するアプリケーションにはプライベートキーストア、SSL クライアントとして機能するアプリケーションには公開 (トラステッド) キーストアが必要になります。公開キーストアは、Java Secure Sockets Extension (JSSE) v1.0.3 によって提供されている独自の JKS フォーマットになります。
これらのキーストアは、どちらもパスワードを指定する必要があります。このパスワードは、両キーストアで同一のものでなければなりません。
例として、アプリケーション A (SSL クライアント) とアプリケーション B (SSL サーバー) を SSL を使用して相互接続する場合を考えてみましょう。両方とも、サーバー認証を要求する暗号群を使用するように構成されています。アプリケーション B は、そのプライベートキーストアに公開 / 非公開鍵ペアが格納されていなければなりません。一方アプリケーション A は、そのトラストキーストアにアプリケーション B の公開鍵が格納されていなければなりません。アプリケーション A がアプリケーション B への接続を試みると、アプリケーション B はアプリケーション A に公開鍵を送信します。アプリケーション A は、トラストキーストア内にこの公開鍵が入っているかを確認することによってこの鍵を検証できます。
クライアント認証を要求するようにアプリケーション B が構成されている場合、アプリケーション A のプライベートキーストアには公開 / 非公開鍵ペアが格納されていなければなりません。同時に、アプリケーション B のトラストキーストアにはアプリケーション A の公開鍵が格納されている必要があります。アプリケーション A がアプリケーション B の認証を行なったあと、アプリケーション B はそのトラストキーストアに鍵が入っているかを確認することによってアプリケーション A の公開鍵を検証できます。
crkeys コマンドを使用してキーストアを生成する場合は、-mode upstream|downstream オプションを使用して、認証を実行しているマシンとの関係上での認証されているマシンの場所を指定します。SSL 接続の試行時には、接続の妥当性検査を行うサーバーが、証明書を送信したサーバーの相対的な位置に一致するモードが受信した証明書に含まれていることを確認します。たとえば、ローカルディストリビュータがマスターサーバーから SSL 接続要求を受信するとします。ローカルディストリビュータは、マスターサーバー証明書に downstream 注釈が含まれていないことを確認します。
サーバーは、証明書に upstream 注釈が含まれているかは確認しません。サーバーが確認するのは、証明書に downstream 注釈が含まれていないことだけです。この結果、元々 upstream 注釈なしの SSL を使用するように構成されていたサーバーはいずれも、引き続き SSL を接続に使用します。
CLI クライアントからアップストリームになれるサーバーはないため、CLI クライアントは、upstream 注釈のある証明書を転送するサーバーとの接続の妥当性を証明できません。リモートエージェントからダウンストリームになれるサーバーはないため、リモートエージェントは、downstream 注釈のある証明書を転送するサーバーとの接続の妥当性を証明できません。