証明書の概要&CUCMの権限
内容
概要
このドキュメントでは、証明書および認証局の基本について説明します。Cisco Unified Communications Manager(CUCM)の暗号化機能または認証機能を参照する他のシスコのドキュメントを補完します。
前提条件
要件
このドキュメントに特有の要件はありません。
使用するコンポーネント
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
表記法
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
証明書の目的
証明書は、エンドポイント間でデータの信頼/認証と暗号化を構築するために使用されます。これにより、エンドポイントは意図したデバイスと確実に通信できるようになり、2 台のエンドポイント間でデータを暗号化するオプションが備わります。
証明書の観点からの信頼の定義
証明書の最も重要な部分は、エンドポイントが信頼できるエンドポイントの定義です。このドキュメントは、データを暗号化する方法と、目的の Web サイト、電話、FTP サーバなどとデータを共有する方法を理解および定義するのに役立ちます。
システムが証明書を信頼する場合、システムにインストール済みの証明書が存在し、正しいエンドポイントと情報を共有していると100%確信していることを示します。それ以外の場合は、これらのエンドポイント間の通信を終了します。
これに関する非技術的な例は運転免許証です。この免許証（サーバ/サービス証明書）は、自身で主張するその人の身元が正しいこと、および国の車両管理局（DMV）（認証局）から権限を付与された地方の車両管理支局（中間証明書）から免許証を取得したことを証明するために使用されます。 職員に免許証（サーバ/サービス証明書）を提示する必要があるときには、職員は DMV 支局（中間証明書）と車両管理局（認証局）が信頼できることを知っており、この免許証がその機関（認証局）によって発行されたことを確認できます。 職員は身元を確認し、自身で主張するその人の身元が正しいことを信頼します。DMV（中間証明書）によって署名されていない偽の免許証（サーバ/サービス証明書）を提示した場合、職員は、自身で主張するその人の身元を信頼しません。このドキュメントの残りの部分では、証明書階層の詳細な技術的な説明を示します。
ブラウザによる証明書の使用法
-
Web サイトにアクセスするときは、http://www.cisco.com などの URL を入力します。
-
DNS がそのサイトをホストするサーバの IP アドレスを見つけます。
-
ブラウザがそのサイトに移動します。
証明書がなければ、不正な DNS サーバが使用されていないか、または別のサーバにルーティングされていないかを知ることはできません。証明書を使用することで、銀行の Web サイトなどの目的の Web サイトに適切かつ安全にルーティングされ、そこで入力する個人情報または機密情報が保護されることが保証されます。
使用されるアイコンはブラウザによって異なりますが、通常は次のような南京錠がアドレス バーに表示されます。 
-
南京錠をクリックすると、次のウィンドウが表示されます。
図 1：Web サイトの識別
-
次の例に示すように、[View Certificates] をクリックしてサイトの証明書を表示します。
図 2：証明書の情報（[General] タブ）
強調表示されている情報が重要です。
-
[Issued by]：システムがすでに信頼している会社または認証局（CA）です。
-
[Valid from/to ]：この証明書が使用可能な日付範囲です（証明書の CA を信頼していることがわかっているにもかかわらず、その証明書が無効になっていることがあります。必ず日付を調べて、証明書の有効期限が切れていないかどうかを確認してください）。
-
PEM 証明書と DER 証明書の違い
PEM は ASCII で、DER はバイナリです。図 3 に、PEM 証明書の形式を示します。
図 3：PEM 証明書の例
図 4 に、DER 証明書を示します。
図 4：DER 証明書の例
PEM 形式は電子メールで扱いやすいため、VeriSign や Thawt などのほとんどの CA 企業は、顧客への証明書の送信にこの PEM 形式を使用します。文字列全体をコピーし、—BEGIN CERTIFICATE – および – END CERTIFICATE – を含め、テキストファイルに貼り付けて、拡張子.PEMまたは.CERを付けて保存します。
Windows は、独自の証明書管理アプレットで DER 形式と CER 形式を読み取り、図 5 で示しているような証明書を表示します。
図 5：証明書情報
場合によっては、デバイスで特定の形式（ASCII またはバイナリ）が必要になります。 これを変更するには、CA から必要な形式の証明書をダウンロードするか、https://www.sslshopper.com/ssl-converter.html などの SSL コンバータ ツールを使用します。
証明書階層
エンドポイントからの証明書を信頼するには、サードパーティCAとの信頼関係がすでに確立されている必要があります。たとえば、図6は、3つの証明書の階層があることを示しています。
図 6：証明書階層
-
Verisign は CA です。
-
Verisign Class 3 Extended Validation SSL CA は、中間証明書または署名サーバ証明書（自身の名前で証明書を発行することが CA から許可されているサーバ）です。
エンドポイントは、SSL ハンドシェイク（詳細は下記を参照）によって提供されるサーバ証明書が信頼できることを確認する前に、まず CA と中間証明書の両方が信頼できることを確認する必要があります。 この信頼の仕組みをより深く理解するには、このドキュメントの「証明書の観点からの「信頼」の定義」のセクションを参照してください。
自己署名証明書とサード パーティ証明書
自己署名証明書とサードパーティ証明書の主な違いは、誰が証明書に署名したか、その署名者を信頼するかどうかです。
自己署名証明書は、証明書を提供するサーバによって署名される証明書です。したがって、サーバ/サービス証明書と CA 証明書は同じです。
サードパーティ CA は、パブリック CA（VeriSign、Entrust、Digicert など）、またはサーバ/サービス証明書の有効性を管理するサーバ（Windows 2003、Linux、UNIX、IOS など）のいずれかによって提供されるサービスです。
それぞれがCAになることができます。システムがそのCAを信頼するかどうかは、最も重要な点です。
共通名とサブジェクトの別名
共通名（CN）とサブジェクトの別名（SAN）は、IP アドレス、または要求されるアドレスの完全修飾ドメイン名（FQDN）への参照です。たとえば、https://www.cisco.com と入力すると、CN または SAN のヘッダーに www.cisco.com が含まれている必要があります。
図 7 に示している例では、証明書に www.cisco.com という CN があります。ブラウザからの www.cisco.com への URL 要求では、URL FQDN と証明書が提供する情報が照合されます。この場合、これらは一致し、SSL ハンドシェイクに成功したことが表示されます。この Web サイトは正しい Web サイトであることが確認され、デスクトップと Web サイト間の通信が暗号化されます。
図 7：Web サイトの確認
同じ証明書に、3 つの FQDN/DNS アドレスに対応する SAN ヘッダーがあります。
図 8：SAN ヘッダー
この証明書では、www.cisco.com（CN でも定義されています）、cisco.com、および cisco-images.cisco.com を認証および確認できます。つまり、cisco.com と入力しても、同じ証明書を使用してこの Web サイトを認証および暗号化することができます。
CUCM は SAN ヘッダーを作成できます。SAN ヘッダーの詳細については、サポート コミュニティにある Jason Burn のドキュメント『CCMAdmin Web GUI 証明書の CUCM へのアップロード』を参照してください。
ワイルド カード証明書
ワイルドカード証明書は、アスタリスク（*）を使用して URL セクションの任意の文字列を表す証明書です。たとえば、www.cisco.com、ftp.cisco.com、ssh.cisco.com などに対応する証明書が必要な場合、管理者は *.cisco.com の証明書を作成するだけで済みます。コストを節約するために、管理者が購入する必要がある証明書は 1 つだけです。複数の証明書を購入する必要はありません。
この機能は、Cisco Unified Communications Manager （CUCM）では現在サポートされていません。 ただし、この機能拡張については次で追跡することができます。CSCta14114：CUCM と秘密キーのインポートでのワイルドカード証明書のサポートの要求。
証明書の識別
複数の証明書に同じ情報が含まれている場合は、それらが同じ証明書かどうかを確認できます。すべての証明書には一意のシリアル番号があります。このシリアル番号を使用して比較し、証明書が同じ証明書であるか、再生成されたものであるか、または偽造されたものであるかを確認できます。図 9 に例を示します。
図 9：証明書シリアル番号
CSR とその目的
CSR は証明書署名要求のことです。CUCM サーバ用のサードパーティ証明書を作成する場合は、CA に提示する CSR が必要です。この CSR は PEM（ASCII）証明書によく似ています。
\
CUCM は、Web GUI を介して CSR を自動的に作成します。[Cisco Unified Operating System Administration] > [Security] > [Certificate Management] > [Generate CSR] で、証明書を作成するサービスを選択し、[Generate CSR] を選択します。このオプションを使用するたびに、新しい秘密キーと CSR が生成されます。
CSR の作成方法の詳細については、サポート コミュニティにある Jason Burn のドキュメント『CCMAdmin Web GUI 証明書の CUCM へのアップロード』を参照してください。
エンドポイントと SSL/TLS ハンドシェイク プロセス間での証明書の使用
ハンドシェイク プロトコルは、データ転送セッションのセキュリティ パラメータをネゴシエートする一連の順序付けられたメッセージです。SSL/TLSの詳細を参照してください。ハンドシェイクプロトコル 
のメッセージシーケンスを文書化しています。これらは、パケットキャプチャ(PCAP)で確認できます。 詳細には、クライアントとサーバ間で送受信される初期メッセージ、後続のメッセージ、最終メッセージが含まれます。
CUCM による証明書の使用法
tomcat と tomcat-trust との違い
証明書を CUCM にアップロードするときには、Cisco Unified Operating System Administration > [Security] > [Certificate Management] > [Find] でサービスごとに 2 つのオプションを使用できます。
次に、CUCM での証明書の管理に使用できる 5 つのサービスを示します。
-
Tomcat
-
IPSec
-
callmanager
-
capf
-
tvs（CUCM リリース 8.0 以降）
次に、CUCM に証明書をアップロードできるサービスを示します。
-
Tomcat
-
Tomcatの信頼性
-
IPSec
-
Ipsecの信頼性
-
callmanager
-
callmanager-trust
-
capf
-
capf-trust
これらは、CUCM リリース 8.0 以降で使用できるサービスです。
-
tvs
-
tvs-trust
-
phone-trust
-
phone-vpn-trust
-
phone-sast-trust
-
phone-ctl-trust
これらのタイプの証明書の詳細については、『リリース別 CUCM セキュリティ ガイド』を参照してください。このセクションでは、サービス証明書と信頼証明書の違いについてのみ説明します。
たとえば、tomcat では、tomcat-trusts で CA と中間証明書をアップロードします。その結果、この CUCM ノードは、CA および中間サーバによって署名されたすべての証明書が信頼できることを確認できます。tomcat証明書は、エンドポイントがこのサーバにHTTP要求を行う場合に、このサーバのtomcatサービスによって提示される証明書です。tomcatによるサードパーティ証明書の提示を可能にするには、CUCMノードがCAと中間サーバを信頼できることを認識している必要があります。したがって、tomcat（サービス）証明書をアップロードする前に、CA と中間証明書をアップロードする必要があります。
CUCM に証明書をアップロードする方法を理解するのに役立つ情報については、サポート コミュニティにある Jason Burn の『CCMAdmin Web GUI 証明書の CUCM へのアップロード』を参照してください。
各サービスには固有のサービス証明書と信頼証明書があります。それらが別々に機能するようになることはありません。つまり、tomcat-trust サービスとしてアップロードされた CA および中間証明書は、callmanager サービスでは使用できません。
CUCM セキュリティ機能についてその他の具体的な疑問がある場合は、セキュリティ ドキュメントを参照してください。
結論
このドキュメントは、証明書に関する高レベルの知識を身に付けるのに役立ちます。このテーマは重要であり、より詳しく説明することもできますが、このドキュメントでは証明書の扱いに十分慣れ親しんでいただくだけにとどめます。CUCMのセキュリティ機能に関する質問がある場合は、 リリース別CUCMセキュリティガイド 参照してください。
関連情報
- Cisco Unified Communications Manager（CallManager）のメンテナンスおよびセキュリティ ガイド
- Cisco Unified Communications Manager（CallManager）
- Cisco Unified Communications Manager Express
- シスコ サポート コミュニティ：CCMAdmin Web GUI 証明書の CUCM へのアップロード
- バグ CSCta14114：CUCM と秘密キーのインポートでのワイルドカード証明書のサポートの要求
- Cisco Emergency Responder（CER）の説明
- テクニカル サポートとドキュメント – Cisco Systems
フィードバック