Expressway証明書のトラブルシューティング

はじめに

このドキュメントでは、証明書の仕組みと、Expresswayサーバでの証明書に関する最も一般的な問題とヒントについて説明します。

前提条件

要件

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

• ExpresswayおよびVideo Communications Server(VCS)サーバ
• セキュアソケットレイヤ(SSL)
• 証明書
• Telepresenceデバイス
• モバイルおよびリモート アクセス
• コラボレーション導入

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

• Expressway x14

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

背景説明

SSLと証明書は標準に準拠し、他のデバイスやブランドでも同じように動作します。このドキュメントでは、Expresswayでの証明書の使用について説明します。

定義

証明書は、2台のデバイス間でセキュアな接続を確立するために使用されます。サーバまたはデバイスのIDを認証するデジタル署名です。Hypertext Transfer Protocol Secure(HTTPS)やSession Initiation Protocol(SIP)Transport Layer Security(TLS)などのプロトコルが機能するには、証明書を使用する必要があります。

証明書に関する説明では、次の異なる用語が使用されます。

• 証明書署名要求(CSR)：後で署名してクライアント証明書またはサーバ証明書に変換するためにデバイスを識別する名前で作成されるテンプレート。
• 証明書：署名済みのCSR。これらは一種のIDであり、SSLネゴシエーションで使用するためにデバイスにインストールされます。証明書は、それ自体または認証局によって署名できます。
• 証明書の署名：対象となる証明書を検証するIDは正当なものであり、別の証明書の形式で提示されます。
• 自己署名証明書：自身で署名されたクライアントまたはサーバの証明書。
• 認証局(CA)：証明書に署名するエンティティ。
  • 中間証明書：自身ではなく、別のCA証明書によって署名されるCA証明書。通常はルート証明書によって署名されますが、別の中間証明書によって署名されることもあります。
  • ルート証明書：自身で署名したCA証明書。

基本原則

クライアントがサーバと通信し、SSL通信を開始すると、クライアントは証明書を交換します。これらは後で、デバイス間のトラフィックを暗号化するために使用されます。

交換の一部として、デバイスは証明書が信頼できるかどうかも判断します。証明書が信頼できるかどうかを判断するには、次のような複数の条件を満たす必要があります。

• サーバに接続するために最初に使用される完全修飾ドメイン名(FQDN)。これは、サーバによって提示される証明書内の名前と一致する必要があります。
  • たとえば、ブラウザでWebページを開くと、cisco.comは証明書を提供するサーバのIPに解決されます。この証明書を信頼するには、名前としてcisco.comを含める必要があります。

• サーバから提示されたサーバ証明書に署名したCA証明書（自己署名の場合は同じサーバ証明書）が、デバイスのCA信頼できる証明書リストに存在します。
  • デバイスには信頼されているCA証明書のリストがあり、コンピュータにはよく知られたパブリック認証局があらかじめ作成されたリストが含まれていることがよくあります。

• 現在の日付と時刻は、証明書の有効期間内です。
  • 認証局は、CAによって決定される一定時間だけCSRに署名します。

• 証明書は失効していません。
  • パブリック認証局は、証明書内に証明書失効リスト(CRL)URLを定期的に組み込みます。これは、証明書を受信した側が、CAによって失効されていないことを確認できるようにするためです。

一般的な問題

Expressway証明書のアップロードが失敗する

この問題の原因となる状況がいくつかあります。これらは別の説明エラーを引き起こします。

証明書の形式が無効

この最初のエラーは、証明書が有効な形式でない場合に発生します。ファイル拡張子は重要ではありません。

証明書が開かない場合は、正しい形式の新しい証明書をCAから要求できます

証明書が開く場合は、次の手順を実行します。

ステップ 1：証明書を開き、Detailsタブに移動します。
ステップ 2：Copy to Fileを選択します。
ステップ 3：ウィザードを完了し、Base-64 encodedが選択されていることを確認します。

証明書の形式の選択

ステップ 4：保存したら、新しいファイルをExpresswayにアップロードします。

信頼されていないCA証明書チェーン

このエラーは、サーバ証明書に署名したCA証明書が信頼されていない場合に発生します。サーバ証明書をアップロードする前に、サーバはチェーン内のすべてのCA証明書を信頼する必要があります。

通常、CAは署名付きサーバ証明書とともにCA証明書を提供します。これらが使用可能な場合は、次のステップ6に進んでください。

CA証明書が使用できない場合は、サーバ証明書から取得できます。次の手順を実行します。

ステップ 1：サーバ証明書を開きます。
ステップ 2：Certification Pathタブに移動します。最上位の証明書は、ルートCA証明書と見なされます。下の方はサーバ証明書で、中間のすべての証明書は中間CA証明書と見なされます。
ステップ 3：CA証明書を選択し、View Certificateを選択します。

認証パス

ステップ 4：Detailsタブに移動し、前の手順を実行して、証明書を別のファイルに保存します。
ステップ 5：存在するすべてのCA証明書について、これらの手順を繰り返します。

Certificate Detailsタブ

すべてのCA証明書が使用可能になったら、それらをExpresswayの信頼済みCA証明書リストにアップロードします。

手順 6：Expresswayサーバで、Maintenance > Security > Trusted CA Certificateの順に移動します。
手順 7：Choose Fileとuploadを選択します。
ステップ 8：各CA証明書について手順7を繰り返します。
ステップ 9：すべてのCA証明書が信頼リストにアップロードされたら、サーバ証明書をサーバにアップロードします。

TLSネゴシエーションエラーによるトラバーサルゾーンのダウン

このエラーは、Expressway-CとExpressway-E間のSSL交換が正常に完了していない場合に発生します。この問題を引き起こす可能性のあるいくつかの例を次に示します。

• ホスト名が、提示された証明書の名前と一致しません。
  • Expressway-Cトラバーサルゾーンに設定されたピアアドレスが、Expressway-Eサーバ証明書の名前の少なくとも1つと一致していることを確認します。
• TLS検証サブジェクト名が、提示された証明書の名前と一致しません。
  • Expressway-Eトラバーサルゾーンに設定されているTLS検証サブジェクト名が、Expressway-Cサーバ証明書の名前のいずれかに一致していることを確認します。クラスタ設定の場合は、Expressway-CクラスタのFQDNをTLS検証サブジェクト名として設定することをお勧めします。これは、この名前がクラスタのすべてのノードに存在する必要があるためです。
• CA証明書はサーバによって信頼されません。
  • サーバ証明書をアップロードする前に各サーバが独自のCA証明書を信頼する必要があるのと同様に、他のサーバもサーバ証明書を信頼するためにこれらのCA証明書を信頼する必要があります。そのためには、両方のExpresswayサーバの認証パスからのすべてのCA証明書が、関係するすべてのサーバの信頼済みCAリストに含まれていることを確認します。CA証明書は、このドキュメントで前述した手順で抽出できます。

証明書の更新後のトラバーサルゾーンのアップとSSHトンネルのダウン

SSHトンネル障害

このエラーは、通常、証明書の更新後に、1つ以上の中間CA証明書が信頼されていない場合に発生し、ルートCA証明書の信頼によってトラバーサルゾーン接続が有効になりますが、SSHトンネルはより詳細な接続であるため、チェーン全体が信頼されていない場合は失敗する可能性があります。

中間CA証明書は認証局によって変更されることが多いため、証明書の更新によってこの問題が引き起こされる可能性があります。すべての中間CA証明書がすべてのExpressway信頼リストにアップロードされていることを確認します。

アップグレードまたは証明書の更新後にモバイルおよびリモートアクセスログインが失敗する

証明書が原因でログインが失敗する方法は数多くありますが、Expresswayソフトウェアの最近のバージョンでは、セキュリティ上の理由から、以前は行われなかった場所で証明書の検証を強制的に行う変更が実装されています。

これについては、次の方法で詳しく説明します。トラフィックサーバが証明書検証を実施する

回避策からわかるように、Expressway-C CA証明書がCisco Unified Communications Managerにtomcat-trustおよびcallmanager-trustとしてアップロードされていることを確認し、必要なサービスを再起動します。

モバイルおよびリモートアクセスログイン時のJabberの証明書アラーム

Jabberの信頼できない証明書の警告

この動作は、アプリケーションで使用されているドメインがExpressway-Eサーバ証明書のサブジェクト代替名と一致しない場合に発生します。
example.comまたは代替collab-edge.example.comが、証明書に存在するサブジェクトの別名の1つであることを確認します。

関連情報

シスコのテクニカルサポートとダウンロード