サポートされない証明書の目的：中間 CA が失敗する理由

サーバー証明書の目的は正しく見え、鍵も一致し、日付も問題なく、それでも接続は unsupported certificate purpose で失敗します。これを解決する手がかりは通常、エラーと同じ行にあります。チェーンの上位にある証明書を指す深さの値と subject です。実行されているのは二つの別のテストで、末端に関わるのはそのうち一つだけです。両者を比較すれば、サーバー証明書を交換しても何も変わらない理由が分かります。

検証者が実際に拒否した証明書はどれか

チェーンは同じオブジェクトを三回繰り返したものではありません。末端はサーバーの名前と鍵を持ち、中間証明書がそれをルートにつなぎ、それぞれに有効期間、制約、用途があります。エラーが深さを示すとき、その番号は検証者が構築したチェーン内の位置を指し、サーバーが想定外のチェーンを送ると期待した位置と一致しないことがあります。

疑っていた証明書ではなく、その深さにある証明書のフィールドを読みます。すべてのフィールドを出力する代わりに、発行を制約する二つの拡張を問い合わせてください。答えはほぼ必ずそのどちらかにあります。拡張の出力は共有しても安全ですが、秘密鍵は決して共有できません。

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

名指しされた証明書が中間証明書で、その拡張鍵用途が TLS サーバー認証と無関係な事柄に触れているなら、残りの失敗は機械的に導かれます。チェーンは OpenVPN が要求した目的には使えません。

末端の目的とチェーンのポリシーは二つのテスト

末端のテストは狭い問いを立てます。このエンドエンティティ証明書は、この名前に対するサーバー認証を許可しているか。チェーンのテストはより広く問います。パス上のすべての証明書がその目的を果たしてよいか。クライアント証明書しか発行できない認証局は、自らの署名検証を通過しても二つ目のテストで失敗します。認可するパスに、アプリケーションが必要とする目的が含まれないからです。二つのテストは同じ言葉で失敗し、修復方法はまったく異なります。

だからこそ、見えるフィールドがすべて正しい新しい末端証明書が即座に失敗することがあります。だからこそ修復は通常、VPN の設定ではなく発行局のプロファイルに属します。

EKU がないことは制限的な EKU ではない

RFC 5280 は拡張鍵用途の拡張を任意とし、存在する場合は制約的とします。したがって拡張のない CA 証明書はサーバー認証に「いいえ」と言ったことにはならず、無関係な目的だけを列挙した証明書は非常に具体的なことを言ったことになります。この二つの状態を同等に扱うと誤った診断を生み、さらに悪いことに誤った修復を生みます。この区別は、コンソールで同じに見える二つの認証局がチェーン内でまったく違う振る舞いをする理由も説明します。

ライブラリの挙動もここでは一様ではありません。OpenSSL の検証オプションに関する文書 は CA 証明書に対する目的チェックの独自の扱いを説明しており、その扱いは実装ポリシーであって、すべての TLS スタックが同一に従う規則ではありません。自分の検証器が何をするかを述べ、実際に動かしているバージョンで確認してください。

再発行の前にオフラインで失敗を再現する

オフライン検証はアプリケーションを問題から切り離します。同じ目的の下でチェーンが同じように失敗するなら、問題は証明書であり、サーバー設定では隠せません。チェーンがオフラインで通るのにサービスが拒否し続けるなら、アプリケーションは別の目的を要求しているか、試験したものとは別のチェーンを使っています。

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

-show_chain が重要なのは、ツールが構築したパスを出力するからです。それは多くの場合、指定したファイル順ではありません。その出力は、二つ目の中間証明書がトラストストアから引かれていること、サーバーが意図しないクロス署名版を送っていること、チュートリアルからコピーした目的フラグが提供中のロールとは別のロールのものだということを、最も速く見つける手段です。

検証呼び出しではなく発行ポリシーを直す

持続的な修復は、果たすべき目的を許可するポリシーの下で発行された中間証明書であり、制約が文書化されレビューされています。すべての認証局にすべての目的を追加することはポリシーではありません。拡張に意味を与えていた制約を取り除くことであり、たいていはそれを招いた事故より長く残ります。認証局がどのロールを証明できるかを記した短いメモをプロファイルに置けば、次の再発行が同じ議論を繰り返すのを防げます。

検証を無効にすることはもう一つの魅力的な近道であり、証明書の問題を信頼の問題に変えてしまいます。目的チェックはそのままにし、チェーンを直し、同じオフライン検証をもう一度実行して、パスが意図したロールを果たすようになったことを確認してからサービスに触れてください。