サテライトと cssm の期ファイル交換...cssm...

2017 Cisco – All Rights Reserved 1

サテライトと CSSM の同期ファイル交換

概要

Smart Software Manager サテライトを（スタンドアロンまたは高可用性（HA）構成で）導入した後

は、完全に機能させるために Cisco Smart Software Manager（CSSM）にサテライトを登録する

必要があります。その後は、ライセンスのエンタイトルメントと使用状況を新しい状態に保つため

に、定常時はサテライトを CSSM と 30 日ごとに同期することを推奨します。31 日以上 CSSM と

同期していない Smart Software Manager サテライトのすべてのインスタンスは、（32 日目以降

に）期限切れの警告を受信します。

同期から 90 日経過すると、サテライトは Cisco Smart Software Manager（software.cisco.com）か

ら削除されます。削除されたサテライトに関連付けられていた既存の製品インスタンスは登録が

継続され、最後の登録更新から最大 365 日間機能します。認証の更新を実行すると、コンプラ

イアンス違反（OOC）応答が返され、新しい製品を登録することはできません。サテライトにはま

だアクセス可能ですが、UI は機能せず、ユーザは以下のリセットページに移動します。

サテライトを復元するには、新しいサテライトを再導入し、CSSM に再度登録して、以前の製品

インスタンスを再度登録する必要があります。

サテライトの運用

次の図は、Smart Software Manager サテライトをセットアップして運用する手順を示しています。


登録時に、サテライトと CSSM の間で 2 つのファイルが交換されます。

• 登録ファイル（SSM サテライト -> シスコ）

• 承認ファイル（シスコ -> SSM サテライト）

通常の動作中は、サテライトと CSSM 間で 2 つの異なるファイルが交換されます。

• 同期要求ファイル（サテライト -> シスコ）

• 同期応答ファイル（シスコ -> SSM サテライト）

このファイルは、ユーザによって検査可能なテキスト YML 形式です。ただし、ユーザがファイ

ルを変更すると、CSSM はそのファイルを拒否します。

1. CSSM へのサテライトの登録

CSSM にサテライトを登録中、サテライトは CSSM に複数の異なる CSR（証明書署名要求）を

送信します（lcs_csr、tg_csr、ssms_csr）。セクション 6 で説明されているように、CSR は検証可

能です。

instance_id：

汎用一意識別子（UUID）。UUID は Open Software Foundation によって標準化されている 128

ビットの値で、SSM サテライトごとに一意です（RFC 4122 も参照）。

exported_timestamp：シスコによってこのイメージが作成されたときのタイムスタンプ。

lcs_csr：送信元は、サテライトとともに常駐するオフライン/ローカルの LCS（ライセンス暗号化

サービス）です（一方、オンラインの LCS は CSSM によって使用されるシスコ内部ネットワーク

内に導入されています）。


tg_csr：送信元はトランスポートゲートウェイです。デュアル NIC には、インターフェイスごとに

2 つの異なる証明書（tg および ssms）が必要です。

ssms_csr：送信元はサテライト（Ruby/Rails アプリケーション）です。サテライト UI 用に使用され

ます。

サテライトの登録中に、完全同期も実行されます（完全同期の説明については、5 ページを参

照）。CSSM は、登録応答ファイルの 8 つの異なる証明書とともに登録承認ファイルを送信しま

す。登録中に、ローカル LCS が CSR を生成して要求ファイル内に配置します。承認応答で、

サテライトはローカルのサブ CA を取得します。この CA は、ローカル LCS によって、製品イン

スタンス（PI）登録用の ID 証明書に署名するために使用されます。

id_cert：ID 証明書は、すべての製品インスタンスを識別するために、サテライトによって使用さ

れます。また、サテライトの識別のためにシスコによっても使用されます。この証明書は、サテラ

イトと CSSM 間の同期のたびに更新されます。

sub_ca_cert：証明書チェーン id_cert -> sub_ca -> licensing_root_ca（サテライトアプリケーショ

ンのソースに埋め込み）を検証するために、シスコ製品上のライセンシングエージェントによっ

て使用されます。

signing_cert：id_cert の署名者。id_cert が licensing_root_ca によって署名されたかどうかを確

認するためにサテライトによって使用されます。

tg_ssl_cert：安全な接続の受け入れ、および製品インスタンス（PI）とサテライトの安全な接続

（HTTPS）を介した通信を可能にするために、トランスポートゲートウェイ（TG）によって使用され

ます。

tg_issuer_cert：証明書チェーン tg_ssl_cert -> tg_issuer_cert -> licensing root certificate（TG

コードに埋め込み）を確立するために、TG によって使用されます。

satellite_cert：ローカルのオフライン LCS 用の local_sub_ca_cert_1_1 に署名するためにオン

ライン LCS によって使用されます。

local_sub_ca_cert_1_1：4 層の製品インスタンスの登録を処理するためにローカルサテライト

LCS およびサテライトによって使用されます（7 ページの「3 層と 4 層の証明書」を参照）。LCS

は、この証明書を使用して、PI への送信中に id_cert に署名します。PI の登録応答では、

sub_ca として表示されます。


ssms_ssl_cert：安全な接続の受け入れ、および Web ブラウザとサテライトの安全な接続

（HTTPS）を介した通信を可能にするために、サテライトによって使用されます。

CSSM もスマートアカウントに割り当てられた情報とサテライト情報（uuid、サテライト名など）を

以下のように送り返します。

2. サテライトと CSSM の同期

定期的な同期の際、サテライトは登録済み製品インスタンス、ライセンスの使用状況などの情報

を CSSM に送信します。また、CSR と 2 つの証明書（id_cert、signing_cert）も CSSM に送信し

ます。

sync_version：CSSM との同期コードのバージョン。

ssms_version：サテライトソフトウェアのバージョン。

id_cert、signing_cert：サテライトが有効なサテライトであるかどうかを確認するために CSSM に

よって使用されます。

csr（lcs csr）：現在は使用されていません。

tg_csr：管理者の IP アドレスが変更された場合や、サテライトが他のホスト（他の IP アドレス）に

復元された場合にのみ、サテライトはこの CSR を CSSM に送信します。PI から TG。

ssms_csr：管理者の IP アドレスが変更された場合や、サテライトが他のホスト（他の IP アドレス）

に復元された場合にのみ、サテライトはこの CSR を CSSM に送信します。ブラウザからサテラ

イト。

:status:success:uuid: 491a5670-9295-0135-cf27-0050568f1fb9:smartaccount:BUProductionTest:accountdomain:buproductiontest.cisco.com:satellitename:sat-rest-003:lastgenerated:2017-Oct-1322:42:03UTC


同期要求には、証明書に加えて、次の情報が表示されます。

last_generated/last_sync：（差分）同期データの取得に使用されるタイムスタンプ。

virtual_accounts：サテライトのバーチャルアカウント、登録済みの製品インスタンス、ライセンス。

デフォルトではホスト名が送信されることに注意してください。ホスト名の送信を無効にするに

は、次のように設定します。

cfg-call-home# data-privacy hostname

サテライト 2.5.0 では同期の最適化がリリースされ、sync_type = PARTIAL または sync_type =

FULL も同期要求ファイルに含まれるようになりました。

部分的な（標準の）同期では、サテライトと CSSM は製品インスタンスとライセンス（エンタイトル

メントと使用状況）について、前回の同期からの差分のみを送信します。完全同期では、サテラ

イトと CSSM はそれぞれのすべての製品インスタンスとライセンスの情報を相互に送信します。

CSSM はライセンスのエンタイトルメントについての信頼できるソースであり、サテライトは製品イ

ンスタンスとライセンスの使用状況についての信頼できるソースです。

:sync: 2.0.0,

:version: 2.0.0

:collector_id: 4cdd0470-e5e4-0132-a310-005056841670

:last_sync: 2017-Jun-22 08:50:35 UTC

:last_generated: 2017-Jul-20 11:22:16 UTC

:virtual_accounts:

- :id: 101342

:name: Ross-1

:product_instances:

- :id: 2373d312-2cd8-4029-9517-8c60037cca8c

:registration_date: 2017-Jun-12 07:25:40 UTC

:last_contact_date: 2017-Jul-02 06:13:47 UTC

:is_active: true

:software_tag_identifier: regid.2013-08.com.cisco.CSR1000V,1.0_1562da96-9176-4f99-a6cb-14b4dd0fa135

:udi_pid: CSR1000V

:hostname: CSR-1000v

:ip_address:

:mac_address:

:udi_serial_number: 97YZFA9VYJK

:host_identifier:

:licenses:

- :tag_id: 1146

:tag: regid.2014-05.com.cisco.ax_2500M,1.0_3e0288f3-4838-47c2-93a8-3d8743850f0c

:consumed_quantity: 1

:root_cert_hash:C3CyNDezXF9nJrp6zLpAnUQOMbxQyeDRn/O0x347an0=:sync_type:PARTIAL:device_conversion_data:[]:signature:|-


3. CSSM の同期応答

CSSM は、サテライトからの同期要求を受信して処理すると、同期承認応答を送信します。基

盤となる完全同期は、サテライトが最初に CSSM に登録するときに発生します。その後、サテラ

イトからの定期的な同期要求が発生すると、CSSM はこれらの要求も処理します。同期応答で

は、サテライトと CSSM 間の通信を保護するための証明書情報、およびバーチャルアカウント

とライセンスに関する情報が CSSM からサテライトに送信されます。

local_sub_ca_cert：3 層の製品インスタンス登録を処理するためにサテライトと LCS によって使

用されます。サテライトが CSSM に登録後 48 時間以上経過している場合にのみ、この証明書

は同期応答に含まれます。

collector_instance_id：このサテライトに割り当てられている ID。

satellite_name：サテライトの名前。

last_generated/last_sync：（差分）同期データの取得に使用されるタイムスタンプ。

synchronization：CSSM からサテライトに送信されるバーチャルアカウントとライセンスに関す

る情報が含まれます。


サードパーティ統合のサポートにより、CSSM は完全な同期応答ファイルでプロバイダ情報も

送信します。これは、それぞれ SpeechView、Apple Push Notification、PnP へのサポートを示し

ています。

機器先行ライセンス変換機能（DLC）のサポートにより、CSSM は DLC を開始したサテライト登

録済み製品インスタンスについての機器変換情報（ステータス、sudi、ソフトウェア ID タグ、メッ

セージなど）を、同期ファイルの :device_conversion_response: フィールドを通じて提供します。

4. 3 層と 4 層の証明書：

サテライトは、製品インスタンスからの登録を受け付ける前に、CSSM に登録する必要がありま

す。以前は、サテライトから CSSM への証明書署名要求（CSR）に担当者が手動で署名する必

要があったことから、サテライトから CSSM への登録には 48 時間の待機が必要でした。つまり、

サテライトに接続する必要がある製品は、サテライトが完全に登録され、機能できるようになるま

で 48 時間待機する必要がありました。

:data:

:authentication:

:id_cert: |-

:local_sub_ca_cert:

:collector_instance_id: 4cdd0470-e5e4-0132-a310-005056841670

:satellite_name: Ross-SSMS-SCH4.1.2-Prod-OVF10

:last_generated: 2017-Jul-20 11:25:48 UTC

:last_sync: 2017-Jul-20 11:22:16 UTC

:synchronization:

:products:

- :id: 3662

:display_name: Cisco IOS XRV 9000 Router

- :id: 3642

:product_type: IOSXRV

:software_tag_id: regid.2017-07.com.cisco.IOS-XRv9000,1.0_5a181e3a-27db-4cbc-8996-fb083ddbd594

- :id: 3682

:virtual_accounts:

- :id: 101342

:name: Ross-1

:smart_account_id: 10560

:device_conversion_response:- :sudi:

:udi_pid:CSR1000V:udi_serial_number:90MDZP3IDHJ

:conversion_status:FAILED:status_message_localized::status_message:DlcConversionnotallowed.:software_tag_identifier:regid.2013-08.com.cisco.CSR1000V,1.0_1562da96-9176-4f99-a6cb-14b4dd0fa135:conversion_response_line:[]


サテライト 2.1.0 リリース以降、CSR への手動による署名が自動化され、サテライトから CSSM

への CSR は即座に署名されるようになっています。ただし、この信頼チェーンが自動的に機能

できるように、製品のスマートエージェント、サテライト、および CSSM に変更を行う必要があり

ます。以前の信頼チェーンは、デバイス - サテライト - CSSM の 3 つのレベルの証明書（つまり

3 層）で構成されていました。信頼チェーン検証を自動化する新しい実装では、補足の証明書

が追加され、4 つのレベルの証明書（つまり 4 層）で構成されています。更新されたレベルのス

マートエージェント、サテライト、CSSM コードが含まれていない旧式のデバイスが機能を継続

できるように、これらの変更には後方互換性を持たせる必要もあります。

新しい実装では、3 層または 4 層のどちらの証明書をサポートしているかどうかを把握するため

に、スマートエージェント、サテライト、CSSM は新しいメッセージタイプを交換する必要があり

ます。最新のスマートエージェントコード（1.4 以降）が実装されていない製品がサテライトへの

登録を必要とする場合は、48 時間待機する必要があります。サテライトは、この製品インスタン

スを登録する前に CSSM から 3 層の証明書を取得する必要があるためです。その結果、

CSSM との同期から 48 時間経過すると、3 層の証明書が :local_sub_ca_cert: フィールドに

よってラベルされて応答に埋め込まれます。この時点で、3 層のデバイスがサテライトに登録で

きるようになります。

製品によってスマートエージェントの実装は異なるため、この機能に埋め込まれているスマート

エージェントのバージョンを常に把握することはできません。この記事の執筆時点で、3 層の製

品は ASAv、FMC、vCUSP、CBR8、5921 です。

スマートエージェントのバージョンは、「license smart status」または「show license all」コマンドを

発行するだけで確認できます。

5. 同期ファイルコンテンツのデータ整合性の検証

サテライトとシスコ間で交換される各同期ファイルのデータは、上記で説明した署名証明書に

よって署名されます。コンテンツと署名の照合について、暗号化ライブラリを使用して署名証明

書から公開キーを抽出し、このキーを使用して署名に照らすことでコンテンツを検証することが

できます。Ruby の使用例を以下に示します。

OpenSSL::X509::Certificate.new(Base64.decode64(signing_cert)).public_key.verify OpenSSL::Digest::SHA256.new, Base64.decode64(signature), content.to_s

signing_cert は署名証明書、content は yml ファイルのコンテンツ（署名に関するすべての情

報である :data フィールド下のすべてのコンテンツ）です。コンテンツは、署名される前に SHA

256 ダイジェストに変換されるため、検証を試みるときにパラメータとして指定する必要がありま

す。また、同期ファイルの署名証明書と署名は Base64 でエンコードされているため、検証中に

デコードする必要があることにも注意してください。


6. 証明書の検証

サテライトとシスコ間で交換されるすべての証明書は、Cisco Smart Licensing CA によって発行

されます。以下に、https://www.sslshopper.com/certificate-decoder.html の SSL デコーダからの

id_cert の証明書情報の例を示します。

共通名は、サテライトの固有識別子で、同期ファイルでは collector_instance_id で表されます。

https://www.sslshopper.com/certificate-decoder.html

サテライトと cssm の期ファイル交換...cssm...

Documents