• NX-API CLI は、スイッチで Cisco NX-OS CLI を実行するために VSH を生成します。VSH のタイムアウトは 5 分です。Cisco NX-OS CLI の実行に 5 分以上かかると、コマンドは失敗し、「Back-end processing error.」というメッセージが表示されます。これは、NX-API コマンドのタイムアウトによって制御されます。これは、NX-API を介して要求されたコマンドを実行できる時間を制御します。この値は 300 秒に固定されており、変更できません。

• Cisco NX-OS リリース 10.2(1)F 以降では、 system server session cmd-timeout を使用してタイムアウトを増やすことができます。

• NX- API はワーカープロセスを生成し、複数のワーカープロセスがリクエストを均等に負担するようにします。

  • nginx のバックエンドワーカープロセスの数は 4 です。

  • N3k および低メモリベースプラットフォームの nginx バックエンドワーカープロセスの数は 2 です。

• 各ワーカープロセスは、5 つの永続的な VSH セッションのプールを維持します。各 VSHセッションは、着信リクエストからのユーザー名とリモート IP の組み合わせで一意に識別されます。新しいリクエストが来るたびに、ワーカー プロセスは一致するユーザー名とリモート IP エントリがすでに存在するかどうかを確認します。存在する場合は、対応する VSH セッションを使用します。存在しない場合は、プール内の可用性に基づいて新しい VSH セッションが作成され、新しいエントリがプールに追加されます。ワーカープロセスがすでに最大許容 VSH セッションを実行している場合、新しいリクエストは拒否され、適切なエラー メッセージが応答で返されます。

• ワーカープロセスごとの VSH セッション数はハードコードされた値であり、構成することはできません。任意の時点で存在できるセッションの合計数は 20 です。

• NX-API に関連付けられているトラストポイント、証明書、またはキーが削除されても、NX-API は NX-API 証明書、トラストポイント、または NX-API クライアント証明書の認証設定を保持します。そのため、NX-API 機能には影響が及びます。NX-API の現在のインスタンスは正常に動作しますが、NX-API コマンドの再構成によってインスタンスが破損する可能性があります。これを防ぐには、no crypto ca trustpoint コマンドを使用してトラストポイントまたは証明書を削除するときに、NX-API 設定も削除または更新することが重要です。

チャンクモード

• チャンクモードは、2 つの同時セッションのみをサポートします。チャンクオプションが選択されている場合、一度に 2 つの並列セッションでのみ指定できます。

• リリース 10.3(1)F リリースまで、チャンク モードでサポートされる応答の最大サイズは 200 MB です。

• 10.3(1)F リリース以降、チャンクモードは、スペースが揮発性領域（約 2.0GB）で使用可能である限り、応答サイズをサポートします。チャンクモード応答がサポートするサイズは、揮発性領域のスペースによって異なります。揮発性領域の 90% がいっぱいになると、その後最初に show 出力がファイルに収集されたとき、チャンクモードは失敗を返します。各応答でサポートされるチャンクサイズは 10 MB です。

証明書認証には次の注意事項と制約事項があります。

• NX-API クライアントには、ユーザ名とパスワードを設定する必要があります。

• NX-API クライアントとスイッチは、デフォルトでウェルノウン ポートで HTTP を介して通信します。柔軟性を高めるために、HTTP は既知のポートでもサポートされます。ただし、追加のポートを設定できます。

• クライアント証明書認証の Python スクリプティングがサポートされています。クライアント証明書がパスフレーズで暗号化されている場合、python はパスフレーズの入力を正常に要求します。ただし、Python 要求ライブラリの現在の制限により、パスフレーズをスクリプトに渡すことはできません。

• NX-API クライアントとスイッチは、同じトラストポイントを使用する必要があります。

• サポートされるトラストポイントの最大数は、スイッチごとに 26 です。

• 信頼できる CA のリストは、すべての NX-API クライアントとスイッチで同じである必要があります。信頼できる CA の個別のリストはサポートされていません。

• 証明書認証は、NX-API サンドボックスではサポートされていません。

• 次の条件によって、NX-API サンドボックスがスイッチにロードされるかどうかが決まります。

  • NX-API サンドボックスは、 または が設定されている場合にのみロードされます。nxapi client certificate authentication optional no nxapi client certificate authentication

  • NX-API サンドボックスは、接続の確立時に有効なクライアント証明書がブラウザに提示されない限り、 および認証モードをロードしません。strict two-step

• スイッチには NGINX サーバーが組み込まれています。複数のトラストポイントが設定されているが、証明書失効リスト（CRL）が 1 つのトラストポイントのみにインストールされている場合、NGINX の制限により NX-API クライアント証明書認証は失敗します。この制限を回避するには、すべてのトラストポイントに CRL を設定します。

• 証明書は期限切れになったり、期限切れになったりする可能性があり、CA（トラストポイント）によって設定された CRL の有効性に影響を与える可能性があります。スイッチが有効な CRL を使用するようにするには、設定されているすべてのトラストポイントに必ず CRL をインストールしてください。トラストポイントによって証明書が失効しなかった場合は、空の CRL を生成、インストール、および更新する必要があります。たとえば、週に 1 回などです。

  暗号化 CLI を使用して CRL を更新した後、 を発行して、新しく更新された CRL を再適用します。nxapi client cert authentication

• NX-API クライアント証明書認証が有効になっているときに ASCII リロードを使用する場合は、リロードの完了後に を発行する必要があります。nxapi client certificate authentication

• 証明書パスは信頼済み CA 証明書で終了している必要があります。

• TLS 用に提示されるサーバー証明書には、extendedKeyUsage フィールドにサーバー認証目的（OID 1.3.6.1.5.5.7.3.1 の id-kp 1）が必要です。

• TLS 用に提示されるクライアント証明書には、extendedKeyUsage フィールドにサーバー認証目的（OID 1.3.6.1.5.5.7.3.2 の id-kp 1）が必要です。

• この機能は、CRL（証明書失効リスト）をサポートします。オンライン証明書ステータス プロトコル（OCSP）はサポートされていません。

• 『NX-OS Security Guide』の追加のガイドラインと制限事項に従ってください。

  • 証明書と基本認証の両方を使用します。そうすることで、証明書が何らかの理由で侵害された場合でも、正しいユーザーとパスワードが必要になります。

  • サーバーの公開キーには接続を試みるすべてのユーザーがアクセスできるため、秘密キーは秘密にしておきます。

  • CRL は中央 CA からダウンロードし、最新の状態に保つ必要があります。古い CRL はセキュリティリスクにつながる可能性があります。

  • トラストポイントを最新の状態に保つ。トラストポイントまたは設定変更が証明書認証機能に加えられた場合は、更新された情報をリロードするために、この機能を明示的にディセーブルにしてから再度イネーブルにします。

• nxapi certificate httpscert certfile bootflash: これは Day-1 の制限です。

• [NX-API Management Commands] 表 1 で、コマンド nxapi certificate {httpscrt certfile | httpskey keyfile} ファイル名の場合、サポートされる certfile の最大サイズは 8K 未満です。

証明書認証を設定する前に、スイッチで次の操作を実行済みであることを確認してください。

1. クライアントでユーザー名とパスワードを構成します。詳細については、「ユーザー アカウントおよび RBAC の構成」を参照してください。

2. CA（トラストポイント）と CRL（存在する場合）を構成します。

トラストポイントによって失効した証明書がない場合は、トラストポイントごとに空白の CRL を作成します。

詳細については、『Cisco Nexus 9000 シリーズ NX-OS セキュリティ設定ガイド』を参照してください。

次の例は、認証用のクライアント証明書を使用した Python スクリプトを示しています。

import requests
import json

"""
Modify these please
"""
switchuser='USERID'
switchpassword='PASSWORD' 
mgmtip='NXOS MANAGEMENT IP/DOMAIN NAME'

client_cert_file='PATH_TO_CLIENT_CERTIFICATE'
client_key_file='PATH_TO_CLIENT_KEY_FILE'
ca_cert='PATH_TO_CA_CERT_THAT_SIGNED_NXAPI_SERVER_CERT'

url='https://' + mgmtip + '/ins'
myheaders={'content-type':'application/json-rpc'}
payload=[
  {
    "jsonrpc": "2.0",
    "method": "cli",
    "params": {
      "cmd": "show clock",
      "version": 1
    },
    "id": 1
  }
]
response = requests.post(url,data=json.dumps(payload), headers=myheaders,auth=(switchuser,switchpassword),cert=(client_cert_file_path,client_key_file),verify=ca_cert).json()

必要に応じて、スクリプトを変更できます。

• クライアント証明書認証モードによっては、スイッチ パスワードをヌル値に設定することで（switchpassword= ）、スイッチ パスワードを省略できます。

  • optional および strict モードの場合、switchpassword= は空白のままにできます。この場合、NX-API はユーザー名とクライアント証明書のみに基づいてクライアントを認証します。

  • two-step モードの場合、パスワードが必要なため、switchpassword= の値を指定する必要があります。

• POST コマンドで verify=False を設定することで、NX-API サーバの証明書が有効であることの確認をバイパスできます。

次に、NX-API クライアント認証用の正しく構造化された cURL 証明書要求の例を示します。

/usr/bin/curl --user admin: --tlsv1.2 --cacert ./ca.pem --cert ./user.crt:pass123! --key ./user.key -v -X POST -H "Accept: application/json" -H "Content-type: application/json" --data '{"ins_api":{"version": "1.0", "type": "cli_show", "chunk": "0", "sid": "1", "input": "show clock","output_format": "json"}}' https://<device-management-ip>:443/ins

構文要素

次の表は、この要求で使用されるパラメータを示しています。