Edge での SNI の使用

Server Name Indication（SNI）を使用すると、複数の HTTPS ターゲットが、同じ TLS 証明書を使用せずに同じ IP アドレスとポートからサービスを提供できます。SNI が有効になっているクライアントは、初期 TLS handshake の一環としてターゲット エンドポイントのホスト名を渡します。これにより、TLS サーバーはどの TLS 証明書を使用してリクエストを検証すればよいかを判断できます。

たとえば、リクエストのターゲットが https://example.com/request/path の場合、TLS クライアントは次のように server_name 拡張を TLS handshake リクエストに追加します。

Edge は、以下のリクエストで SNI をサポートしています。

  • クライアント アプリから API プロキシへのリクエスト。この場合、Edge は TLS サーバーとして動作します。
  • Edge からバックエンドへのリクエスト。この場合、Edge は TLS クライアントとして動作します。

SNI の詳細については、以下を参照してください。

Edge 上の API プロキシへのリクエストに対する SNI のサポート

API プロキシへのリクエストに対する SNI のサポートは、ホスト エイリアスと仮想ホストによって制御されます。

仮想ホストとホスト エイリアスについて

Edge 上の仮想ホストは、API プロキシが公開される IP アドレスとポート、または DNS 名とポートを定義します。また、拡張により、アプリから API プロキシへのアクセスに使用される URL も定義します。IP アドレス / DNS 名は Edge Router に対応しており、ポート番号は Router 上のオープンポートです。

仮想ホストを作成するときは、仮想ホストのホスト エイリアスも指定します。通常、これは仮想ホストの DNS 名です。Router は、リクエストを処理する API プロキシを決定するプロセスの一環として、受信リクエストの Host ヘッダーを、すべての仮想ホストで定義されている使用可能なホスト エイリアスのリストと比較します。

仮想ホストのホスト エイリアスとポート番号の組み合わせは、Edge インストール環境のすべての仮想ホストの間で一意でなければなりません。つまり、ホスト エイリアスが違っていれば、複数の仮想ホストで同じポート番号を使用できます。

また、仮想ホストは、API プロキシへのアクセスに HTTP プロトコルと TLS を使用した暗号化 HTTPS プロトコルのどちらを使用するかも定義します。仮想ホストで HTTPS を使用するように構成する場合は、仮想ホストを、TLS handshake 中に仮想ホストによって使用される証明書と秘密鍵が格納されたキーストアに関連付けます。

仮想ホストの詳細については、以下をご覧ください。

SNI とホスト エイリアスの連携の仕組み

SNI を使用すると、それぞれ異なる TLS 証明書と鍵を持つ複数の仮想ホストを同じポート上に定義できます。Edge は、TLS handshake リクエストに含まれる server_name 拡張に基づいて、仮想ホストと、TLS によって使用される証明書 / 鍵のペアを決定します。

Edge Router は、TLS handshake リクエスト内の server_name 拡張を読み取り、それを使用してすべての仮想ホストのホスト エイリアスを検索します。ホスト エイリアスとの一致が検出されると、Router はそのホスト エイリアスに関連付けられている仮想ホストの TLS 証明書と鍵を使用します。一致するものが見つからない場合、TLS handshake は失敗します。

TLS handshake の失敗を防ぐため、デフォルトの証明書 / 鍵ペアを定義できます。これについて次のセクションで説明します。

Edge for Cloud でのデフォルト証明書 / 鍵ペアの定義

Apigee は、HTTPS をサポートするための TLS 証明書と秘密鍵を提供しています。多くのお客様はデプロイ時に独自の証明書と秘密鍵を使用しますが、Apigee 証明書と鍵を使用して API をデプロイすることもできます。

Edge for Cloud では、SNI ヘッダーとホスト エイリアスの一致が見つからない場合、またはクライアントで SNI がサポートされていない場合に、Router で Apigee 提供のデフォルト証明書（*.apigee.net）が使用されます。

Edge for Private Cloud でのデフォルト証明書 / 鍵ペアの定義

Edge for Private Cloud では、server_name 拡張とすべての仮想ホストのホスト エイリアスとの間で一致するものが見つからない場合、またはリクエスト側クライアントで SNI がサポートされていない場合に、デフォルト仮想ホストの証明書 / 鍵をそのポートに対して使用するように Router を構成できます。デフォルト仮想ホストは、組織名、環境名、仮想ホスト名を次の形式で組み合わせて定義されます。

orgName_envName_vhName

Router は、orgName_envName_vhName の組み合わせがアルファベット順で最初に来る仮想ホストの証明書 / 鍵を使用します。たとえば、環境 prod の組織 example に次の 2 つの仮想ホストが定義されていて、リクエストがポート 443 に到着するとします。

  • 仮想ホスト名 = default
  • 仮想ホスト名 = test

この例では、example_prod_default の方が example_prod_test よりもアルファベット順で前に来るため、Router は仮想ホスト default の証明書 / 鍵を使用します。

デフォルト仮想ホストを有効にするには:

  1. 最初の Router ノードで、/opt/apigee/customer/application/router.properties を編集します。このファイルが存在しない場合は作成します。
  2. デフォルト仮想ホストを定義できるようにするため、次のプロパティをファイルに追加します。 
    conf_load_balancing_load.balancing.driver.nginx.fallback.conf.enabled=true
  3. Router を再起動します。 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  4. 残りのすべての Router で、この手順を繰り返します。

デフォルト仮想ホストの証明書 / 鍵を使用する代わりに、Router でデフォルトの証明書 / 鍵を明示的に定義することもできます。デフォルトの証明書 / 鍵ペアを明示的に定義するには、次の手順に従います。

  1. 最初の Router ノードで、apigee ユーザーがアクセスできる Router ノード上の場所に証明書と秘密鍵をコピーします。たとえば、/opt/apigee/customer/application にコピーします。
  2. ファイルの所有権を apigee ユーザーに変更します。 
    chown apigee:apigee /opt/apigee/customer/application/myCert.pem
     
    chown apigee:apigee /opt/apigee/customer/application/myKey.pem
  3. /opt/apigee/customer/application/router.properties を編集します。このファイルが存在しない場合は作成します。
  4. デフォルトの証明書 / 鍵を指定できるようにするため、次のプロパティをファイルに追加します。
    conf_load_balancing_load.balancing.driver.nginx.fallback.server.default.ssl.template.enabled=true
    conf_load_balancing_load.balancing.driver.nginx.fallback.conf.enabled=true
  5. router.properties で次のプロパティを設定し、証明書と鍵の場所を指定します。 
    conf_load_balancing_load.balancing.driver.nginx.ssl.cert=/opt/apigee/customer/application/myCert.pem
conf_load_balancing_load.balancing.driver.nginx.ssl.key=/opt/apigee/customer/application/myKey.pem
  6. Router を再起動します。 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  7. 残りのすべての Router で、この手順を繰り返します。

Edge からバックエンドへのリクエストに対する SNI のサポート

Apigee Edge for Cloud と Apigee Edge for Private Cloud のどちらにおいても、Message Processor からターゲット エンドポイントへの SNI を使用できます。デフォルトでは、Edge Message Processor での SNI は、Cloud では有効、Private Cloud では無効になっています。

Edge for Private Cloud でのバックエンド向け SNI の使用

Edge for Private Cloud では、既存のターゲット バックエンドとの下位互換性を保つため、SNI はデフォルトで無効になっています。ターゲット バックエンドが SNI をサポートするように構成されている場合は、ご使用の Edge バージョンに応じて、下記の方法でこの機能を有効にできます。

これ以外の Edge 固有の構成は必要ありません。ターゲット環境で SNI が構成されている場合、Edge は SNI をサポートします。Edge はリクエスト URL からホスト名を自動的に抽出し、それを TLS handshake リクエストに追加します。

Edge とバックエンドの間で SNI を有効にする（Edge バージョン 4.15.07.0x の場合）

SNI を有効にするには:

  1. 最初の Message Processor ノードで、/opt/apigee4/conf/apigee/message-processor/system.properties ファイルをエディタで開きます。
  2. system.properties で次のプロパティを true に設定します。 
    jsse.enableSNIExtension=true
  3. Message Processor を再起動します。 
    /opt/apigee4/bin/apigee-service message-processor restart
  4. 残りのすべての Message Processor で上記の手順を繰り返します。

Edge とバックエンドの間で SNI を有効にする（Edge バージョン 4.16.01 以降）

SNI を有効にするには:

  1. 最初の Message Processor ノードで、/opt/apigee/customer/application/message-processor.properties を編集します。このファイルが存在しない場合は作成します。
  2. ファイルに次のプロパティを追加します。 
    conf_system_jsse.enableSNIExtension=true
  3. Message Processor を再起動します。 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  4. 残りのすべての Message Processor で上記の手順を繰り返します。