私はnginxを複数のドメイン（たとえば100）のSSL終了TCPエンドポイントとして使用しています。
着信接続を別々に処理する必要はありませんが（すべて同じバックエンドでプロキシ設定されます）、各（サポートされている）ドメインに対してnginxはクライアントに有効な証明書を提供する必要があります（ここで有効であることは、クライアントのドメインが発行され署名されている場合）。を意味する）。ドメインがサポートされている100のドメインに属している場合は接続）。
私が試した最初のことは、-sectionを使用してx509 "代替トピック名"拡張を介してサポートされているすべてのドメインに公開するセクションをserver{}指定することでした。ssl_certificateしたがって、SNIは関係ありません。
しかし、これには次の欠点があります。 a) 代替テーマの数が制限されている。 b) サポートされているすべてのドメインのリストが漏洩する。
だから私はSNIを使用する必要があると思い、すべての証明書（ドメインごとに1つ）をファイルに接続してssl_certificate（明らかにその秘密鍵と同じ）とnginxを介して参照できると思いました。一部のSNIマジックでは、クライアントはサーバー名で送信されたコンテンツに提供されている正しい証明書を選択します。ただし、ファイルの最初の項目は選択されません。
指定ssl_certificate/ssl_certificate_keyサポートしているようですアルゴリズム/タイプ証明書（RSA、ECなど）
現在表示されている最後のオプションには、サポートされているserver{}各ドメインとそのドメイン固有ssl_certificate/ssl_certificate_keyオプションのセクションがあります。
100個のサポートされているドメインの場合、これは100個のserver{}部品を意味し、各部品はssl_certificate。
TCP-SSL接続を「ただ」終了し、同じネクストホップに転送するより良い方法はありますか？ここで唯一の違いは、TLS証明書に関連付けられた秘密鍵だけです。
編集する：ssl_certificateどういうわけか/に割り当てられた値に変数を使用できることを見逃しましたssl_certificate_key。たとえば、次のようになります。
ssl_certificate $ssl_server_name.crt;
ssl_certificate_key $ssl_server_name.key;
しかし、ここにはいくつかの欠点もあります。 a) 接続しようとするたびにファイルシステム検索が行われ、成功すると証明書がロードされます。 b）（たとえば、www-data）で実行されている（UNIX-）ユーザーnginxは証明書へのアクセス権を必要とし、キーファイルの読み取り権限は読み込まれ、要求時に読み込まれますが、静的に定義されているとnginxは権限を削除します。前にそれをロードします。