TLS を http で用いる場合(HTTP Over TLS)には、RFC [ietf.org] によると、subjectAltName か Common Name を検証しなくてはなりません。
If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.
Common Name の検証は、多くの TLSライブラリ(OpenSSL も含む)ではできません。従って、プログラマーが自前で Common Name を検証するためのコードを用意する必要がある ケースが多いと思います。Android SDK の場合は Warnings About Using SSLSocket Directly [android.com] を参考にして下さい。
https を使うなら 「サーバの証明書の検証」だけでは不十分 (スコア:2)
多くの解説サイトや書籍が、TLS (や既に過去の遺物である SSL) と HTTP Over TLS [ietf.org] (所謂 https) というレイヤーの全く違う規格を混同した記事を書いているせいか、誤解している人が多いようですが、 TLS として正しく「サーバ証明書の検証」 [wikipedia.org] したとしても HTTP Over TLS における成り済まし攻撃は防げません。
もっと具体的にいうと、OpenSSL を使っているならSSL_CTX_set_verify [openssl.org] で、TLS としての「サーバ証明書の検証」ができますし、これで TLS としての「サーバ証明書」の検証が終わったことになりますが、それだけでは不十分なのです。何故ならば、通信を改ざんした悪意のある第三者が、別の証明書(悪意のある第三者がCAから正規に購入した別の証明書、つまりクラッカーが秘密鍵を持っている正規CA発行の証明書)にすり替えたとしても検証(RFC上正しいTLSとしての検証でも)に通ってしまうからです。
TLS を http で用いる場合(HTTP Over TLS)には、RFC [ietf.org] によると、subjectAltName か Common Name を検証しなくてはなりません。
これは結構鬼門でして、コモンネームの位置づけ The (soon to be) not-so Common Name [globalsign.com] を読んでいただくと分かりやすいですが、ブラウザ等の実装を考えますと今のところは subjectAltName ではなく Common Name を使わざるを得ない現状です。
Common Name の検証は、多くの TLSライブラリ(OpenSSL も含む)ではできません。従って、プログラマーが自前で Common Name を検証するためのコードを用意する必要がある ケースが多いと思います。Android SDK の場合は Warnings About Using SSLSocket Directly [android.com] を参考にして下さい。
Re:https を使うなら 「サーバの証明書の検証」だけでは不十分 (スコア:2, 参考になる)
要約:HTTPS等はTLSの証明書チェーンの検証に加えてCommonNameをチェックしないと通信が他所を向いたとき等に大穴があくので、みんなWarnings About Using SSLSocket Directly [android.com]を参考にチェックするコード書いてね。
Re: (スコア:0)
多分、自分所のサーバーで使ってる証明書の一部をアプリに持たせて検証させたほうが簡単で早いね。
どーせアプリ自体が改竄されたらそのクライアントは諦めるしか無いんだし。
Re:https を使うなら 「サーバの証明書の検証」だけでは不十分 (スコア:1)
GnuTLSでは
gnutls_server_name_set
wolfSSLでは
wolfSSL_check_domain_name
でドメイン名を指定すればCommon Nameのチェックができますよ