Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページで
 

SSL 証明書

SSL プロキシとして機能する SRX シリーズ ファイアウォールは、クライアントの一方の端ともう一方の端のサーバー間の SSL 接続を管理します。SSL プロキシ サーバーは、暗号化技術を使用してデータを安全に送信します。SSLは、安全な通信を提供するために、証明書とプライベートパブリックキー交換ペアに依存しています。このトピックでは、SSL 接続のためにセキュリティー・デバイスに SSL 証明書を生成してインストールする方法について説明します。

SSL 証明書の構成と読み込み

図 1 は、SSL プロキシーの構成の概要を示しています。SSL プロキシーの構成には、以下のものが含まれます。

  • ルート CA 証明書の設定

  • CA プロファイル グループの読み込み

  • SSLプロキシプロファイルを設定し、ルートCA証明書とCAプロファイルグループを関連付ける

  • セキュリティー・ポリシーへの SSL プロキシー・プロファイルの適用

図 1:SSL プロキシー構成の概要 SSL Proxy Configuration Overview

次のセクションで、これらの手順について詳細に説明します。

ルート CA 証明書の設定

CA は、ツリー構造の形式で複数の証明書を発行できます。ルート証明書はツリーの一番上の証明書で、その秘密鍵は他の証明書に sign 使用されます。ルート証明書のすぐ下のすべての証明書は、ルート証明書の署名または信頼性を継承します。これはアイデンティティ notarizing のようなものです。

ルート CA 証明書を設定するには、

  1. ルート CA 証明書の取得(いずれか一方をインポートする方法)

    • SRX シリーズ ファイアウォールで Junos OS CLI を使用して、ルート CA 証明書を生成できます。

    • 外部 CA から証明書を取得する(このトピックではカバーされていません)

  2. SSL プロキシー・プロファイルへのルート CA の適用

CLI を使用してルート CA 証明書を生成する

CLIで自己署名証明書を定義するには、以下の詳細を提供する必要があります。

  • 証明書識別子(前のステップで生成)

  • 証明書の完全修飾ドメイン名(FQDN)

  • 証明書を所有するエンティティの電子メール アドレス

  • 共通名と関係する組織

Junos OS CLI を使用してルート CA 証明書を生成します。

  1. 運用モードから、ローカルデジタル証明書の PKI 公開/秘密鍵ペアを生成します。

    例：

  2. 自己署名証明書を定義します。

    例：

    オプションを add-ca-constraint 設定することで、証明書が他の証明書の署名に使用できることを確認します。

  3. 設定モードから、SSL プロキシ プロファイルで読み込まれた証明書を root-ca として適用します。

    例：

  4. 信頼できる CA としてルート CA をクライアント ブラウザにインポートします。これは、クライアントブラウザーがSRXシリーズファイアウォールによって署名された証明書を信頼するために必要です。 ルート CA 証明書のブラウザーへのインポートを参照してください。

信頼できる CA プロファイル グループの設定

CA プロファイルは、認証の証明書情報を定義します。これには、新しい証明書を生成する際にSSLプロキシが使用する公開キーが含まれています。Junos OSでは、CAプロファイルのグループを作成し、1つのアクションで複数の証明書を読み込み、グループ内のすべての証明書に関する情報を表示し、不要なCAグループを削除することができます。接続が開始されると、接続デバイス(Web ブラウザなど)は、信頼できる CA から証明書が発行されているかどうかチェックします。これらの証明書がなければ、ブラウザはほとんどのWebサイトのIDを検証して信頼できないサイトとしてマークすることはできません。

信頼できる CA プロファイル グループの構成には、以下の手順が含まれます。

  • 信頼できる CA 証明書のリストの取得。信頼できる CA 証明書は、次のいずれかの方法で取得できます。

    • Junos OS は、信頼できる CA 証明書のデフォルト リストを PEM ファイルとして提供します(例: trusted_CA.pem)。Junos OS パッケージをダウンロードすると、デフォルト証明書がシステムで使用できるようになります。

      動作モードから、デフォルトの信頼できる CA 証明書を読み込みます(グループ名は CA プロファイル グループを識別します)。

      例：

      この方法を使用することをお勧めします。

    • 信頼できる CA 証明書の独自のリストを定義し、システムにインポートします。信頼できるCAのリストが単一のPEMファイル( IE-all.pemなど)に含まれており、PEMファイルを特定の場所( /var/tmpなど)に保存します。 ナレッジ ベース記事 KB23144 を参照してください。

      動作モードから、信頼できるリストをデバイスに読み込みます(グループ名はCAプロファイルグループを識別します)。

      例：

    • Mozilla(https://curl.haxx.se/docs/caextract.html)などの別のサードパーティーから最新のCAバンドルリストをダウンロードします。信頼できる認証局のリストは、時間の経過とともに変化する可能性があり、最新の CA バンドルを使用していることを確認してください。

    • 公開鍵基盤(PKI)を使用して、信頼できる独自の CA 証明書をインポートします。PKI は、信頼できる CA 証明書の有効性の確認と認証に役立ちます。信頼できる CA 証明書を含む CA プロファイル グループを作成し、デバイスにグループをインポートしてサーバー認証を行います。

  • CA グループを SSL プロキシー・プロファイルにアタッチします。

    • すべての CA プロファイル グループをアタッチします。

      例：

    • 1 つの CA プロファイル グループをアタッチします(グループ名は CA プロファイル グループを識別します)。

      例：

CA プロファイル グループ内のすべての証明書に関する情報を簡単に表示できます。

CA プロファイル グループを削除できます。CA プロファイル グループを削除すると、そのグループに属するすべての証明書が削除されます。

今後の予定

次にSSLプロキシプロファイルの設定に進み、SSLプロキシプロファイルをセキュリティポリシーに適用します。 SSL プロキシーの構成を参照してください。

ルート CA 証明書をブラウザーにインポートする

SSL プロキシ プロファイルで構成された root CA によって署名されたすべての証明書をブラウザーまたはシステムが自動的に信頼できるようにするには、プラットフォームまたはブラウザーに CA ルート証明書を信頼するよう指示する必要があります。

ルート CA 証明書をインポートするには、以下の手順に示します。

  1. 設定したルート CA の PEM フォーマット ファイルを生成します。
  2. ルート CA 証明書をブラウザーにインポートします。

    Internet Explorer(バージョン 8.0)から:

    1. [ツール] メニューから [ インターネット オプション] を選択します。
    2. [コンテンツ] タブで [ 証明書] をクリックします。
    3. [ 信頼されたルート証明機関 ] タブを選択し、 [ インポート] をクリックします。
    4. 証明書のインポート ウィザードで、必要なルート CA 証明書に移動して選択します。

    Firefox(バージョン 39.0)から:

    1. [ツール] メニューから [ オプション] を選択します。
    2. [詳細] メニューから [ 証明書 ] タブを選択し、 [ 証明書の表示] をクリックします。
    3. 「証明書マネージャー」ウィンドウで、「 権限 」タブを選択して「 インポート」をクリックします。
    4. 必要なルート CA 証明書に移動し、それを選択します。

    Google Chrome(45.0)から:

    1. [設定]メニューから、[ 詳細設定を表示]を選択します。
    2. [詳細] メニューから [ 証明書 ] タブを選択し、 [ 証明書の表示] をクリックします。
    3. [HTTPS/SSL] の下にある [ 証明書の管理] をクリックします。
    4. [証明書] ウィンドウで [ 信頼されたルート証明機関 ] を選択し、[ インポート] をクリックします。
    5. 証明書のインポート ウィザードで、必要なルート CA 証明書に移動して選択します。

証明書チェーンの実装

Junos OS リリース 15.1X49-D30 以降、SSL フォワード プロキシーは証明書チェーンの実装をサポートしています。証明書チェーンの概念を理解し、SRX シリーズ ファイアウォールで構成する方法について説明します。

  • Certificate Authority (CA)— CA は、エンティティの ID(Web サイト、電子メール アドレス、企業、個人など)を検証し、暗号化キーをバインドしてデジタル証明書を発行する責任を負う信頼される第三者です。組織が CA サーバーを所有している場合は、自分の CA となり、自己署名証明書を使用します。

  • Root Certificate—ルート証明書は、信頼できる認証局(CA)によって発行された証明書です。ルート証明書はツリーの一番上の証明書で、その秘密鍵は他の証明書の署名に使用されます。ルート証明書のすぐ下のすべての証明書は、ルート証明書の署名または信頼性を継承します。これらの証明書は、2つのエンドポイント間の接続を確立するために使用されます。

  • Intermediate CA Certificate中間 CA 証明書は、特にエンドエンティティ証明書を検証するために信頼されたルートによって署名された下位証明書です。

  • Certificate Chain - 証明書チェーンは、SSL証明書、中間証明書、およびルート証明書を含む証明書の順序指定済みリストです。一部の CA(認証機関)は、ルート証明書で署名するのではなく、中間証明書を使用します。中間 CA は、ルート CA 証明書に代わって証明書に署名できます。ルート CA は中間証明書に署名し、信頼チェーンを形成します。

    中間証明書は、接続するデバイス(ブラウザ、アプリケーション、モバイル デバイスなど)が信頼できるように、SSL 証明書と同じサーバーにインストールする必要があります。

接続を開始すると、接続デバイス(Web ブラウザーなど)は、証明書が本物かどうか、およびブラウザーの信頼できるストアに埋め込まれている信頼できる認証機関によって発行されているかどうかを確認します。

SSL 証明書が信頼できる CA から取得されていない場合、接続デバイスは、SSL 証明書が中間 CA によって発行され、この中間 CA がルート CA によって署名されているかをチェックし続けます。ルート CA が見つかるまで、チェックは続行されます。ルート CA が検出されると、セキュアな接続が確立されます。ルート CA が見つからなければ、接続は切断され、無効な証明書または信頼されていない証明書に関するエラー メッセージが Web ブラウザに表示されます。

この例では、ブラウザが証明書を信頼できるように証明書チェーンをインストールする方法を示しています。

要件

この機能を設定する前に、デバイス初期化以外の特別な設定は必要ありません。

概要

この例では、ドメイン例.domain-1 があり、そのドメインのXYZ権限から証明書を購入します。ただし、XYZ -Authority は Root-CA ではなく、訪問する Web ブラウザーは Root-CA 証明書のみを信頼します。つまり、その証明書は Web ブラウザーに直接埋め込まれていないため、明示的に信頼されません。

この場合、証明書チェーン(中間証明書の)を使用して、次の方法で信頼が確立されます。

トポロジ

このチェーンを可視化して 図 2 に進みましょう。この画像は、ルートCA証明書からエンドユーザー証明書までの完全な証明書チェーンを示しています。チェーンはエンドユーザー証明書で終了します。

図 2:証明書所有者からルート CA Certification Path from the Certificate Owner to the Root CA への認定資格パス
表 1:証明書チェイニングの詳細

ユーザー

証明書を使用

署名者

型

例.domain-1

エンドユーザー証明書

XYZ 権限

エンド ユーザー証明書。CA から購入した 1 つ。

XYZ 権限

認定書-1

中間 CA-1

中間認定書

中間 CA-1

認定書-2

中間 CA-2

中間認定書

中間 CA-2

証明書-3

中間 CA-3

中間認定書

中間 CA-3

認定書-4

root-example-authority です。これはルート CA です。

ルート証明書

その証明書は、Webブラウザに直接埋め込まれます。そのため、明示的に信頼できます。

サーバーの例.domain-1用にエンドユーザー証明書をインストールする場合、すべての中間証明書をバンドルし、エンドユーザー証明書と一緒にインストールする必要があります。証明書チェーンには、証明書1からルートCA証明書までのすべての証明書が含まれています。Web ブラウザーはルート CA を信頼するため、すべての中間証明書も暗黙的に信頼します。SSL 証明書チェーンが無効または破損している場合、証明書は一部のデバイスから信頼されません。

メモ：

  • すべての証明書は、PEM(プライバシ拡張メール)形式である必要があります。

  • CA は、連結された証明書ファイルをデバイスにインポートする場合、署名されたサーバー証明書に追加する必要があるチェーン証明書のバンドルを提供します。サーバー証明書は、結合ファイルで連鎖された証明書の前に表示される必要があります。

構成

SSL 証明書チェーンの構成には、以下のタスクが含まれます。

  • 署名証明書と対応する鍵を含む SSL 証明書を CA から購入します。

  • 信頼できる CA プロファイル グループを設定します。

  • デバイス上の署名証明書とキーを読み込みます。

  • 公開鍵基盤(PKI)メモリの中間 CA とルート CA を読み込みます。この証明書ファイルには、必要なすべての CA 証明書が 1 つずつ PEM 形式で格納されます。

  • 中間 CA 証明書またはルート CA 証明書の信頼できる CA プロファイルを作成します。

  • SSL プロキシー・プロファイルを構成してセキュリティー・ポリシーに適用することにより、CA から受け取った署名証明書を使用するようにデバイスをセットアップします。SSLフォワードプロキシは、この証明書チェーン情報(CA証明書プロファイル名)をそれぞれのSSLプロファイルに格納します。セキュリティー ポリシー実装の一環として、証明書チェーン情報と CA 証明書を持つ SSL プロファイルが使用されます。

以下のコンポーネントは、証明書チェーンの処理に含まれます。

  • 管理者は、証明書チェーンとローカル証明書(署名証明書)を PKI デーモン証明書キャッシュに読み込みます。

  • ネットワークセキュリティデーモン(nsd)は、SSLプロキシプロファイルで設定された署名証明書の証明書チェーン情報を提供するために、PKIデーモンに要求を送信します。

この例では、CA から SSL 証明書をすでに購入済みであることを前提としています。

デバイス上の証明書チェーンの設定

手順

証明書チェーンを設定するには:

  • ローカル証明書を PKI メモリに読み込みます。

    以下のメッセージが表示されます。

    証明書 ID は、SSL プロキシー・プロファイルの root-ca セクションの下で使用されることに注意してください。

  • PKI メモリ内の中間 CA 証明書またはルート CA 証明書を読み込みます。

    CA プロファイルには、認証に使用される証明書情報が含まれています。これには、新しい証明書を生成する際にSSLプロキシが使用する公開キーが含まれています。

    この証明書は証明書チェーンとして添付されます。

  • CAプロファイルグループをSSLプロキシプロファイルにアタッチします。信頼できる CA を 1 つずつ接続することも、1 つのアクションですべてを読み込むことも可能です。

  • SSL プロキシ プロファイルで、署名証明書を root-ca として適用します。

  • セキュリティ ポリシーを作成し、ポリシーの一致条件を指定します。一致条件として、SSL プロキシを有効にするトラフィックを指定します。この例では、要件に基づいてセキュリティ ゾーンを既に作成していることを前提としています。

    SSLフォワードプロキシは、この証明書チェーン情報(CA証明書プロファイル名)を、それぞれのSSLプロファイルに格納します。セキュリティー ポリシー実装の一環として、証明書チェーン情報と CA 証明書を持つ SSL プロファイルが使用されます。

    接続しているWebブラウザ(つまりクライアント)で証明書チェーンを表示できます。

「」も参照

サーバー認証の失敗を無視する

サーバー認証

クライアントとデバイスの間の暗黙的な信頼(クライアントがデバイスによって生成された証明書を受け入れるので)は、SSLプロキシの重要な側面です。サーバー認証が侵害されていないことは非常に重要です。実際には、自己署名証明書と異常のある証明書が豊富に存在します。異常には、期限切れ証明書、ドメイン名と一致しない共通名のインスタンスなどが含まれます。

サーバー認証は、SSL プロキシー・プロファイルで オプションを ignore-server-auth-failure 設定することで制御されます。このオプションを設定した結果は 、表 2 に示されています。

表 2:サーバ認証失敗オプションを無視する

SSL プロキシー・プロファイル・アクション

結果

ignore-server-auth-failureオプションが設定されていません(デフォルト オプション)

  • 認証に成功した場合は、キーを置き換え、発行者名をプロキシ プロファイルのルート CA 証明書で構成された発行者名に変更することで、新しい証明書が生成されます。

  • 認証に失敗した場合、接続は切断されます。

オプションが ignore-server-auth-failure 設定されている

  • 証明書が自己署名の場合、鍵を置き換えることで新しい証明書が生成されます。発行者名は変更されません。これにより、クライアント ブラウザーに証明書が無効であるという警告が表示されます。

  • 証明書が期限切れになった場合、または共通名がドメイン名と一致しない場合、鍵を置き換え、発行者名を SSL-PROXY に変更することで、新しい証明書が生成されます。DUMMY_CERT:SRVR AUTH 障害が発生したために生成されます。

    これにより、クライアント ブラウザーに証明書が無効であるという警告が表示されます。

  • このオプションは認証にはお勧めしません。設定すると Web サイトがまったく認証されないからです。ただし、このオプションを使用して、SSL セッションのドロップの根本原因を効果的に特定することができます。 SSL プロキシーのデバッグとトレースの使用可能化を参照してください。

クライアント認証

現在、クライアント認証はSSLプロキシではサポートされていません。サーバーがクライアント認証を要求した場合、証明書が利用できないという警告が発行されます。この警告により、サーバーは続行するか終了するかを決定できます。

SSL プロキシーの証明書失効リスト

SSL プロキシーの証明書失効リストの使用

認証局(CA)は、取り消された証明書のリストを証明書失効リスト(CRL)を使用して定期的に公開します。セキュリティ デバイスは、最近発行された CRL をダウンロードしてキャッシュします。CRL には、有効期限の前にキャンセルされたシリアル番号を持つデジタル証明書の一覧が含まれています。

CAは、証明書が侵害される可能性がある場合、発行された証明書を取り消します。証明書を取り消すその他の理由は次のとおりです。

  • 未指定(特定の理由は付与されません)。

  • 証明書を発行した証明書または CA に関連付けられた秘密鍵が侵害されました。

  • 証明書の所有者は、証明書の発行者と関連付けされなくなります。

  • 元の証明書は別の証明書に置き換えられます。

  • 証明書を発行した CA の動作が停止しました。

  • 証明書は、さらなるアクションを保留して保留中です。取り消されたとして扱われるが、将来的に受け入れられる可能性があります。

参加するデバイスがデジタル証明書を使用すると、証明書の署名と有効性が確認されます。デフォルトでは、SSL プロキシー・プロファイルでは、CRL 検証が有効になっています。

Junos OS リリース 15.1X49-D30 および Junos OS リリース 17.3R1 以降、SRX シリーズ ファイアウォールは証明書失効リスト(CRL)をサポートしています。SRX シリーズ ファイアウォールでの CRL 検証では、取り消された証明書をサーバーからチェックします。

SRXシリーズファイアウォールでは、証明書の失効チェックがSSLプロキシプロファイルでデフォルトで有効になっています。特定のセキュリティ要件を満たすために、CRL 検証を有効または無効にすることができます。

  • CRL 検証を無効にします。
  • CRL 検証を再び有効にします。

ROOT 証明書または中間証明書で CRL パスのダウンロードに失敗した、または使用できないなどの理由で、CRL 情報が利用できない場合にセッションを許可または削除できます。

  • CRL 情報が利用できない場合は、セッションを許可します。

  • CRL 情報が利用できない場合は、セッションを削除します。

  • SRX シリーズ ファイアウォールが、失効ステータスで利用可能な信頼性の高い確認なしに証明書を受け入れるように設定し、証明書が取り消され、取り消し理由が保留されている場合にセッションを許可します。

「」も参照

SSL パフォーマンスの強化

SRX シリーズ ファイアウォールにおける SSL パフォーマンスの強化には、以下の機能があります。

SSL パフォーマンスの最適化

SSL/TLS ハンドシェイクは、CPU を大量に消費するプロセスです。SSL/TLS は Web 上で最も広く使用されているセキュリティー プロトコルであるため、パフォーマンスが Web パフォーマンスに大きな影響を及ぼします。

Junos OS リリース 15.1X49-D120 以降では、以下のオプションを使用してパフォーマンスを最適化できます。

  • 最適化された RSA 鍵交換の使用

  • 関連データ(AEAD)による認証暗号化の使用 - AES128-CBC-SHA、AES256-CBC-SHA

  • 証明書キャッシュの維持 —証明書キャッシュは、サーバー証明書の詳細とともに、サーバー証明書を保存します。SSL/TLS ハンドシェイク中に、SSL プロキシーは、新しい証明書を生成する代わりに、キャッシュされた証明書をクライアントに提示できます。

SSLパフォーマンスを向上することで、セキュリティを損なうことなくWebサイトのパフォーマンスを向上させ、ユーザーエクスペリエンスを最大化します。

オプションで、証明書キャッシュに対して以下の設定を行うことができます。ただし、デフォルト値は保持することをお勧めします。

例：

  • (オプション)証明書キャッシュのタイムアウト値(例- 300 秒)を設定します。

    この例では、証明書キャッシュは証明書の詳細を 300 秒間保存します。デフォルトのタイムアウト値は600秒です。

  • (オプション)証明書キャッシュを無効にします。

    証明書キャッシュを無効にすると、デバイスは新しい接続のSSLフルハンドシェイクを許可します。デフォルトでは、証明書キャッシュが有効になっています。

  • (オプション)既存の証明書キャッシュを無効にします。

    この例では、証明書失効リスト(CRL)が更新されると、デバイスは既存の証明書キャッシュを無効にします。デフォルトでは、CRL 更新時の無効な証明書キャッシュは無効になっています。

セッションの再開

SSL セッションの再開は、すでにネゴシエートされたセッション ID を使用して以前のセッションを再開するメカニズムを提供します。セッション再開により、クライアントとサーバーは、完全な SSL ハンドシェイクと新しいプライマリ キーの生成による計算オーバーヘッドを節約できます。

セッション再開により、ハンドシェイク プロセスが短縮され、SSL トランザクションが高速化されるため、パフォーマンスが向上すると同時に、適切なレベルのセキュリティが維持されます。

TLS 1.2は、セッション識別子とセッションチケットメカニズムによるセッション再開をサポートしています。SSL セッションの再開には、以下の手順が含まれます。

  • セッション・キャッシング・メカニズムは、プリマスター秘密鍵や、クライアントとサーバーの両方の合意された暗号方式などのセッション情報をキャッシュします。

  • セッションIDは、キャッシュされた情報を識別します。

  • それ以降の接続では、両当事者は、事前マスター秘密鍵を作成するのではなく、セッションIDを使用して情報を取得することに同意します。

Junos OSリリース22.1R1以降、TLS 1.3はSSLプロキシのPSK(事前共有キー)を使用してセッションの再開をサポートしています。PSKを使用したセッション再開により、以前に確立された共有秘密鍵を使用したセッションを再開して、SSLハンドシェイクのオーバーヘッドを削減できます。

PSKは、最初のTLSハンドシェイクから派生した固有の暗号化キーです。TLSハンドシェイクに成功すると、サーバーはPSK IDをクライアントに送信します。クライアントは、今後のハンドシェイクでそのPSK IDを使用して、関連するPSKの使用をネゴシエートしてセッションを再開します。

TLS1.3 による SSL セッションの再開には、以下の手順が含まれます。

  1. 最初のTLSハンドシェイクの後、サーバーはPSK ID(PSKの暗号化されたコピー)を含む新しいセッションチケットメッセージをクライアントに送信します。

  2. 次に、クライアントがセッションを再開しようとすると、同じセッションチケットをHelloメッセージ内のサーバーに送信します。
  3. サーバーはメッセージを復号化し、PSKを識別し、セッション情報をキャッシュから取得してセッションを再開します。

SSL-I(SSL 初期化)では、PSK と ECDHE 鍵交換モードを使用し、SSL-T(SSL 終端)では PSK と PSK を ECDHE 交換モードで使用します。

SSL プロキシー・セッションは、セッション再開のための接続の両端で TLS1.3 と TLS1.2 以前のバージョンの相互運用性をサポートします。

デフォルトでは、SSLプロキシではセッション再開が有効になっています。セッションの再開をクリアするか、要件に従って再び有効にすることができます。

  • セッションの再開をクリアするには、次の手順にしたがっています。
  • セッションの再開を再度有効にするには:

以下のコマンドを使用して、セッションタイムアウト値を設定します。

タイムアウト値は、300 秒から 86400 秒まで設定できます。デフォルト値は86400秒(24時間)です。

セッション再ネゴシエイション

SRXシリーズファイアウォールは、セッション再ネゴシエーションをサポートします。セッションが作成され、SSLトンネルトランスポートが確立された後、SSLパラメーターの変更には再ネゴシエイションが必要になります。SSLプロキシは、セキュア(RFC 5746)と非セキュア(TLS v1.0、TLS v1.1、TLS v1.2)の両方を再ネゴシエイションに対応しています。セッションの再開が有効になっている場合、次の状況ではセッション再ネゴシエイションが有効になります。

  • 暗号キーは、長引く SSL セッションの後に更新する必要があります。

  • よりセキュアな接続には、より強力な暗号方式を適用する必要があります。

証明書、暗号強度、信頼済み CA リストを変更して SSL プロキシー・プロファイルを変更した場合、変更されたポリシーをコミットすると、システムがキャッシュ・エントリーをフラッシュします。この場合、新しい SSL パラメーターを確立するには、完全なハンドシェイクが必要です。(非 SSL セッションには影響しません。

SSL プロキシー・プロファイルが変更されていない場合、そのプロファイルに対応するキャッシュ・エントリーはフラッシュされず、セッションは続行されます。

SMTP セッションの StartTLS のネゴシエート

StartTLS では、最初のプレーン TCP 接続からよりセキュアな TLS 接続への SMTP セッションを有効にします。StartTLS では、ピア間のネゴシエーションに成功した後、TLS レイヤーを介してサーバーとクライアント間の SMTP セッションを許可します。StartTLS は、既存の安全でないプレーン SMTP 接続をセキュアな SSL/TLS 接続にアップグレードします。

クライアントからStartTLSを受信しなかった場合にセッションを無視するまでの待ち時間を決定できるしきい値を設定できます。

以下のオプションを設定できます。

  • バイトしきい値 — クライアントから StartTLS を受信できない場合、セッションを無視する前に許可される暗号化されていないセッションの最小バイト。100~300 の範囲。
  • パケットしきい値 — StartTLS がクライアントから受信されない場合、セッションを無視する前にクライアントからサーバーへの方向で許可される暗号化されていないパケットの数。1~15 の範囲。

例：

この単純な例では、SSL プロキシによって 100 バイトのプレーン(暗号化されていない)SMTP トラフィックが許可されます。100 バイトに達すると、クライアントから StartTLS を受信しなかった場合、セッションは無視されます。

この例では、SSLプロキシにより、プレーン(暗号化されていない)SMTPトラフィックの2パケットが許可されています。2 パケットに達した後、StartTLS がクライアントから受信されなかった場合、セッションは無視されます。

ドメイン名の動的解決

ドメイン名に関連付けられた IP アドレスは動的であり、いつでも変更できます。ドメインIPアドレスが変更されるたびに、SSLプロキシ設定に反映されます(ファイアウォールポリシー設定で行われるのと同様)。

関連ドキュメント

リリース履歴テーブル
リリース
説明
15.1X49-D30
Junos OS リリース 15.1X49-D30 および Junos OS リリース 17.3R1 以降、SRX シリーズ ファイアウォールは証明書失効リスト(CRL)をサポートしています。