PEG のインストールの一部として、証明書を作成します。

前提条件

証明書は、次の 2 つのオプションのいずれかを使用して作成できます。
いずれの場合も、以下が必要です。
  • UID (一意の ID): 実行する各 PEG VM には一意の ID が必要です。以下の条件を満たしていれば、任意の UID を定義することができます。
    • 長さが 18 文字以下
    • a ~ z の文字、0 ~ 9 の数字、ハイフンのみを含む
    • 先頭および末尾がハイフンではない。
    • 連続したハイフンを含んでいない
    • ヒント: UID を簡単に作成するには、オンラインの GUID ジェネレーターから生成された GUID の最後の 18 文字を使用します。
  • PEG DNS 名に使用する apex ドメイン (例: example.com)。

オプション 2 - 自分専用のキーと証明書を作成する

PEG をデプロイする前に、キーと証明書を作成する方法を説明します。

キーと証明書は、Base64 PEM フォーマットでなければなりません (一部のシステムのキー フォーマットでは、openssl または PKCS #8 と呼ばれる)。「共通のタスク - 証明書の作成」に従って証明書を作成します。キーはパスワード保護しないでください。また、キーが「共通のタスク - 証明書の作成」のキーのファイル名列のファイル名と一致していることを確認します。

ターミナルに貼り付けられた証明書がソース証明書と正確に一致することを確認することが重要です。アプリケーションによっては、コピー アンド ペースト中に、隠し文字を含んだファイルが追加される場合があります。問題を回避するには、次の手順が役立ちます。

  • ファイルの内容を確認: 内容をファイルに貼り付けた後、テキスト エディター (nano、vim、または gedit など) を使用して、ファイルの末尾に不要な文字がないか確認します。
  • リダイレクトで echo を使用: 内容を直接貼り付ける代わりに、リダイレクトで echo を使用してファイルを作成します。これにより、隠し文字のリスクが最小限に抑えられます。
  • ファイルをコピーする代わりに、scp を使用してローカル システムからリモート インスタンスにファイルをコピーします。

共通のタスク - 証明書の作成

Base64 PEM 証明書の作成方法について説明します。

証明書を作成する場合は、ドメイン名とファイル名が次のようにマッピングされた 6 つのサーバー Base64 PEM 証明書 (一部のシステムでは openssl フォーマットと呼ばれる) を作成します。ここで、UID は プロセス ディスカバリー によって提供され、apex ドメインは PEG 用に使用する apex ドメインです。作成する各証明書には、リーフ証明書を含めてください。フルチェーン証明書は含めないでください。

表 1. ドメイン名と証明書ファイル名のマッピング
ドメイン 証明書ファイル名 キー ファイル名 (自分専用のキーを作成した場合のみ必要)
analytics-fiq-<UID>.<apex domain> analytics-cert.pem analytics-key.pem
proxy-fiq-<UID>.<apex domain> proxy-cert.pem proxy-key.pem
storage-fiq-<UID>.<apex domain> storage-cert.pem storage-key.pem
st-fiq-<UID>.<apex domain> st-cert.pem st-key.pem
dlp-fiq-<UID>.<apex domain> dlp-cert.pem dlp-key.pem
es-fiq-<UID>.<apex domain> es-cert.pem es-key.pem
klite-fiq-<UID>.<apex domain> klite-cert.pem klite-key.pem
注: すべての SAN を含む 1 つの証明書を作成できます。必要に応じて、キーを作成する場合に、キーを 1 つだけ作成することもできます。ただし、引き続き、その証明書の 7 つのコピーと、前述したとおりに命名されたキー (キーを作成した場合) の 7 つのコピーが存在することを確認する必要があります。ワイルドカード証明書は作成しないでください。

考慮事項

PEG をインストールするための証明書を作成する場合は、次の考慮事項を確認してください。
  • ワイルドカード証明書は許可されない: PEG のデプロイではワイルドカード証明書は使用できません。各証明書は、特定のドメイン名を持つ各サービスごとに個別に作成する必要があります。
  • 証明書はグローバルに有効ではない: 内部 CA 生成の証明書は、外部システムではグローバルに信頼されているものとして認識されないため、すべてのクライアント デバイスまたはサービスで手動で信頼する必要があります。
  • 証明書を手動で検証する: 証明書は、正しいこと、および転送中の破損や改ざんがないことを確認するために、各デプロイ段階で手動で検証する必要があります。
  • 証明書を手動で転送する: 証明書は仮想マシン (VM) に手動でコピーする必要がありますが、コピーの操作が不適切だったり、コピー プロセス中にファイルが変更されたりすると、潜在的なエラーが発生するおそれがあります。
  • すべてのマシンで有効な証明書を確認する: すべての証明書が有効であり、これらの証明書によって保護されたサービスにアクセスする必要があるすべてのマシンに正しくインストールされていることを確認することが重要です。
  • 証明書は自動的に更新されない: 内部証明書はグローバル CA システムと統合されていないため、自動化された更新プロセスはありません。管理者は、サービスの中断を防ぐために、証明書を有効期限が切れる前に手動で追跡して更新する必要があります。
  • 信頼するための構成を追加する: PEG サービスにアクセスする各クライアントまたはシステムは、内部 CA 証明書を信頼するように手動で構成する必要があります。これには、ルート証明書のインストールやセキュリティ設定の調整が必要になる場合があります。
  • ヒューマン エラーのリスクがある: 証明書の作成、検証、配布は手動で行われるため、ファイル名の誤り、無効な構成、証明書の欠落などのヒューマン エラーが発生する可能性が高くなります。
  • 失効と監査が限定的である: 内部 CA の設定には高度な失効メカニズム (証明書失効リストや OCSP など) が不足している場合があり、侵害された証明書や有効期限切れの証明書を無効にすること、およびその使用状況を効果的に監査することが難しくなります。
  • スケーリングが難しい: システムの拡張に伴い、複数の仮想マシン (VM) と環境にわたって多数の証明書を手動で管理することが困難になり、一貫性を確保するために専用のプロセスが必要になります。