はじめに
このドキュメントでは、証明書署名要求(CSR)を生成し、署名付き証明書をCisco Meeting Server(CMS)にアップロードする方法について説明します。
前提条件
要件
次の項目に関する知識があることが推奨されます。
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
- Puttyまたは同様のソフトウェア
- CMS 2.9以降
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
CSRの生成
CSRを生成するには2つの方法があります。1つは、管理アクセス権を持つコマンドラインインターフェイス(CLI)からCMSサーバ上に直接CSRを生成する方法で、もう1つは、Open SSLなどの外部のサードパーティ認証局(CA)を使用する方法です。
どちらの場合も、CMSサービスが正しく動作するように、正しい構文でCSRを生成する必要があります。
ステップ 1:構文構造。
pki csr <key/cert basename> <CN:value> [OU:<value>] [O:<value>] [ST:<-value>] [C:<value>] [subjectAltName:<value>]
- <key/cert basename>は、新しいキーとCSR名を識別する文字列です。英数字、ハイフン、またはアンダースコアを含めることができます。これは必須フィールドです。
- <CN:value>は共通名です。これは、ドメインネームシステム(DNS)内のサーバの正確な場所を指定する完全修飾ドメイン名(FQDN)です。これは必須フィールドです。
- [OU:<value>]は組織単位または部署名です。たとえば、サポート、IT、エンジニア、財務などです。これはオプションのフィールドです。
- [O:<value>]は組織名または事業名です。 通常は、法的に設立された会社の名前。これはオプションのフィールドです。
- [ST:<value>]は、都道府県、地域、郡、または州です。 たとえば、Buckinghamshire Californiaなどです。 これはオプションのフィールドです。
- [C:<value>]は国です。所属する国の2文字の国際標準化機構(ISO)コード。たとえば、US、GB、FRなどです。これはオプションのフィールドです。
- [subjectAltName:<value>]はサブジェクト代替名(SAN)です。 X509バージョン3(RFC 2459)以降では、Secure Socket Layer(SSL)証明書は、証明書が一致する必要がある複数の名前を指定できます。このフィールドは、生成された証明書が複数のドメインをカバーできるようにします。これには、IPアドレス、ドメイン名、電子メールアドレス、通常のDNSホスト名などをカンマで区切って含めることができます。指定する場合は、このリストにCNも含める必要があります。これはオプションのフィールドですが、Extensible Messaging and Presence Protocol(XMPP)クライアントが証明書を受け入れるためには、SANフィールドに値を入力する必要があります。そうしないと、XMPPクライアントに証明書エラーが表示されます。
ステップ 2:callbridge、xmpp、webadmin、およびwebbridge CSRを生成します。
- Puttyを使用してCMS CLIにアクセスし、adminアカウントでログインします。
- 次のコマンドを実行して、CMSで必要なすべてのサービスに対してCSRを作成します。必要に応じて、ワイルドカード(*.com)またはクラスタFQDNをCN、各CMSサーバのFQDN、および参加URLとして持つ1つの証明書を作成することもできます。
サービス |
コマンド |
Web管理者 |
pki csr
CN:
|
Webブリッジ |
pki csr
CN:
subjectAltName:
,
|
コールブリッジ 回転 ロードバランサ |
pki csr
CN:
|
- CMSがクラスタ化されている場合は、次のコマンドを実行します。
サービス |
コマンド |
コールブリッジ 回転 ロードバランサ |
pki csr
CN:
subjectAltName:
|
XMPP |
pki csr
CN:
subjectAltName:
,
|
ステップ 3:データベースクラスタCSRを生成し、組み込みCAを使用して署名します。
CMS 2.7以降では、データベースクラスタ用の証明書が必要です。 2.7には、データベース証明書の署名に使用できる組み込みCAが含まれています。
- すべてのコアで
database cluster remove
を参照。
- プライマリで、次のコマンドを実行します
pki selfsigned dbca CN
を参照。以下に例を挙げます。 Pki selfsigned dbca CN:tplab.local
- プライマリで、次のコマンドを実行します
pki csr dbserver CN:cmscore1.example.com subjectAltName
を参照。 以下に例を挙げます。 cmscore2.example.com,cmscore3.example.com
- プライマリで、データベースクライアントの証明書を作成します
pki csr dbclient CN:postgres
を参照。
- プライマリでは、dbcaを使用してdbserver証明書に署名します
pki sign dbserver dbca
を参照。
- プライマリでは、dbcaを使用してdbclient証明書に署名します
pki sign dbclient dbca
を参照。
- dbclient.crtを、データベースノードに接続する必要があるすべてのサーバにコピーします
- dbserver.crtファイルを、データベースに参加しているすべてのサーバ(データベース・クラスタを構成するノード)にコピーします
- dbca.crtファイルをすべてのサーバにコピーします。
- プライマリDBサーバで、
database cluster certs dbserver.key dbserver.crt dbclient.key dbclient.crt dbca.crt
を参照。 この設定では、 dbca.crt
を使用して root ca-cert
を参照。
- プライマリDBサーバで、
database cluster localnode a
を参照。
- プライマリDBサーバで、
database cluster initialize
を参照。
- プライマリDBサーバで、
database cluster status
を参照。 ノード: (me): Connected Primaryを参照してください。
- データベースクラスタに参加している他のすべてのコアで、を実行します。
database cluster certs dbserver.key dbserver.crt dbclient.key dbclient.crt dbca.crt
を参照。
- データベースクラスタに接続されている(データベースと共存していない)すべてのコアで、を実行します。
database cluster certs dbclient.key cbclient.crt dbca.crt .
- 参加している(データベースと同じ場所に配置されている)コア:
- run
database cluster localnode a
を参照。
- run
database cluster join
を参照。
- 接続されている(データベースと共存していない)コア:
- RU N
database cluster localnode a
.
- run
database cluster connect
.
ステップ 4:署名付き証明書を確認します。
- 証明書の有効性(有効期限)は、証明書インスペクションで確認できます。次のコマンドを実行します。
pki inspect
を参照。
- 証明書が秘密キーと一致することを検証するには、次のコマンドを実行します。
pki match
を参照。
- 証明書がCAによって署名され、証明書バンドルを使用して証明書をアサートできることを検証するには、次のコマンドを実行します
pki verify
を参照。
ステップ 5:CMSサーバのコンポーネントに署名付き証明書を適用します。
- Webadminに証明書を適用するには、次のコマンドを実行します。
webadmin disable
webadmin certs <keyfile> <certificate file> <certificate bundle/Root CA>
webadmin enable
- 証明書をCallbridgeに適用するには、次のコマンドを実行します。
callbridge certs <keyfile> <certificate file> <certificate bundle/Root CA>
callbridge restart
- 証明書をWebbridgeに適用するには、次のコマンドを実行します。
webbridge disable
webbridge certs <keyfile> <certificate file> <certificate bundle/Root CA>
webbridge enable
- 証明書をXMPPに適用するには、次のコマンドを実行します。
xmpp disable
xmpp certs <keyfile> <certificate file> <certificate bundle/Root CA>
xmpp enable
- 証明書をデータベースに適用するか、現在のDBクラスタで期限切れの証明書を置き換えるには、次のコマンドを実行します。
database cluster remove (on all servers, noting who was primary before beginning)
database cluster certs <server_key> <server_certificate> <client_key> <client_certificate> <Root ca_crt>
database cluster initialize (only on primary node)
database cluster join <FQDN or IP of primary> (only on slave node)
database cluster connect <FQDN or IP of primary> (only on nodes that are not part of the database cluster)
- TURNに証明書を適用するには、次のコマンドを実行します。
turn disable
turn certs <keyfile> <certificate file> <certificate bundle/Root CA>
turn enable
証明書信頼チェーンおよびバンドル
CMS 3.0以降では、証明書信頼チェーンまたは完全なチェーン信頼を使用する必要があります。 また、バンドルを作成する際に証明書がどのように構築されるかを認識するサービスも重要です。
証明書信頼チェーンを構築する場合は、Webブリッジ3に必要に応じて、図に示すように構築する必要があります。最初にエンティティ証明書、中間に中間証明書、最後にルートCAを構築し、最後に単一のキャリッジリターンを構築します。
バンドルを作成する場合は、証明書の末尾に必ず1つのキャリッジリターンが必要です。
CAバンドルは図に示すように同じですが、当然、エンティティ証明書はありません。
トラブルシュート
データベース証明書を除くすべてのサービスで期限切れの証明書を置き換える必要がある場合、最も簡単な方法は、古い証明書と同じ名前で新しい証明書をアップロードすることです。この場合、サービスを再起動するだけで、サービスを再設定する必要はありません。
次の操作を実行する場合 pki csr ...
その証明書名が現在のキーと一致すると、サービスはすぐに中断されます。 本番で、新しいCSRとキーをプロアクティブに作成する場合は、新しい名前を使用します。 新しい証明書をサーバにアップロードする前に、現在アクティブな名前を変更できます。
データベース証明書の有効期限が切れている場合は、 database cluster status
データベースのプライマリは誰か、すべてのノードでコマンドを実行します。 database cluster remove
を参照。 次に、ステップ3の手順を使用できます。データベースクラスタCSRを生成し、組み込みCAを使用して署名します。
関連情報