このモジュールでは、ローカルで有効な証明書（LSC）を使用するように Cisco Catalyst 9800 シリーズ ワイヤレス コントローラ および Lightweight アクセスポイント（LAP）を設定する方法について説明します。LSC を使用する公開キーインフラストラクチャ（PKI）を選択した場合は、AP とコントローラで LSC を生成でき、証明書を使用してコントローラと AP を手動で認証できます。

シスコ コントローラでは、LSC を使用するようにコントローラを設定できます。独自の PKI でセキュリティを強化して認証局（CA）を管理し、生成された証明書でポリシー、制約事項、および使用方法を定義する場合は、LSC を使用します。

コントローラで新しい LSC 証明書をプロビジョニングし、CA サーバーから Lightweight アクセスポイント（LAP）をプロビジョニングする必要があります。

LAP は、CAPWAP プロトコルを使用してコントローラと通信します。証明書への署名と、LAP およびコントローラ自体の CA 証明書の発行についての要求は、コントローラから開始する必要があります。LAP は CA サーバーと直接通信しません。CA サーバーの詳細がコントローラで設定されていて、アクセス可能である必要があります。

コントローラは、デバイス上で生成された certReqs を CA に転送するために Simple Certificate Enrollment Protocol（SCEP）を使用し、CA から署名済み証明書を取得するために SCEP を再度使用します。

SCEP は、証明書の登録と失効をサポートするために PKI クライアントと CA サーバーで使用される証明書管理プロトコルです。SCEP はシスコで広く使用され、多くの CA サーバーでサポートされています。SCEP では、HTTP は PKI メッセージのトランスポートプロトコルとして使用されます。SCEP の主な目的は、ネットワーク デバイスに証明書を安全に発行することです。SCEP は多くの操作に対応していますが、このリリースでは次の操作に使用されています。

• CA およびルータアドバタイズメント（RA）公開キーの配布

• 認証登録

• LSC ワークフローは、FIPS + WLANCC モードでは異なります。CA サーバーは Enrollment over Secure Transport（EST）プロトコルをサポートし、FIPS + WLANCC モードで EC 証明書を発行できる必要があります。

• 楕円曲線デジタル署名アルゴリズム（ECDSA）暗号は、AP とコントローラの両方に LSC でプロビジョニングされた EC 証明書がある場合にのみ機能します。

• EC 証明書（LSC-EC）は、CA サーバーが（SCEP ではなく）EST をサポートしている場合にのみプロビジョニングできます。

• EC 証明書をプロビジョニングするには、FIPS + CC セキュリティモードを設定する必要があります。

• LSC を有効にする前に、すべての AP の設定不備を修正する必要があります。設定に不備がある AP の数は、次の show コマンドの出力で確認できます。

  Device# show wireless summary
  Priming controller         : DISABLED
  Max APs supported          : 3000
  Max clients supported      : 32000
  Access Point Summary
                        Total    Up    Down
  ------------------------------------------
  802.11 2.4GHz             2     2       0
  802.11 5GHz               5     2       3
  802.11 6GHz               1     1       0
  802.11 dual-band          2     0       2
  802.11 dual-band(5/6GHz)  0     0       0
  802.11 rx-dual-band       0     0       0
  Client Serving(2.4GHz)    3     1       2
  Client Serving(5GHz)      4     1       3
  Client Serving(6GHz)      1     1       0
  Monitor(Dual band)        0     0       0
  Monitor(2.4GHz)           1     1       0
  Monitor(5GHz)             1     1       0
  Monitor(6GHz)             0     0       0
  Sniffer(Dual band)        0     0       0
  Sniffer(2.4GHz)           0     0       0
  Sniffer(5GHz)             0     0       0
  Sniffer(6GHz)             0     0       0
  Misconfigured APs         1 (For more info use 'show ap tag summary')
  Client Summary
    Total Clients : 0
    Excluded      : 0
    Disabled      : 0
    Foreign       : 0
    Anchor        : 0
    Local         : 0

  設定に不備がある AP の詳細については、wireless config validate コマンドを実行します。報告されたエラーを表示するには、show wireless config validation status コマンドを実行します。

Cisco IOS XE Bengaluru 17.4.1 以前のリリースでは、デフォルトの証明書（製造元でインストールされる証明書（MIC）または Secure Unique Device Identifier（SUDI））を持つ AP は、ローカルで有効な証明書（LSC）が展開されたコントローラには接続できません。このコントローラの管理証明書は LSC です。この問題を解決するには、LSC が展開されたコントローラに移動する前に、プロビジョニング コントローラを使用してそれらの AP に LSC をプロビジョニングする必要があります。

Cisco IOS XE Bengaluru 17.5.1 以降では、新しい認証ポリシー設定により、MIC AP を LSC が展開されたコントローラに接続でき、LSC と MIC AP がコントローラ内で同時に共存できるようになりました。

• CA サーバーが証明書署名要求（CSR）を受け入れるように手動登録（手動介入）で構成されている場合、コントローラは CA サーバーが保留中の応答を送信するのを待ちます。10 分間 CA サーバーからの応答がない場合、フォールバックモードが有効になります。

  • Cisco Wave 2 AP が CSR を再生成し、新しい CSR が CA サーバーに送信されます。

  • Cisco IOS AP が再起動すると、Cisco IOS AP から新しい CSR が送信され、CA サーバーにも送信されます。

• コントローラのローカルで有効な証明書（LSC）は、パスワードチャレンジでは機能しません。このため、LSC を機能させるには、CA サーバーでパスワードの確認を無効にする必要があります。

• Microsoft CA を使用している場合は、CA サーバーとして Windows Server 2012 以降を使用することをお勧めします。

AP が CAPWAP 用の LSC を使用して設定されているが、DTLS 接続を確立できない場合、AP は再起動し、一定の回数再試行します。LSC を使用した AP の設定方法については、 LSC 証明書による AP の参加試行回数の設定（CLI）を参照してください。

AP は、最大失敗回数に達すると、CAPWAP 用のデフォルトの証明書（MIC）にフォールバックします。この状態は、LSC フォールバックと呼ばれます。

（注）	MIC は SUDI 証明書とも呼ばれます。

LSC フォールバック状態の AP がコントローラに参加すると、次の syslog が生成されます。

Jun 15 23:24:14.836: %APMGR_TRACE_MESSAGE-3-WLC_GEN_ERR: Chassis 1 R0/0: wncd: Error 
in AP: 'AP2c5a.0f70.84dc' with address 70db.9888.cc20 is joined with MIC, while configuration 
requires LSC. No WLANs will be pushed.

コントローラはそのような AP が MIC に参加することを許可し（AP 証明書ポリシーで許可されている場合）、AP は誤って設定された状態で保持されます。

（注）	このような状態では、AP は WLAN または SSID 構成をブロードキャストしません。これにより、管理者は以前の障害の理由を調べて AP を回復できます。

次のように show wireless summary を使用して、LSC フォールバック AP を特定できます。

Device# show wireless summary
…
Access Point Summary
… 
DTLS LSC fallback APs     20 (No WLANs will be pushed to these APs)
…
For more information on DTLS LSC fallback APs,
    execute 'wireless config validate' and look for reported errors in
    'show wireless config validation status' CLI output.
 
Use 'show ap config general | inc AP Name | LSC fallback' to list DTLS LSC fallback APs.
Examine LSC fallback reasons / DTLS handshake failures with LSC then
    issue 'ap lsc dtls-fallback clear-certificate / clear-flag' to recover APs

• ap lsc dtls-fallback clear-flag を使用して AP の LSC フォールバックフラグをクリアし、リロードするよう AP に指示します。

  （注）	AP は、リロード後に CAPWAP DTLS 接続に LSC を再利用します。

• ap lsc dtls-fallback clear-certificate を使用して LSC をクリアし、リロードするよう AP に指示します。

  （注）	AP は、リロード後に CAPWAP-DTLS に MIC を使用します。Dot1x ポート認証に LSC が使用されている場合は、AP 認証のためにスイッチポートでさらにリカバリが必要になります。

（注）	AP で LSC を保持するには、ap lsc dtls-fallback clear-flag コマンドで十分です。ap lsc dtls-fallback clear-flag コマンドと ap lsc dtls-fallback clear-certificate コマンドを同時に使用する必要はありません。 リカバリコマンドを発行するときは、AP が接続状態である必要があります。後で LSC フォールバックの AP が参加した場合は、コマンドを再発行する必要があります。

• VLAN インターフェイスが稼働しており、その IP に到達可能であることを確認します。

• ip http server が有効であることを確認します。詳細については、「HTTP サーバーの有効化」を参照してください。

• clock calendar-valid コマンドを適切に設定します。詳細については、を参照してください。

• PKI CA サーバーがすでに構成されているかどうかを確認します。構成されている場合は、既存の CA サーバー構成を削除する必要があります。

  （注）	show crypto pki server コマンドの出力に何も表示されない必要があります。