問題タブ [ocsp]

Nginx の Thawte 証明書に対して OCSP Stapling が機能しません。何が問題なのですか?

OCSP Stapling で動作するように Nginx を構成しました。

ssl_trusted_certificate.crt 証明書には、貼り付けられた root.crt と middle.crt が含まれています。

検証リクエストは、OCSP Stapling がまだオフであることを示しています。

結果：

誰がこの問題を知っていますか?

OCSP リクエストを作成し、それを CA サーバーに送信して証明書のステータスを確認する必要があるiOSアプリケーションを準備しています。

OpenSSLライブラリをx-code プロジェクトに統合しました。OpenSSL には、ocsp 要求および応答構造を定義する ocsp.hという名前のヘッダー ファイルが 1 つあります。

リクエストを作成してOCSPのレスポンスを解析するためのリソースや方法を見つけるのを手伝ってくれる人はいますか?

コマンド ライン インターフェイスの 1 行の呼び出しで、完全な OCSP 検証プロトコルを実行できるかどうかに興味がありopensslます。たとえば、チェーン内のすべての OCSP レスポンダー サーバーにクエリを実行して、証明書の現在の有効性を確認します。

これがそうであるかどうかを確認するために、ルックアップの代わりにキャッシュされた証明書が使用されるのを回避することを期待して、-CAfileオプションを として指定しました。/dev/null @pepo の回答で説明されているように、サーバー証明書チェーンには、RFC 5246 で指定された基本的な TLS1.2 ハンドシェイクの一部が送信されます (詳細は以下の更新を参照)。

出力が得られました：

opensslキャッシュされたファイルの助けを借りずに、チェーン内の 3 つのリンクすべてを見つけ たように見えます。そのため、エージェント (1) GeoTrust DV SSL CA - G3および (2) GeoTrust Global CAとインターネット経由で通信して、鎖。あれは正しいですか？ いいえ！それは正しくありません！

opensslまた、3 つの OCSP レスポンダーのそれぞれに適切な OCSP 要求を行うことにより、チェーンを検証しましたか ?

(私の推測では「いいえ」です。またopenssl ocsp ...、証明書の手動テキスト操作と組み合わせて、一度に 1 つのリンクで OSCP 検証を実行できることも認識してopensslいます。完全な OCSP 検証を実行してください。それが私が質問している理由です。)

2017 年 9 月 14 日更新:

@pepo の回答「SSL サーバー (正しく構成されている場合) は、証明書チェーン (ルート CA 証明書を除く) を送信します」のおかげで、RFC 5246 を調べたところ、 「サーバー証明書」の内容を説明するセクション「7.4.2 サーバー証明書」が見つかりました。 Certificate" TLS1.2 ハンドシェイクの部分:

これは証明書のシーケンス (チェーン) です。送信者の
証明書は、リストの最初に来る必要があります。次の各証明書は、その前の証明書を直接認証する必要があります。証明書の検証では、ルート キーを個別に配布する必要があるため、ルート認証局を指定する自己署名証明書は、いずれにしても検証するためにリモート エンドがすでに所有している必要があるという前提の下で、チェーンから省略される場合があります。

さらに、オプションに関する@pepoの回答のおかげで-crl_check_all、それを試してみたところ、次の出力が得られました。

エラーで失敗しましunable to get certificate CRLた。選択した Web サイトではOCSP ステープルが有効になっ ているため、これは重要ではありません。

CRL チェックを -crl_check_all実行する代わりに、 OCSP stapling を要求 するオプションを追加すると、次の出力が表示されます。-status

これは、サーバー側で OCSP ステープルが有効になっていることを示していますが、2 番目の証明書ではなく、最初の (リーフ) 証明書に対してのみ有効になっているように見えます。(いずれにせよ、自己署名の 3 番目の証明書は個別に検証する必要があります)。したがって、2 番目の証明書を検証するには、CRL チェックまたはOCSP 要求応答を使用する必要があります。この特定の承認チェーンではCRL チェックが有効になっていないため、OCSP-request-responseのみが残ります。

openssl@pepo の返信のおかげで、TLS1.2プロトコルと、認証を検証するためのこれらの方法 (歴史的な順序でリストされています) との関係をよりよく理解できます。

• CRL (証明書失効リスト) チェック
• OSCP 要求と応答
• OCSP ステープル

しかし、次のような新たな疑問も提起されています。

• 「サーバー証明書」メッセージステップ中にチェーン内の証明書とともにサーバーによって送信されたOCSP ステープル応答に関して- これには検証が必要な (次のレベルからの) 署名情報があります。この署名情報は の処理中に実際に検証されopenssl ... -statusますか?

更新: 2017 年 9 月 15 日

この回答 と以下の@dave_thompson_085のコメント（ソースコードを調べた） によると、 「この署名情報は実際に処理中に検証されますか？」という質問に対する安全な答えはopenssl ... -statusNOのようです 。

紛らわしいですか？はい！奇妙なことに、「OpenSSL クックブック (feistyduck、Ivan Ristić)」は この質問について異常に不明確で あり、署名を検証する明示的な方法を示しておらず、署名が検証されているかどうかについても明示的に述べていません。対照的に、他の両方のタイプの失効チェックでは、次のようになります。

• CRL チェック
• および OCSP-request-response (「OCSP リクエストの送信」を検索)

「OpenSSLクックブック」は、 によってすでに生成された情報を使用して、余分な距離を移動し、手動で検証を完了するための明示的な方法 (レシピ) を示していopensslます。「OpenSSL Cookbok」に、ステープルされた OCSP 応答を完全に検証するためのレシピが含まれていない理由は、それが必要ないためであると推測するのは、非常に人為的な間違いです。

私見、OpenSSL（または同様のライブラリ）が次の優先順位でトップレベルのドキュメントを含めることは非常に責任があります

• (1) OpenSSL は TLS+認可に対するブラック ボックス ソリューションを提供しないという説明、
• (2) それが提供するソリューションの限られた部分についての説明 (例: 認証チェックなしの TLS ハンドシェイク)、
• (3) OpenSSL コンポーネントを組み立てて認証チェック ソリューションを完成させるためのレシピに関するドキュメント。

誤解は非常に簡単に広がります。ほんの数日前、Linux Ubuntu PC から通知メールを送信する簡単なプログラムを作成しようとしていました。標準の Python リリース (バージョン 2 と 3 の両方) には、SMTP と、TLS1.2 を「実装する」SSL ライブラリが含まれています。10 分でプログラムを作成し、デバッガーで実行することができました。Python SSL ライブラリから OpenSSL のhandshake()関数への呼び出しをhandshake()確認でき、認証チェックを含めずに SSL ライブラリと SMTP ライブラリがリリースされないという前提に基づいて、すべての認証チェックを処理する必要があると想定しました。奇妙なことに、SSL ライブラリの呼び出しコードにはhandshake()、受信した証明書名が呼び出されたサーバーの名前と一致することを確認するための事後チェックが含まれていました。"handshake()署名の検証などはすでにすべて処理されているのでしょうか?」と思いました。その疑いが、TLS セキュリティのタマネギの層を剥がす旅の始まりであり、それ以来、私は涙を止めることができませんでした。

車輪を再発明しようとはしたくありません。それでも、利用可能なホイールが見つからないようです。ここからどこへ行く？