CUCMを使用したIP PhoneでのLSCの設定

はじめに

このドキュメントでは、Cisco Internet Protocol Phone(Cisco IP Phone)にローカルで有効な証明書(LSC)をインストールする方法について説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• Cisco Unified Communications Manager(CUCM)クラスタセキュリティモードオプション
• X.509 証明書
• 製造元でインストールされる証明書(MIC)
• LSC
• Certificate Authority Proxy Function(CAPF)証明書操作
• デフォルトのセキュリティ(SBD)
• 初期信頼リスト(ITL)ファイル

使用するコンポーネント

このドキュメントの情報は、SBDをサポートするCUCMのバージョン、つまりCUCM 8.0(1)以降に基づいています。

注：この問題が該当するのは、デフォルトのセキュリティ(SBD)をサポートしている電話機だけです。たとえば、7940および7960電話機はSBDをサポートしておらず、7935、7936、および7937会議電話機もサポートしていません。ご使用のCUCMバージョンのSBDをサポートするデバイスのリストを確認するには、Cisco Unified Reporting > System Reports > Unified CM Phone Feature Listの順に移動し、Feature: Security By Defaultに関するレポートを実行します。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

Cisco Authority Proxy Function(CAPF)サービスは、パブリッシャノードでのみ実行されます。パブリッシャは、LSCの認証局(CA)または署名者として機能します。

MICとLSC

802.1XまたはAnyConnect電話VPNに証明書ベースの認証を使用する場合、MICとLSCの違いを理解することが重要です。

すべてのシスコ電話機には、工場でMICがプリインストールされています。この証明書は、Cisco Manufacturing CA、Cisco Manufacturing CA SHA2、CAP-RTP-001、CAP-RTP-002のいずれかのCisco Manufacturing CA証明書によって署名されます。電話機がこの証明書を提示すると、電話機は有効なCisco電話機であることがわかります。ただし、電話機が特定のお客様またはCUCMクラスタに属していることは検証されません。これは、一般市場で購入されたか、別のサイトから持ち込まれた不正な電話である可能性があります。

一方、LSCは管理者によって電話機に意図的にインストールされ、CUCMパブリッシャのCAPF証明書によって署名されます。既知のCAPF認証局によって発行されたLSCだけを信頼するように802.1XまたはAnyConnect VPNを設定します。証明書認証をMICではなくLSCに基づくことで、信頼できる電話機を非常にきめ細かく制御できます。

設定

Network Topology

このドキュメントでは、次のCUCMラボサーバを使用しました。

• CUCMパブリッシャとTFTPサーバ
• CUCMサブスクライバとTFTPサーバ 

CAPF証明書が期限切れでないこと、また近い将来に期限切れになることを確認します。図に示すように、Cisco Unified OS Administration > Security > Certificate Managementの順に移動し、Find Certificate List（ここで、CertificateはCAPFと完全に一致しています）を選択します。

Common Nameをクリックして、Certificate Detailsページを開きます。次の図に示すように、Certificate File DataペインでValidity From：およびTo：の日付を調べて、証明書の有効期限が切れる日付を確認します。

CAPF証明書の期限が切れているか、間もなく切れる場合は、その証明書を再生成します。期限切れのLSCインストールプロセスや、間もなく期限切れになるCAPF証明書を使用して、LSCインストールプロセスを進めないでください。これにより、CAPF証明書の期限切れによる近い将来のLSCの再発行が不要になります。CAPF証明書を再生成する方法については、「CUCM証明書の再生成/更新プロセス」を参照してください。

同様に、サードパーティ認証局によって署名されたCAPF証明書が必要な場合は、この段階で選択できます。今すぐ証明書署名要求(CSR)ファイルの生成と署名付きCAPF証明書のインポートを完了するか、または準備テストのために自己署名LSCを使用して設定を続行します。 サードパーティの署名付きCAPF証明書が必要な場合、一般的には、最初に自己署名CAPF証明書を使用してこの機能を設定し、テストと検証を行ってから、サードパーティの署名付きCAPF証明書によって署名されたLSCを再展開するのが賢明です。これにより、サードパーティの署名付きCAPF証明書を使用したテストが失敗した場合の、後のトラブルシューティングが簡素化されます。

警告: CAPFサービスがアクティブ化され、起動されている間にCAPF証明書を再生成するか、サードパーティ署名付きCAPF証明書をインポートすると、CUCMによって電話機が自動的にリセットされます。電話機のリセットが可能な場合は、メンテナンス時間帯に次の手順を実行します。詳細については、Cisco Bug ID CSCue55353「電話機がリセットするTVS/CCM/CAPF証明書を再生成する際の警告の追加」を参照してください

注：ご使用のCUCMバージョンがSBDをサポートしている場合、CUCMクラスタが混合モードに設定されているかどうかに関係なく、このLSCインストール手順が適用されます。SBDは、CUCMバージョン8.0(1)以降の一部です。これらのバージョンのCUCMでは、ITLファイルにCUCMパブリッシャのCAPFサービスの証明書が含まれています。これにより、インストール/アップグレードやトラブルシューティングなどの証明書操作をサポートするために、電話機をCAPFサービスに接続できます。

CUCMの以前のバージョンでは、証明書操作をサポートするためにクラスタを混合モードに設定する必要がありました。これは不要になるため、802.1X認証またはAnyConnect VPNクライアント認証の電話ID証明書としてLSCを使用する際の障害が軽減されます。

CUCMクラスタ内のすべてのTFTPサーバでshow itlコマンドを実行します。ITLファイルにCAPF証明書が含まれていることを確認します。

たとえば、次に示すのは、ラボ演習CUCMサブスクライバao115subからのshow itlの出力の抜粋です。

注：このファイルには、CAPFのFUNCTIONを含むITLレコードエントリがあります。

注：ITLファイルにCAPFエントリがない場合は、CUCMパブリッシャにログインし、CAPFサービスがアクティブであることを確認します。これを確認するには、Cisco Unified Serviceability > Tools > Service Activation > CUCM Publisher > Securityの順に移動し、Cisco Certificate Authority Proxy Function Serviceをアクティブにします。サービスが非アクティブ化され、アクティブ化されたばかりの場合は、Cisco Unified Serviceability > Tools > Control Center - Feature Services > Server > CM Servicesの順に移動し、CUCMクラスタ内のすべてのTFTPサーバでCisco TFTPサービスを再起動してITLファイルを再生成します。また、Cisco Bug ID CSCuj78330が発生していないことも確認してください。

注：作業が終了したら、CUCMクラスタ内のすべてのTFTPサーバでshow itlコマンドを実行して、現在のCUCMパブリッシャCAPF証明書がファイルに含まれていることを確認します。

 ITL Record #:1
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 727
2 DNSNAME 2
3 SUBJECTNAME 64 CN=CAPF-7f0ae8d7;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 CAPF
5 ISSUERNAME 64 CN=CAPF-7f0ae8d7;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 64:F2:FE:61:3B:79:C5:D3:62:E2:6D:AB:4A:8B:76:1B
7 PUBLICKEY 270
8 SIGNATURE 256
11 CERTHASH 20 C3 E6 97 D0 8A E1 0B F2 31 EC ED 20 EC C5 BC 0F 83 BC BC 5E
12 HASH ALGORITHM 1 null

 ITL Record #:2
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 717
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TVS
5 ISSUERNAME 59 CN=ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 6B:99:31:15:D1:55:5E:75:9C:42:8A:CE:F2:7E:EA:E8
7 PUBLICKEY 270
8 SIGNATURE 256
11 CERTHASH 20 05 9A DE 20 14 55 23 2D 08 20 31 4E B5 9C E9 FE BD 2D 55 87
12 HASH ALGORITHM 1 null

 ITL Record #:3
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1680
2 DNSNAME 2
3 SUBJECTNAME 71 CN=ITLRECOVERY_ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 71 CN=ITLRECOVERY_ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 51:BB:2F:1C:EE:80:02:16:62:69:51:9A:14:F6:03:7E
7 PUBLICKEY 270
8 SIGNATURE 256
9 CERTIFICATE 963 DF 98 C1 DB E0 61 02 1C 10 18 D8 BA F7 1B 2C AB 4C F8 C9 D5 (SHA1 Hash HEX)
This etoken was not used to sign the ITL file.

 ITL Record #:4
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 717
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TVS
5 ISSUERNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 65:E5:10:72:E7:F8:77:DA:F1:34:D5:E3:5A:E0:17:41
7 PUBLICKEY 270
8 SIGNATURE 256
11 CERTHASH 20 00 44 54 42 B4 8B 26 24 F3 64 3E 57 8D 0E 5F B0 8B 79 3B BF
12 HASH ALGORITHM 1 null

 ITL Record #:5
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1652
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 48:F7:D2:F3:A2:66:37:F2:DD:DF:C4:7C:E6:B9:CD:44
7 PUBLICKEY 270
8 SIGNATURE 256
9 CERTIFICATE 959 20 BD 40 75 51 C0 61 5C 14 0D 6C DB 79 E5 9E 5A DF DC 6D 8B (SHA1 Hash HEX)
This etoken was used to sign the ITL file.

 ITL Record #:6
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1652
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TFTP
5 ISSUERNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 48:F7:D2:F3:A2:66:37:F2:DD:DF:C4:7C:E6:B9:CD:44
7 PUBLICKEY 270
8 SIGNATURE 256
9 CERTIFICATE 959 20 BD 40 75 51 C0 61 5C 14 0D 6C DB 79 E5 9E 5A DF DC 6D 8B (SHA1 Hash HEX)

 ITL Record #:7
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1031
2 DNSNAME 9 ao115sub
3 SUBJECTNAME 62 CN=ao115sub-EC;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TFTP
5 ISSUERNAME 62 CN=ao115sub-EC;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 53:CC:1D:87:BA:6A:28:BD:DA:22:B2:49:56:8B:51:6C
7 PUBLICKEY 97
8 SIGNATURE 103
9 CERTIFICATE 651 E0 CF 8A B3 4F 79 CE 93 03 72 C3 7A 3F CF AE C3 3E DE 64 C5 (SHA1 Hash HEX)

The ITL file was verified successfully.

ITLのエントリとして確認されたCAPFエントリを使用して、電話機での証明書操作を完了できます。この例では、ヌルストリング認証を使用して2048ビットのRSA証明書がインストールされます。

電話機で、図のようにLSCがまだインストールされていないことを確認します。たとえば、79XXシリーズの電話機で、Settings > 4 - Security Configuration > 4 - LSCの順に移動します。

電話機の電話機の設定ページを開きます。Cisco Unified CM Administration > Device > Phoneの順に移動します。

図に示すように、電話機の設定のCAPF情報セクションに次の詳細を入力します。

• Certificate Operationでは、Install/Upgradeを選択します。
• 認証モードには、By Null Stringを選択します。
• この例では、Key Order、RSA Key Size(Bits)、およびEC Key Size(Bits)はシステムのデフォルト設定のままにします。
• [操作の完了期限]に、少なくとも1時間後の日付と時刻を入力します。

設定の変更を保存し、Apply Configを実行します。

図に示すように、電話機のLSCステータスがPendingに変わります。

図に示すように、電話機はキーを生成します。

電話機がリセットされ、リセットが完了すると、図に示すように、電話機のLSCステータスがInstalledに変わります。

これは、図に示すように、電話機のステータスメッセージにも表示されます。

確認

ここでは、設定が正常に機能しているかどうかを確認します。

複数の電話機でのLSC証明書のインストールを確認するには、『Cisco Unified Communications Managerセキュリティガイドリリース11.0(1)』の「CAPFレポートの生成」セクションを参照してください。または、LSCステータスまたは認証文字列による電話機の検索手順を使用して、CUCM管理Webインターフェイス内で同じデータを表示できます。

電話機にインストールされたLSC証明書のコピーを取得するには、記事「Cisco IP Phoneから証明書を取得する方法」を参照してください。

LSCの一括インストール

このセクションを使用して、同じモデルの電話機にLCSを一括でアップロードします。

1. Bulk Administration >電話>電話の更新>クエリに移動します。
2. Device Typeに<enter four digit model number>が含まれている電話機を検索します。Find、Nextの順に選択します。
3. Certification Authority Proxy Function (CAPF) Informationセクションまでスクロールします。
4. ドロップダウンセクションで、Install/Upgradeを選択します。

一括管理を使用して認証モードを選択する場合、認証モードは電話セキュリティプロファイルの動作と一致する必要があります。  By Null String in BulkとBy Existing Certificate (precedence to LSC) in Phone Security Profileが一致しない場合は、操作を完了できません。

電話セキュリティプロファイルと認証モードを確認して、正しいモードを使用していることを確認します。

LSC優先順位によるLSC

一括設定を行うには、ドロップダウンから、電話セキュリティプロファイルに一致する認証モードを選択します。

一括選択

電話セキュリティプロファイルの認証モードを変更する場合は、Saveを実行してから、設定をApplyを実行する必要があります。  これにより、特定の電話セキュリティプロファイルを使用しているデバイスが再起動する可能性があります。

認証の選択

トラブルシュート

ここでは、設定のトラブルシューティングに使用できる情報を示します。

有効なCAPFサーバがありません

LSCのインストールに失敗。電話機のステータスメッセージに「No valid CAPF server」と表示されます。これは、ITLファイルにCAPFエントリがないことを示します。CAPFサービスがアクティブになったことを確認し、TFTPサービスを再起動します。再起動後にITLファイルにCAPF証明書が含まれていることを確認し、電話機をリセットして最新のITLファイルを取得してから、証明書操作を再試行します。電話機のセキュリティ設定メニューにCAPFサーバエントリがホスト名または完全修飾ドメイン名として表示される場合、電話機がエントリをIPアドレスに解決できることを確認します。

LSC：接続できませんでした

LSCのインストールに失敗。電話機のステータスメッセージに「LSC: Connection Failed」と表示されます。これは、次のいずれかの状態を示している可能性があります。

• ITLファイルのCAPF証明書と現在の証明書が一致しない場合、CAPFサービスが使用されています。
• CAPFサービスが停止または非アクティブ化されています。
• 電話機がネットワーク経由でCAPFサービスに到達できません。

CAPFサービスがアクティブになっていることを確認し、CAPFサービスを再起動し、TFTPサービスを再起動して起動し、電話機をリセットして最新のITLファイルを取得してから、証明書の操作を再試行します。問題が解決しない場合は、電話機とCUCMパブリッシャからパケットキャプチャを取得し、デフォルトのCAPFサービスポートであるポート3804で双方向通信が行われているかどうかを分析します。そうでない場合は、ネットワークに問題がある可能性があります。

LSC：失敗

LSCのインストールに失敗。電話機のステータスメッセージに「LSC: Failed」と表示されます。電話機の設定Webページに、「Certificate Operation Status: Upgrade Failed: User Initiated Request Late/Timedout」と表示されます。これは、操作が時間までに完了し、日付が期限切れであるか、過去の日付であることを示します。少なくとも1時間後の日付と時刻を入力してから、証明書の操作をやり直してください。

LSC：操作保留中

LSCのインストールに失敗。電話機のステータスメッセージに「LSC: Connection Failed」と表示されます。電話機の設定ページに、「Certificate Operation Status: Operation Pending」と表示されます。Certificate Operation Status: Operation Pendingステータスが表示される理由はさまざまです。その一部は次のとおりです。

• 電話機のITLが、設定されたTFTPサーバで現在使用されているものと異なる
• 破損したITLの問題。これが発生すると、デバイスは信頼できるステータスを失い、電話機がITLRecovery証明書を使用するように強制するために、CUCMパブリッシャからutils itl reset localkeyコマンドを実行する必要があります。クラスタが混合モードの場合、utils ctl reset localkeyコマンドを使用する必要があります。次に、CUCMのCLIから破損したITLを表示しようとした場合の表示例を示します。ITLを表示してutils itl reset localkeyコマンドを実行しようとして、2番目のエラーが表示される場合は、不具合Cisco Bug ID CSCus33755の可能性があります。CUCMのバージョンが該当するかどうかを確認します。

• TVSの障害が原因で電話機が新しいLSCの認証に失敗する。
• 電話機ではMIC証明書が使用されますが、電話機の設定ページのCertificate Authority Proxy Function(CAPF)情報セクションで、認証モードがExisting Certificate（LSCに対する優先順位）に設定されています。
• 電話機がCUCMのFQDNを解決できません。

最後のシナリオでは、電話機がCUCMのFQDNを解決できなかった場合にログに表示される内容をシミュレートするようにラボ環境が設定されています。現在、ラボは次のサーバでセットアップされています。

• バージョン11.5.1.15038-2を実行するCUCMパブリッシャおよびサブスクライバ
• Windows 2016 ServerがDNSサーバーとしてセットアップされました

このテストでは、PUB11 CUCMサーバのDNSエントリが設定されていません。

ラボ内の電話(8845)のいずれかにLSCをプッシュしてみた。まだCertificate Operation Status: Operation Pendingが表示されていることを確認します。

電話機のコンソールログで、設定されたDNSサーバアドレスにクエリーを転送する前に、電話機がローカルキャッシュ(127.0.0.1)にクエリーを送信しようとすることを確認します。

0475 INF Mar 12 15:07:53.686410 dnsmasq[12864]: query[A] PUB11.brianw2.lab from 127.0.0.1
0476 INF Mar 12 15:07:53.686450 dnsmasq[12864]: forwarded PUB11.brianw2.lab to X.X.X.X
0477 INF Mar 12 15:07:53.694909 dnsmasq[12864]: forwarded PUB11.brianw2.lab to X.X.X.X
0478 INF Mar 12 15:07:53.695263 dnsmasq[12864]: reply PUB11.brianw2.lab is NXDOMAIN-IPv4
0479 INF Mar 12 15:07:53.695833 dnsmasq[12864]: query[A] PUB11.brianw2.lab from 127.0.0.1
0480 INF Mar 12 15:07:53.695865 dnsmasq[12864]: cached PUB11.brianw2.lab is NXDOMAIN-IPv4
0481 WRN Mar 12 15:07:53.697091 (12905:13036) JAVA-configmgr MQThread|NetUtil.traceIPv4DNSErrors:? - DNS unknown IPv4 host PUB11.brianw2.lab

++ However, we see that the phone is not able to resolve the FQDN of the CUCM Publisher. This is because we need to configure the DNS entry for PUB11 on our DNS server.

0482 ERR Mar 12 15:07:53.697267 (12905:13036) JAVA-configmgr MQThread|cip.sec.TvsProperty:? - Failed to resolve Tvs Ipv4 Address with hostname PUB11.brianw2.lab

++ Afterwards, we see the CAPF operation fail. This is expected because we do not have a DNS mapping for PUB11. 

0632 NOT Mar 12 15:07:55.760715 (12905:13036) JAVA-configmgr MQThread|cip.sec.CertificateProperty:? - CertificateProperty.setCertificate() authMode=CAPF_AUTH_MODE_NULL_STR authorizationString=null theReason=CAPF_REASON_AUTO
0633 NOT Mar 12 15:07:55.761649 (322:17812) SECUREAPP-RCAPF_START_MODE: Start CAPF - mode:[1]([NULL_STR]), reason:[1]([AUTO]) no auth-str
0634 NOT Mar 12 15:07:55.761749 (322:17812) SECUREAPP-CAPF_CLNT_INIT:CAPF clnt initialized
0635 NOT Mar 12 15:07:55.761808 (322:17812) SECUREAPP-CAPFClnt: SetDelayTimer - set with value <0>
0636 ERR Mar 12 15:07:55.761903 (322:17812) SECUREAPP-Sec create BIO - invalid parameter.
0637 ERR Mar 12 15:07:55.761984 (322:17812) SECUREAPP-SEC_CAPF_BIO_F: CAPF create bio failed
0638 ERR Mar 12 15:07:55.762040 (322:17812) SECUREAPP-SEC_CAPF_OP_F: CAPF operation failed, ret -7
0639 CRT Mar 12 15:07:55.863826 (12905:13036) JAVA-configmgr MQThread|cip.sec.CertificateProperty$1:? - LSC: Connection failed

++ What we would expect to see is something similar to the following where DNS replies with the IP address that is associated with the FQDN of CUCM. After configuring a AAAA record in DNS for PUB11, we now see the below result in the console logs.

4288 INF Mar 12 16:34:06.162666 dnsmasq[12864]: query[A] PUB11.brianw2.lab from 127.0.0.1
4289 INF Mar 12 16:34:06.162826 dnsmasq[12864]: forwarded PUB11.brianw2.lab to X.X.X.X
4290 INF Mar 12 16:34:06.164908 dnsmasq[12864]: reply PUB11.brianw2.lab is X.X.X.X
4291 NOT Mar 12 16:34:06.165024 (12905:13036) JAVA-configmgr MQThread|cip.sec.TvsProperty:? - Resolve Tvs Ipv4 Address to X.X.X.X from hostname PUB11.brianw2.lab

電話機がPUB11.brianw2.labを解決できないことを電話機ステータスメッセージで確認します。その後、「LSC: Connection」 failedメッセージが表示されます。

考慮すべき不具合:

Cisco Bug ID CSCub62243:LSCのインストールが断続的に失敗し、その後CAPFサーバがフリーズする。

考慮すべき機能拡張不具合:

Cisco Bug ID CSCuz18034:LSCがインストールされたエンドポイントの期限切れステータスとともにレポートが必要です。

関連情報

次のドキュメントでは、AnyConnect VPNクライアント認証と802.1X認証に関連したLSCの使用について詳しく説明します。

• AnyConnect VPN 電話 - IP Phone、ASA、および CUCM のトラブルシューティング
• Identity-Based Networking Services: IP Telephony In IEEE 802.1X-Enabled Networks Deployment and Configuration Guide（IDベースのネットワークサービス：IEEE 802.1X対応ネットワークのIPテレフォニー導入および設定ガイド）

高度なタイプのLSC設定もあります。この設定では、LSC証明書が、CAPF証明書ではなく、サードパーティ認証局によって直接署名されます。

詳細については、「CUCMサードパーティCA署名付きLSCの生成およびインポートの設定例」を参照してください。

• テクニカル サポートとドキュメント - Cisco Systems