【暗号化】証明書と秘密鍵について

はじめに

現在、様々な通信で暗号化の使用が一般的となっています。ネットワークデバイスについても例外ではなく、機器単体の管理やオーケストレーションのGUIでWebブラウザーを使用するものはhttpsを、CLIにおいてもSSHが使用されています。

その他、ADC製品がhttpsなどの暗号化通信に介在する構成、ZTNAやSSL-VPNのフロントエンドなど、様々な環境で暗号化の取り扱いが必要となっています。

今回、筆者が携わった作業より、この暗号化通信と証明書の実装に関わる情報をお送りさせて頂きます。

暗号化に必要なもの

この記事では、例としてネットワークデバイスの管理UIなどを筆頭とした、httpsを題材にします。

多くのネットワークデバイスなどでは、製品の初期状態で内部の証明機関による自己証明書（通称：オレオレ証明書）を発行して、GUIでの管理画面（https）を有効化しています。当然ながら、アクセスデバイスからは有効な証明書として扱われないため、ブラウザーでアクセスした際に以下のようなエラーが表示されます。

自己証明書であっても、実際の通信そのものは暗号化されているため、これを良しとして継続使用する環境もあれば、信頼できるCAの発行でない証明書は使用が不可とされ、提供される証明書と秘密鍵をインストールさせて頂くケースもあります。

有効期限の管理や更新の反映など、運用面の負担と比較してどちらを選択するものであるかは、環境や利用するエンドユーザー様や管理者のポリシーによるものですが、筆者の見解としては以下の通りです。

• ・当然、イントラネットを含む全てに信頼されたCAの証明書を実装するのが理想論ではある
• ・インターネットなど広域な不特定多数と疎通するサービスであれば、必ず信頼されたCAが発行する証明書を使用する
• ・関連するコストが問題となる場合や、公開されないイントラネットなどに限定される環境おいては、管理者として信頼できるプライベートCA（Active Directory Certificate Servicesなど）での発行も可

証明書がインポートできない事例

改めて、httpsの実装において、サービスを提供するサーバー側では以下が必要になります。

• ・証明書
• ・秘密鍵

実際の作業においても、この2つをご用意頂いた作業端末をお借りして構築を進めることが多いのですが、インストールするサーバー側で証明書と秘密鍵を照合できず、取り込みが完了できないケースがありました。

このケースでも、ZTNAのサービスでhttpsを構成するために、証明書と秘密鍵をファイルとしてご提供を頂き、サーバーとして終端するネットワーク機器へアップロードして作業をしていました。しかし、正常にインポートできずエラーが発生したため、秘密鍵のファイルをテキストエディタで確認すると以下のようになっていました。

-----BEGIN ENCRYPTED PRIVATE KEY-----
<<（保護された秘密鍵）>>
-----END ENCRYPTED PRIVATE KEY-----

「ENCRYPTED」となっています。この状態は秘密鍵そのものがパスフレーズで暗号化されており、今回インポートするサーバー（ネットワーク機器）では証明書と照合することができないため、復号した状態に変換する必要があります。実際の手順として、一般的に使用されるOpenSSLでは、以下のようなコマンドで復号が可能です。

openssl rsa -in private.key -out private-decrypted.key -traditional
Enter pass phrase for private.key
<<秘密鍵を生成した際のパスフレーズを入力>>

このコマンドから、以下の復号されたファイルを生成することができます。

-----BEGIN RSA PRIVATE KEY-----
<<（復号された秘密鍵）>>
-----END RSA PRIVATE KEY-----

このケースでは、前述の手順で複合した秘密鍵と証明書で、サーバーへ証明書の取り込みが問題なく完了しました。様々なOSやソフトウェアで、今回のようなインポート時に秘密鍵がパスフレーズで暗号化されていると、サーバー側で証明書と照合ができない（インポート時にパスフレーズを入力して復号する機構がない）ものが多く存在します。（秘密鍵のパスフレーズ保護に対応したものでも、当然ながらこのパスフレーズの入力が必要となります。）

このため、このケースにおけるネットワーク機器など、パスフレーズ保護された秘密鍵に対応しない機構に証明書をインポートする場合は、秘密鍵をエクスポートする際に、保護を解除した状態（秘密鍵として直接的に証明書と照合可能な形態）とする必要があることをご案内させて頂きました。

また、当然ですが秘密鍵は暗号化に最も重要な情報です。秘密鍵の漏洩は直接的に暗号化の安全性を失うため、お取り扱いには十分にご留意下さい。

※予めホームページへの掲載許可を頂いた事例のみを記載しています。

証明書の期限切れに関連する不具合

httpsのようなプロトコルであれば、仮に有効期限が切れてしまった場合でも、エラーメッセージの表示などを考慮しなければ、通信動作そのものは継続可能です。しかし、証明書の使途によっては、大きな影響を及ぼすものが存在します。

HA構成のデバイスやOSの間で、相互に信頼関係を構成している場合などがこれに該当しますが、今回の記事では当社が実際にお問い合わせを頂いた、Cisco Systems社の製品における一例を記載させて頂きます。

【期限切れが動作に影響する一例】Cisco Systems社製品の場合

証明書や暗号化に関連して、運用の不具合で当社にお問い合わせを頂いたケースは、直近で以下がありました。

Cisco Secure Firewall FDMで管理するFTDのアップグレードが失敗する
※詳細情報の閲覧には、Ciscoアカウントでのログインが必要です。

Bug Search Tool

https://bst.cisco.com/quickview/bug/CSCwd11825

bst.cisco.com

この問題は、FDMのGUI管理画面（https）で使用している証明書の有効期限が超過している場合、OSのアップグレードに失敗するというものです。Workaroundは、この証明書を有効期限が超過していない新たなものに差替えるものですが、HAを構成している場合、まずHAを解除してから双方の証明書を新しいものに差し替え、この後に再度HAを構成する手順が必要となります。

当社にお問い合わせを頂いたケースもまさに上記に該当し、2024年8月に推奨バージョンとなった7.2.8へのアップグレードを管理者様が試行されたところ、アップグレードが完了せずに元のバージョンへロールバックされてしまうものでした。このケースは幸いにも緊急で十分なメンテナンス時間を確保できる環境であったため、前述のWorkaroundに基づいた作業で問題が解消され、正常にアップグレードも完了することができました。

※筆者個人としては、この問題はそもそも証明書の有効期限が失効しているために引き起こされるものであり、ソフトウェアの不具合とは感じられません。Bug Search Toolに掲載されている事象ですが、アップグレードができないことそのものは通信動作に対する致命的な影響はなく、実態としては構造に対するKnowledge Baseの意味合いが強い、注意喚起として受け止めています。

※予めホームページへの掲載許可を頂いた事例のみを記載しています。

まとめ

いかがだったでしょうか。

今日では当たり前となっている通信の暗号化ですが、サービスを構成して運用するには様々な見識が必要となります。さらに、証明書を使用した環境には、有効期限の管理や秘密鍵の取扱いなどの管理コストが伴い、これが適切でない場合は逆にセキュリティリスクとなってしまう恐れもあります。

皆様の環境では暗号化プロトコルや証明書は使用されていますでしょうか。使用されている証明書や秘密鍵に適切な管理がなされていますでしょうか。セキュリティと運用負荷のどちらを優先するかに一律な正解はなく、それぞれの環境で明確なポリシーを定め改善を続けていくべきものだと筆者は考えています。

今回の記事は、直近で当社へお問い合わせを頂いたケースから2点を取り上げて、関連する情報を注意喚起のためにお送りさせて頂きました。

この記事が、ご覧いただいた皆様へ少しでもお役に立てば幸いです。

• ※この記事は筆者個人の見解によるものであり、各メーカー様や当社としての意見や見解を示すものではありません。
• ※この記事に含まれる情報については、その内容について当社として何らの保証をするものではありません。
• ※この記事に含まれる情報を利用したことに起因する、利用者又は第三者が被る直接的及び間接的損害に関して、当社はその責任を一切負いません。

• ← 前の記事に戻る
• 一覧に戻る