ロード・バランサのSSL証明書

ロード・バランサでSecure Socket Layer (SSL)証明書を使用します。

ノート

このトピックでは、ロード・バランサ・サービス内でSSL証明書を作成および管理する方法について説明します。Oracleでは、証明書の作成および管理に証明書サービスを使用することを強くお薦めします。詳細は証明書を参照してください。

ロード・バランサとそのリソースで標準SSLを使用するには、証明書を指定する必要があります。

ロード・バランサで相互TLS (mTLS)を使用するには、1つ以上の認証局(CA)または認証局バンドル(CAバンドル)をシステムに追加する必要があります。

  • 認証局: リーフ証明書を発行できるプライベート認証局。ロード・バランサとその関連リソースの場合、CAは証明書サービス内で作成されたトラスト・ストアであり、ユーザーはアップロードされません。

  • CAバンドル: 集約グループとしてアップロードできるCA公開証明書のコレクション。CAバンドルには、秘密キーまたはリーフ証明書は含まれません。

ヒント

関連付けるリスナーまたはバックエンド・セットを作成する前に、使用する証明書バンドルをアップロードすることをお薦めします。

次のSSL証明書タスクを実行できます:

ロード・バランサでは、通常、単一のドメイン証明書が使用されます。ただし、リクエスト・ルーティング構成を含むリスナーを含むロード・バランサ(ロード・バランサのリクエスト・ルーティングを参照)では、サブジェクト代替名(SAN)証明書(マルチドメイン証明書とも呼ばれる)またはワイルドカード証明書が必要になる場合があります。ロード・バランシング・サービスは、これらの各証明書タイプをサポートします。

ノート

  • ロード・バランサ・サービスはSSL証明書を生成しません。すでに所有している既存の証明書のみをインポートできます。証明書は、VerisignやGoDaddyなどのベンダーが発行したものにすることができます。また、OpenSSLLet's Encryptなどのオープン・ソース・ツールを使用して生成する自己署名証明書を使用することもできます。自己署名証明書を生成する方法の手順は、対応するツールのドキュメントを参照してください。

  • バックエンドSSLの自己署名証明書を送信する場合は、対応するCA証明書フィールドに同じ証明書を送信する必要があります。

Oracle Cloud Infrastructureは、x.509タイプの証明書をPEM形式のみで受け入れます。次に、PEMエンコード証明書の例を示します:


-----BEGIN CERTIFICATE-----
<Base64_encoded_certificate>
-----END CERTIFICATE-----

PEM形式への変換

証明書とキーをPEM以外の形式で受信した場合は、システムにアップロードする前にそれらを変換する必要があります。OpenSSLを使用して、証明書とキーをPEM形式に変換できます。次のコマンド例でガイダンスを提供します。

証明書または証明書チェーンをDERからPEMへ

openssl x509 -inform DER -in <certificate_name>.der -outform PEM -out <certificate_name>.pem

秘密キーをDERからPEMへ

openssl rsa -inform DER -in <private_key_name>.der -outform PEM -out <private_key_name>.pem

証明書バンドルをPKCS#12 (PFX)からPEMへ

openssl pkcs12 -in <certificate_bundle_name>.p12 -out <certificate_bundle_name>.pem -nodes

証明書バンドルをPKCS#7からPEMへ

openssl pkcs7 -in <certificate_bundle_name>.p7b -print_certs -out <certificate_bundle_name>.pem

ピア証明書の検証の構成

クライアント認証にはピア証明書の検証が使用されます。ピア証明書の検証の深さは、クライアント認証で検証する必要があるチェーン内の証明書の数です。

次は、設定することが予想される値です:

  • 1つの中間証明書、クライアント証明書、ルート証明書 - 2

  • クライアント証明書、ルート証明書 - 1

ピア証明書の検証が誤って構成されているかどうかを判断するには、次に注意してください:

  • クライアントは、証明書を検証できず、クライアントSSLハンドシェイクが失敗することを示します。このエラー・メッセージは、クライアント・タイプによって異なります。

  • ロード・バランサのログに、次のエラーが表示されます: Client %s has SSL certificate verify error

  • OpenSSLユーティリティを使用して、次のコマンドを実行します: openssl verify -verbose -CAfile RootCert.pem Intermediate.pem

    検証の失敗が発生している深さを示すエラーが発生します: error 20 at 0 depth lookup:unable to get local issuer certificate

この状況を解決するには、正しい証明書の深さを指定し、クライアント証明書と認証局の証明書が一致していること、およびそれらが正しい順序であることを確認します。

証明書チェーンのアップロード

1つの証明書チェーンを形成する証明書(中間認証局証明書など)が複数ある場合は、システムにアップロードする前に、関連するすべての証明書を1つのファイルに正しい順序で含めます。信頼できるルート認証局によって直接署名された証明書をリストの一番下にして開始するのが正しい順序です。追加の証明書は、署名証明書の上位に貼り付けます。

サーバー証明書(SSL_Certificate.crt)と中間認証局証明書(intermediateCA.crt)のファイルを、連結された1つのファイルに結合します。

SSL証明書と中間認証局証明書から連結された1つのファイルを取得するには、コマンド・プロンプトを開いて、次のコマンドを実行します:

cat ssl_certificate.crt IntermediateCA.crt >> certbundle.pem

次に示す連結された証明書チェーン・ファイルの例には、4つの証明書が含まれています:

-----BEGIN CERTIFICATE-----
Base64-encoded_certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded_certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded_certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded_certificate
-----END CERTIFICATE-----

秘密キーの送信

ノート

Oracleでは、RSA秘密キーに2048ビット以上の長さをお薦めします。

秘密キーの送信でエラーが返された場合の最も一般的な理由は3つあります:

  • 指定したパスフレーズが正しくありませんでした。

  • 秘密キーの形式が不正です。

  • システムがキーで使用されている暗号化方式を認識していません。

キー・ペアの不一致

秘密キーと公開キーの不一致に関連するエラーを受信した場合、アップロードの前に、次のOpenSSLコマンドを使用してそれらが同じペアの一部であることを確認します:

openssl x509 -in certificate_name.crt -noout -modulus | openssl sha1
openssl rsa -in private_key.key -noout -modulus | openssl sha1

返されたsha1ハッシュ値が完全に一致していることを確認します。それらが異なる場合、指定された秘密キーはパブリック証明書の署名に使用されず、使用できません。

秘密キーの整合性

秘密キーに関連するエラーが発生した場合は、OpenSSLを使用してその整合性をチェックできます:

openssl rsa -check -in <private_key>.pem

このコマンドは、キーが完全であること、パスフレーズが正しいこと、およびファイルに有効なRSA秘密キーが含まれていることを確認します。

秘密キーの復号化

システムが秘密キーで使用されている暗号化テクノロジを認識していない場合、そのキーを復号化します。暗号化されていないバージョンのキーと証明書バンドルをアップロードします。OpenSSLを使用して秘密キーを復号化できます:

openssl rsa -in <private_key>.pem -out <decrypted_private_key>.pem

SSL処理の構成

ロード・バランサ・リソースのSSL処理の構成について学習します。

ロード・バランサに対して次のSSL処理タスクを実行できます:

  • ロード・バランサでSSLを終了します。この構成はフロントエンドSSLです。ロード・バランサは、クライアントから暗号化されたトラフィックを受け入れることができます。ロード・バランサとバックエンド・サーバー間にトラフィックの暗号化は存在しません。

  • ロード・バランサとバックエンド・サーバー間にSSLを実装します。この構成はバックエンドSSLです。ロード・バランサは、クライアント・サーバーから暗号化されたトラフィックを受け入れません。ロード・バランサとバックエンド・サーバー間のトラフィックは暗号化されます。

  • ポイント・ツー・ポイントSSLを実装します。ロード・バランサは、クライアントからSSLで暗号化されたトラフィックを受け入れ、バックエンド・サーバーへのトラフィックを暗号化できます。

ロード・バランサでのSSLの終了

ロード・バランサでSSLを終了するには、443などのポートでリスナーを作成してから、アップロードした証明書バンドルをリスナーに関連付ける必要があります。詳細は、Load Balancerリスナーの作成を参照してください。

バックエンドSSLの実装

ロード・バランサとバックエンド・サーバー間にSSLを実装するには、アップロードした証明書バンドルをバックエンド・セットに関連付ける必要があります。詳細は、Load Balancerバックエンド・セットの作成を参照してください。

ノート

  • バックエンド・セットに複数のバックエンド・サーバーを含める場合は、中間CA証明書を使用してバックエンド・サーバーに署名します。中間CA証明書が証明書バンドルの一部として含まれる必要があります。

  • バックエンド・サービスはSSLを受け入れて終了できる必要があります。

ポイント・ツー・ポイントSSLの実装

ポイントツーポイントSSLを実装するには、証明書バンドルをリスナーとバックエンド・セットの両方に関連付ける必要があります。詳細は、Load Balancerリスナーの作成およびLoad Balancerバックエンド・セットの作成を参照してください。