私は、証明書の検証が非常に厳しい顧客がいます。証明書の冗長中間体の検証
"openssl verify"の使用を提案しましたが、これは "s_client"ほど厳密ではないようです。 私は中間体A、B、C（Aはサイト、Cはルート、Bは中間体）の鎖を持っていますが、全く連結されていない中間体証明書に侵入します。これをXと呼びましょう。証明書にA、B、X、Cが含まれています。
s_clientは検証では失敗します。 私はまた、いくつかのオンラインサービスをチェックしました - ほとんどは失敗しません。たとえばdigicertは失敗し、チェーンが壊れていると表示されます。
私はopenssl検証フラグを探してみましたが、s_serverを実行してからs_clientで有効性を確認しようとしました。
これについても検証を実行する方法はありますか？
opensslの代わりにgnutlsパッケージの 'certtool'を使用してください。
グッドチェーン：
$ cat A B C | certtool -e
Certificate[0]: <subject for A>
Issued by: <subject for B>
Verifying against certificate[1].
Verification output: Verified.
Certificate[1]: <subject for B>
Issued by: <subject for C>
Verifying against certificate[2].
Verification output: Verified.
Certificate[2]: <subject for C>
Issued by: <subject for C>
Verification output: Verified.
Chain verification output: Verified.
悪いチェーン：
$ cat A B X C | certtool -e
Certificate[0]: <subject for A>
Issued by: <subject for B>
Verifying against certificate[1].
Verification output: Verified.
Certificate[1]: <subject for B>
Issued by: <subject for C>
Verifying against certificate[2].
Error: Issuer's name: <subject for X>
certtool: issuer name does not match the next certificate
私はここに脅威モデルを理解していません。各証明書は発行エンティティを含み、その証明書が証明書チェーンにあるエンティティにデジタル署名されます。証明書は、発行エンティティ*および*署名を妨害せずに、介在することができず、利用できない発行エンティティの秘密鍵で介在証明書に署名する。 – EJP
"、証明書にA、B、X、Cが含まれています。 - 実は違う。証明書には発行者1名と科目1名のみが含まれます。 PEMはエンコードされ、同じファイルに連結され、 'SSL_CTX_load_verify_locations'または' SSL_load_verify_locations'に送られますか？ – jww