「信頼証明書」やその他の属性がある場合、これはどの程度重要ですか?
OpenSSL は現在これを実装していますか? そうでない場合、なぜ OpenSSL は実装しないのですか?
答え1
SSL を使用するほとんどのプロトコル/アプリケーションでは、クライアントは (1) サーバーが有効な証明書を提示していること、つまり信頼できる CA によって発行され、期限切れ、取り消し、または改ざんされていないこと、および (2) その証明書が、誤ってまたは意図的な攻撃によって接続がルーティングされた他の誰かのものではなく、必要なサーバーのものであることを確認する必要があります。(サーバー認証ではなく機密性のみが必要なまれなケースがありますが、その場合は明示的に認証しない「anon」または「aNULL」暗号スイートを使用する方がよいでしょう。)
OpenSSLは今のところ（1）はできるが（2）はできない。、通常はトラストストア内の CA ルート証明書のみをサポートします。1 つの CA ルートが数千または数百万のサーバー証明書に対して「責任」を負っている可能性があり、たとえば Verisign が両方に証明書を発行したとしてもbigbank.com、localdiner.combigbank のアカウントを localdiner に渡したいわけではありません。したがって、アプリケーションは (2) を、verify_callback 内、またはハンドシェイクの完了後 (機密) データを送信する前に実行する必要があります。次のメジャー リリース 1.0.2 では、証明書チェーンの検証に対する機能強化が含まれる予定であり、少なくとも一部のケースでは名前の検証も含まれると考えています。RFC 2818 を使用する HTTPS または RFC 6125 を使用するその他の TLS ベースのプロトコルの場合、Subject の CommonName と、存在する場合は SubjectAlternativeNames 拡張の両方をチェックする必要があることに注意してください。
わからないOpenSSLを選ぶ理由(そしてその前は SSLeay)それをしないすでに。一部の珍しい SSL/TLS アプリケーションでは、標準の CN/SAN 以外のものが必要になると言う人もいるかもしれませんが、OpenSSL が一般的なケースを処理し、まれなケースに対してコールバックやオプションを提供する領域もあります。おそらく、作業量が多すぎて、人手が足りなかっただけだと思います (ごく最近まで)。