NetScaler Ingress ControllerにおけるTLS証明書の処理

最終公開日 : Oct 02, 2026

NetScaler Ingress Controllerは、NetScalerのSSLベースの仮想サーバー向けにTLS証明書を設定するオプションを提供します。SSL仮想サーバーはSSLトラフィックを傍受し、復号化して処理した後、仮想サーバーにバインドされているサービスに送信します。

デフォルトでは、SSL仮想サーバーは1つのデフォルト証明書にバインドでき、アプリケーションは証明書にバインドされたポリシーに基づいてトラフィックを受信します。ただし、Server Name Indication (SNI) オプションを使用すると、複数の証明書を単一の仮想サーバーにバインドできます。NetScalerは、TLSハンドシェイクのドメイン名に基づいて、クライアントに提示する証明書を決定します。

NetScaler Ingress Controllerは、以下の3つの方法で証明書を処理します。

NetScaler Ingress Controllerのデフォルト証明書
事前設定された証明書
Ingress YAMLのTLSセクション

前提条件

NetScaler Ingress Controllerを使用してTLS証明書を処理するには、アプリケーションに対してNetScalerでTLSサポートを有効にする必要があります。また、Kubernetesデプロイメントで証明書を使用している場合は、証明書を使用してKubernetesシークレットを生成する必要があります。

アプリケーション向けにNetScalerでTLSサポートを有効にする

NetScaler Ingress Controllerは、Ingress定義のTLSセクションをNetScalerでのTLSサポートを有効にするものとして使用します。

注:

デフォルト証明書がある場合、または事前設定された証明書がある場合は、TLSを有効にするために、Ingress定義の***spec.tls.secretname***フィールドに空のシークレットを追加する必要があります。

Ingress定義の以下のサンプルスニペット:

spec:
   tls:
   - secretName:

Kubernetesシークレットを生成する

既存の証明書用のKubernetesシークレットを生成するには、次のkubectlコマンドを使用します。

     kubectl create secret tls k8s-secret --cert=path/to/tls.cert --key=path/to/tls.key  --namespace=default
 
     secret “k8s-secret” created

このコマンドは、tls.crtキーの下にPEM形式の証明書を、tls.keyキーの下にPEM形式の秘密鍵を持つKubernetesシークレットを作成します。

または、次のYAML定義を使用してKubernetesシークレットを生成することもできます。

apiVersion: v1
 kind: Secret
 metadata:
   name: k8s-secret
 data:
   tls.crt: base64 encoded cert
   tls.key: base64 encoded key

kubectl -create <file-name>コマンドを使用してYAMLをデプロイします。これにより、tls.crtキーの下にPEM形式の証明書、tls.keyキーの下にPEM形式の秘密鍵を持つKubernetesシークレットが作成されます。

NetScaler Ingress Controllerのデフォルト証明書

NetScaler Ingress Controllerで提供されるデフォルトのシークレットは、NetScalerでSSLおよびSSL SNI証明書を設定するために使用できます。非SNI証明書とSNI証明書をそれぞれ設定するためのシークレットを提供するには、default-sni-certificateとdefault-ssl-sni-certificate引数を使用できます。NetScaler Ingress ControllerのデプロイYAMLファイルで引数を指定する際は、シークレット名と、クラスター内でシークレットがデプロイされている名前空間を次のように指定します。

デフォルト証明書を非SNI証明書として使用するためにYAMLファイルに追加する引数: --default-ssl-certificate <NAMESPACE>/<SECRET_NAME>。
デフォルト証明書をSNI証明書として使用するためにYAMLファイルに追加する引数: --default-ssl-sni-certificate <NAMESPACE>/<SECRET_NAME>

注:

Helmチャートまたはオペレーターを使用してNetScaler Ingress Controllerをデプロイする場合、両方のデフォルトシークレットは、NetScaler Ingress Controllerがデプロイされているのと同じ名前空間にデプロイする必要があります。NetScaler Ingress Controllerのインストール中に、非SNIシークレット名をdefaultSSLCertSecretパラメーターに、SNIシークレット名をdefaultSSLSNICertSecretパラメーターに指定します。例: defaultSSLCertSecret: <non-SNI secret name>; defaultSSLSNICertSecret: <SNI secret name>。

以下は、ssl名前空間から取得され、NetScaler Ingress Controllerのデフォルト証明書として提供されるTLSシークレット (hotdrink.secret) を含むNetScaler Ingress Controller YAML定義ファイルのサンプルです。

注:

名前空間は、有効なSECRET_NAMEとともに必須です。

apiVersion: v1
 kind: Pod
 metadata:
   name: cic
   labels:
     app: cic
 spec:
   serviceAccountName: cpx
   containers:
   - name: cic
     image: "xxxx"
     imagePullPolicy: Always
     args:
     - --default-ssl-certificate
       ssl/hotdrink.secret
     env:
     # Set NetScaler Console Management IP
     - name: "NS_IP"
       value: "xx.xx.xx.xx"
     # Set port for Nitro
     - name: "NS_PORT"
       value: "xx"
     # Set Protocol for Nitro
     - name: "NS_PROTOCOL"
       value: "HTTP"
     # Set username for Nitro
     - name: "NS_USER"
       value: "nsroot"
     # Set user password for Nitro
     - name: "NS_PASSWORD"
       value: "nsroot"

KubernetesクラスターにおけるKubernetesイングレスに関連するさまざまなシナリオでのNetScaler Ingress Controllerの動作については、次の表を参照してください。

NetScaler Ingress ControllerのデフォルトSSLシークレット	NetScaler Ingress ControllerのデフォルトSSL SNIシークレット	Ingressのホスト	Ingressのシークレット	アクション
はい	いいえ	提供されていません	提供されていません	非SNIシークレットをSSL仮想サーバーの非SNI証明書としてバインドします。
いいえ	はい	提供されていません	提供されていません	デフォルトのSNIシークレットをSSL仮想サーバーのSNI証明書としてバインドします。
はい	はい	提供されていません	提供されていません	非SNIシークレットを非SNI証明書としてバインドします。* SNIシークレットをSNI証明書としてバインドします。* また、複数のシークレットがバインドされるため、非SNIシークレットをSNIとしてバインドします。


はい	いいえ	提供済み	提供されていません	非SNIシークレットをSSL仮想サーバーの非SNI証明書としてバインドします。
いいえ	はい	提供済み	提供されていません	SNIシークレットをSSL仮想サーバーのSNI証明書としてバインドします。
はい	はい	提供済み	提供されていません	非SNIシークレットをSSL仮想サーバーの非SNI証明書としてバインドします。* SNIシークレットをSSL仮想サーバーのSNI証明書としてバインドします。* また、複数のシークレットがバインドされるため、非SNIシークレットもSNI証明書としてバインドします。


任意	任意	提供されていません	提供されています	提供されたシークレットをSSL仮想サーバーの非SNI証明書としてバインドします。
任意	何でも	提供済み	提供済み	SSL仮想サーバーでSNI証明書として提供されたシークレットをバインドします。
何でも	何でも	提供済み/未提供	複数	SSL仮想サーバーでSNI証明書として提供されたすべてのシークレットをバインドします。

OpenShiftクラスター内のOpenShiftルートに関連するさまざまなシナリオにおけるNetScaler Ingress Controllerの動作については、次の表を参照してください。

NetScaler Ingress ControllerのデフォルトSSLシークレット	NetScaler Ingress ControllerのデフォルトSSL SNIシークレット	ルートタイプ	ルート内のキーと証明書	アクション
はい	いいえ	エッジ	提供されていません	非SNIシークレットをSSL仮想サーバーの非SNI証明書としてバインドします。
いいえ	はい	エッジ	提供されていません	デフォルトのSNIシークレットをSSL仮想サーバーのSNI証明書としてバインドします。
はい	はい	エッジ	提供されていません	非SNIシークレットを非SNI証明書としてバインドします。* SNIシークレットをSNI証明書としてバインドします。* また、複数のシークレットがSSL仮想サーバーにバインドされるため、非SNIシークレットをSNIとしてバインドします。


はい	いいえ	再暗号化	提供されていません	非SNIシークレットをSSL仮想サーバーの非SNI証明書としてバインドします。
いいえ	はい	再暗号化	提供されていません	SNIシークレットをSSL仮想サーバーのSNI証明書としてバインドします。
はい	はい	再暗号化	提供されていません	非SNIシークレットをSSL仮想サーバーの非SNI証明書としてバインドします。* SNIシークレットをSNI証明書としてバインドします。* また、複数のシークレットがSSL仮想サーバーにバインドされているため、非SNIシークレットをSNIとしてバインドします。


はい	いいえ	パススルー	提供されていません	非SNIシークレットをSNI証明書としてバインドします。
いいえ	はい	パススルー	提供されていません	SNIシークレットをSSL仮想サーバーのSNI証明書としてバインドします。
はい	はい	パススルー	提供されていません	非SNIシークレットをSSL仮想サーバーのSNI証明書としてバインドします。* SNIシークレットをSSL仮想サーバーのSNI証明書としてバインドします。
はい	はい	パススルー	提供されていません
任意	任意	エッジ	提供済み	提供されたシークレットをSSL仮想サーバーのSNI証明書としてバインドします。
何でも	何でも	再暗号化	提供済み	SSL仮想サーバーでSNI証明書として提供されたシークレットをバインドします。
何でも	何でも	パススルー	OpenShiftは許可しません	NA

事前設定された証明書

NetScaler Ingress Controllerを使用すると、NetScalerにすでに設定されている証明書キーを使用できます。イングレス定義で次のアノテーションを使用して、証明書の詳細を指定する必要があります。

ingress.citrix.com/preconfigured-certkey : '{"certs": [ {"name": "<name>", "type": "default|sni|ca"} ] }'

アノテーション内で複数の証明書の詳細をリストとして提供できます。また、証明書の処理方法を定義することもできます。次のサンプルアノテーションでは、certkey1は非SNI証明書として使用され、certkey2はSNI証明書として使用されています。

ingress.citrix.com/preconfigured-certkey : '{"certs": [ {"name": "certkey1", "type": "default"}, {"name": "certkey2", "type": "sni"} ] }’

証明書の名前とともにtypeパラメーターが指定されていない場合、それはデフォルト（非SNI）タイプと見なされます。

NetScaler Ingress Controllerを使用すると、OpenShiftの外部で実行されているNetScaler VPX/MPX/BLXインスタンス上のルートで、すでに設定されている証明書をアノテーション（イングレスと同様）を使用して使用できます。コンテンツスイッチング仮想サーバー用に設定する必要があるNetScaler上の既存のSSL証明書キーを指定する必要があります。

route.citrix.com/preconfigured-certkey

例:

次の例では、certkey1 は非SNIデフォルト証明書として使用され、certkey2 はSNI証明書として使用されます。

route.citrix.com/preconfigured-certkey : '{"certs": [{"name": "certkey1", "type": "default"}, {"name": "certkey2", "type": "sni"}]}'

注:

NetScaler上に存在する証明書を再利用し、NetScaler Ingress Controllerによって管理されるアプリケーションにバインドしたい場合に、この機能を使用するようにしてください。NetScaler Ingress Controllerは証明書のライフサイクルを管理しません。つまり、証明書を作成または削除するのではなく、必要なアプリケーションにバインドするだけです。

ingress YAML の TLS セクション

Kubernetes では、ingress 定義の spec: セクションで TLS シークレットを提供できます。このセクションでは、NetScaler Ingress Controller がこれらのシークレットをどのように使用するかを説明します。

ホストセクションを使用する場合

シークレット名がホストセクションとともに提供された場合、NetScaler Ingress Controller はそのシークレットをSNI証明書としてバインドします。

spec:
   tls:
   - secretName: fruitjuice.secret
     hosts:
     - items.fruit.juice

ホストセクションを使用しない場合

シークレット名がホストセクションなしで提供された場合、NetScaler Ingress Controller はそのシークレットをデフォルト証明書としてバインドします。

spec:
   tls:
   - secretName: colddrink.secret

注:

複数のシークレットが指定された場合、NetScaler Ingress Controller はすべての証明書をSNI対応証明書としてバインドします。

注意点

複数のシークレットがNetScaler Ingress Controllerに提供される場合、以下の優先順位が適用されます。
1. preconfigured-default-certkey または非ホスト TLS シークレット
2. デフォルトSSL証明書
同一グレードの証明書間で優先順位の競合がある場合（例えば、2つのIngressファイルがそれぞれ非ホストTLSシークレットをデフォルト/非SNIタイプとして構成している場合）、NetScaler Ingress Controllerは、NetScaler Ingress Controllerのデフォルト証明書を非SNI証明書としてバインドし、他のすべての証明書をSNIで使用します。
TLSセクションで指定されたシークレットに使用される証明書にはCN名が必要です。そうでない場合、NetScalerにバインドされません。
SSL仮想サーバーでSNIが有効になっている場合：
- 非SNI（デフォルト）証明書は、以下のHTTPSリクエストに使用されます。
  curl -1 -v -k https://1.1.1.1/ curl -1 -v -k -H 'HOST:*.colddrink.beverages' https://1.1.1.1/
- SNIが有効な証明書は、完全なドメイン名を持つリクエストに使用されます。
  curl -1 -v -k https://items.colddrink.beverages/
  証明書と一致しないリクエストが受信された場合、CN名が一致しないため、失敗します。