Amazon Elastic Load Balancingでの1つの方法(またはサーバー側)TLS/HTTPSは 十分に文書化されています
双方向(またはクライアント側)TLS/HTTPSのサポートは、ドキュメントから明確ではありません。
ELBがTLS/HTTPS接続を終了すると仮定します。
ELBはTCP転送をサポートしているため、EC2ホストサーバーは双方向TLS/HTTPS接続を確立できますが、この場合、ELBがTLS/HTTPS接続を終了してクライアントを識別することに関心があります。
ELBが2番目のTCP=バックエンドサーバーへの接続を確立しており、内部でペイロードを復号化/暗号化しているため、ダブルエンドHTTPSモードでどのようにそれができるかわかりません。/from the client and server ...したがって、サーバーはクライアント証明書を直接見ることができず、-For、-Proto、および-Port以外の文書化されたX-Forwarded- *ヘッダーはありません。
一方、ELBがTCP=モードで実行されている場合、クライアントとサーバー間で直接SSLネゴシエーションが行われ、ELBはストリームを盲目的に結び付けます。サーバーが PROXY
protocol 、次のことができます ELBでその機能を有効にする これにより、サーバーでクライアントの発信元IPおよびポートを識別できるだけでなく、クライアント証明書を直接識別できます。クライアントはあなたと直接交渉します...これは、SSLをELBにオフロードしないことを意味します。これは、あなたがしようとしていることのポイントの一部である可能性があります。
更新:
ELBだけで、SSLをオフロードしてクライアント証明書を特定するなど、やりたいことをすべて実行する方法はないようです。以下の情報は、「価値があるもののために」提示されています。
どうやらHAProxyには バージョン1.5のクライアント側の証明書のサポート があり、証明書情報をX-
ヘッダー。 HAProxyは設定を介してPROXY
プロトコルもサポートするため(- tcp-request connection expect-proxy
)...したがって、TCPモードELBの背後でHAProxyを使用し、HAProxyがSSL接続を終了して転送するbothELBからのクライアントIP /ポート情報(PROXY
プロトコルを介して)およびクライアント証明書情報をアプリケーションサーバーに。 。したがって、SSLオフロードを引き続き維持できます。
私がこれを補足するのは、おそらくどちらかのプラットフォームだけよりも機能が充実しているようであり、少なくとも1.4では、2つの製品が完璧に連携するためです。私は、ELBの背後でHAProxy 1.4を使用して、最大のWebプラットフォーム(私の場合、ELBはSSLをオフロードしています-クライアント証明書はありません)。カスケードされたロードバランサーの明らかな冗長性にもかかわらず、それは確かな組み合わせのようです。 ELBだけが大きな悪いインターネット上に存在するのが好きですが、直接露出されたHAProxyだけでは問題があると考える理由はありません。私のアプリケーションでは、ELBはA/ZのHAProxiesの間でバランスをとるためにあります(私はもともと自動スケーリングも意図していましたが、忙しい季節でもCPU使用率が非常に低いので、アベイラビリティーゾーン、私は決して失われていませんが...)配信前にヘッダーのフィルタリング、転送、および変更を行うことができます実際のプラットフォームへのトラフィックに加えて、ELBだけでは得られないロギング、リライト、およびトラフィック分割の制御を提供します。
バックエンドがクライアント認証HTTPS接続自体をサポートできる場合は、ELBをTCPポート443でTCPバックエンドがリッスンするポートで使用できます。これにより、ELBは暗号化されていないリクエストを直接バックエンドに再送信するだけです。この構成では、ロードバランサーにSSL証明書をインストールする必要もありません。
更新:このソリューションでは、x-forwarded- *ヘッダーが設定されていません。
Elastic Beanstalkで単一インスタンスに切り替え、 ebextensions を使用して証明書をアップロードし、相互TLSのnginxを設定できます。
例
.ebextensions/setup.config
files:
"/etc/nginx/conf.d/00_elastic_beanstalk_ssl.conf":
mode: "000755"
owner: root
group: root
content: |
server {
listen 443;
server_name example.com;
ssl on;
ssl_certificate /etc/nginx/conf.d/server.crt;
ssl_certificate_key /etc/nginx/conf.d/server.key;
ssl_client_certificate /etc/nginx/conf.d/ca.crt;
ssl_verify_client on;
gzip on;
send_timeout 300s;
client_body_timeout 300s;
client_header_timeout 300s;
keepalive_timeout 300s;
location / {
proxy_pass http://nodejs;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Host $Host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-SSL-client-serial $ssl_client_serial;
proxy_set_header X-SSL-client-s-dn $ssl_client_s_dn;
proxy_set_header X-SSL-client-i-dn $ssl_client_i_dn;
proxy_set_header X-SSL-client-session-id $ssl_session_id;
proxy_set_header X-SSL-client-verify $ssl_client_verify;
proxy_connect_timeout 300s;
proxy_send_timeout 300s;
proxy_read_timeout 300s;
}
}
"/etc/nginx/conf.d/server.crt":
mode: "000400"
owner: root
group: root
content: |
-----BEGIN CERTIFICATE-----
MIJDkzCCAvygAwIBAgIJALrlDwddAmnYMA0GCSqGSIb3DQEBBQUAMIGJMQswCQYD
...
LqGyLiCzbVtg97mcvqAmVcJ9TtUoabtzsRJt3fhbZ0KKIlzqkeZr+kmn8TqtMpGn
r6oVDizulA==
-----END CERTIFICATE-----
"/etc/nginx/conf.d/server.key":
mode: "000400"
owner: root
group: root
content: |
-----BEGIN RSA PRIVATE KEY-----
MIJCXQIBAAKBgQCvnu08hroXwnbgsBOYOt+ipinBWNDZRtJHrH1Cbzu/j5KxyTWF
...
f92RjCvuqdc17CYbjo9pmanaLGNSKf0rLx77WXu+BNCZ
-----END RSA PRIVATE KEY-----
"/etc/nginx/conf.d/ca.crt":
mode: "000400"
owner: root
group: root
content: |
-----BEGIN CERTIFICATE-----
MIJCizCCAfQCCQChmTtNzd2fhDANBgkqhkiG9w0BAQUFADCBiTELMAkGA1UEBhMC
...
4nCavUiq9CxhCzLmT6o/74t4uCDHjB+2+sIxo2zbfQ==
-----END CERTIFICATE-----