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

ロード・バランシング・サービスを介してSSL証明書をインポートおよび管理できますが、サービスでは証明書は生成されません。 SSL証明書は、VeriSignやGoDaddyなどのベンダーによって発行される証明書、またはOpenSSLやLet's Encryptなどのツールを使用して生成する自己署名証明書です。

リスナーにHTTPSまたはSSLを構成する場合は、SSLサーバー証明書をロード・バランサに関連付ける必要があります。証明書によって、ロード・バランサは、接続を終了し、受信リクエストをバックエンド・サーバーに渡すことができます。次のSSL構成をロード・バランサに適用できます:

SSLターミネーション: ロード・バランサは受信SSLトラフィックを処理し、暗号化されていないリクエストをバックエンド・サーバーに渡します。
ポイント・ツー・ポイントSSL: ロード・バランサは、受信トラフィック・クライアントとのSSL接続を終了し、バックエンド・サーバーへのSSL接続を開始します。
SSLトンネリング: TCPトラフィック用にロード・バランサのリスナーを構成する場合、ロード・バランサは受信SSL接続をアプリケーション・サーバーにトンネリングします。

ロード・バランシングでは、デフォルトで「強い」暗号強度が設定されたTLS 1.2プロトコルがサポートされます。

ロード・バランサとそのリソースで標準SSLを使用するには、証明書を指定する必要があります。ロード・バランサで相互TLS (mTLS)を使用するには、1つ以上の認証局バンドル(CAバンドル)をシステムに追加する必要があります。証明書バンドルには、公開証明書、対応する秘密キー、および関連する認証局(CA)証明書が含まれます。証明書バンドルは、関連付けるリスナーまたはバックエンド・セットを作成する前にアップロードすることをお薦めします。 PEM形式のX.509証明書のみが受け入れられます。

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

SSLトラフィック処理構成

保護された接続の様々なステージでSSLトラフィックを様々な方法で処理するようにロード・バランサを構成できます。

ロード・バランサでのSSLの停止

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

SSLをロード・バランサでターミネートするには、443などのポートでリスナーを作成した後、アップロードした証明書バンドルをリスナーに関連付ける必要があります。

バックエンドSSLの実装

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

ロード・バランサとバックエンド・サーバー間にSSLを実装するには、アップロードした証明書バンドルをバックエンド・セットに関連付ける必要があります。

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

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

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

「ポイント・ツー・ポイントSSL」構成では、ロード・バランサはクライアントからのSSL暗号化トラフィックを受け入れ、バックエンド・サーバーへのトラフィックを暗号化します。

ポイント・ツー・ポイントSSLを実装するには、アップロードした証明書バンドルをリスナーとバックエンド・セットの両方に関連付ける必要があります。

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

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

サーバー証明書( ssl-certificate.crt)と中間CA証明書( intermediate-ca-cert.crt)ファイルを1つの連結されたPEMファイルに結合します:

cat ssl_certificate.crt intermediate-ca-cert.crt >> certbundle.pem

ピア証明書の検証

ロード・バランサでSSLが設定されている場合、リスナーは、クライアントが信頼性を検証できる証明書を使用して受信クライアント・リクエストに応答します。ピア証明書検証を有効にすると、セキュリティの層が追加されます: クライアント(ピア)は、リスナーが検証できる証明書を提示する必要があります。つまり、ピア証明書検証は、クライアントとサーバーの間で相互認証を確立します。

ピア証明書の検証が正しく構成されていない場合、クライアントは証明書を検証できず、クライアントSSLハンドシェイクの失敗を返します。エラー・メッセージはクライアント・タイプによって異なります。 OpenSSLユーティリティを使用して、検証が失敗する深さを確認できます:

$ openssl verify -verbose -CAfile root-cert.pem intermediate-cert.pem
error 20 at 0 depth lookup: unable to get local issuer certificate

これらの検証エラーを解決するには、クライアント証明書と認証局の証明書が一致していることを確認し、証明書が正しい順序に含まれていることを確認します。

SSLキーの問題

ロード・バランサのSSLを構成するときに、次のキー関連の問題が発生することがわかっています。

キー・ペアの不一致

秘密キーと公開キーが一致しない場合、アップロードしようとすると不一致エラーが発生します。次のOpenSSLコマンドを使用して、公開キーと秘密キーが同じペアの一部であることを確認します:

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

これらのコマンドから返されたsha1ハッシュ値は、正確に一致する必要があります。それらが異なる場合、秘密キーはパブリック証明書の署名に使用されず、このキーは使用できません。

秘密キーの整合性

一般に、秘密キーに関連するエラーが発生した場合は、OpenSSLユーティリティを使用してキーの一貫性をチェックできます。このコマンドは、キーが変更されていないこと、パスフレーズが正しいこと、およびファイルに有効なRSA秘密キーが含まれていることを確認します:

openssl rsa -check -in private_key.pem

秘密キーの復号化

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

openssl rsa -in private_key.pem -out private_key_decrypted.pem