返事が遅くなってすみません。（さすがに会社から投稿というわけにも行かないので）

一般論的な部分は、
こちら [verisign.co.jp]をご覧下さい。

しかし、残念ながら、”「本物の」サーバ証明書を持つフィッシングサイト”などと言う物
に対抗する事は、通常のSSLの機能だけでは無理です。

もちろん、サーバ証明書の発行元を目視で確認後、その発行元の情報を調査し、かつ、既
にその発行方法に問題がある事が公表されている、と言った条件が揃えば、どうもあやし
い、ぐらいの見当は付くかもしれませんが、いちいちそんなことを調べるほど慎重な人な
ど見た事がありませんから、上記ケースでは、事実上SSLの認証機能は無力化されていると
見て良いと思います。

また、上記の件とは別件で、アプリケーション署名用の証明書ですが、2001年にVerisign
が誤って｢Microsoft Corporation｣の署名が入った証明書を個人に発行してしまった事例が
あります。
VeriSign 発行の誤ったデジタル証明書による、なりすましの危険性 (MS01-017) [microsoft.com]

この例などは、MicrosoftまたはVerisignからの公表やパッチの提供が無ければ、目視で
あっても厳密に技術的な意味であっても正規の証明書とまったく区別がつかないでしょう。

SSLのサーバ証明書で証明できるのは、そのサーバ証明書自体が、ブラウザに登録された
ルート証明書の発行元となっている認証局で認証されたか、または、ルート証明書発行
元の認証局に認証された中間認証局が認証した物であるという事です。
じゃあ、その認証局は何を見て認証しているんだ？と言う話になると、それは個別に調べ
るか問い合わせるしか無い、と言う話になってしまうので、”どのような条件で発行され
たか”は不明である、と言えます。

この暗号の仕組み自体が破られ、”技術的に偽造された証明書”が使用された、という例
は聞いた事がありませんので、上記の部分に関してだけは、今のところ確かだと思って良
いんじゃないでしょうか。

また、Flashで作られたログインフォームのSSLに関してですが、私はFlashに明るくないの
でちょろっと調べてみたところ、

1、Flashでログインフォームを実装した場合、サーバとの通信はActionScriptで行う。
2、ActionScriptは、SSLでの通信も素のHTTPでの通信でも、どちらでも指定できる。
3、ActionScriptがどちらのメソッドを利用して通信しているかは、Plugin内のみで決定さ
　 れ、ブラウザには表示されない。
4、ただし、ActionScriptでSSLを指定しているにも関わらず、サーバ証明書に不備があった
　 場合、警告メッセージの表示ではなく、単に動作しないかエラー終了となる。
5、ブラウザのSSL表示機能は、単にFlashファイル（*.swf）がSSLで転送されていれば鍵マー
　 クの表示がなされ、通常のHTTPでswfを転送すれば、鍵マークは表示されない。
　（か、開いたまま）
　 これは、実際にID/PASSがどちらのメソッドで転送されているかとはまったく関係が無い。

と言う事のようです。つまり、そのログインフォームの作者の意思次第であり、それをサイト
のユーザが知るにはパケットキャプチャなどで調査するしか無いようです。
私なら、Flashでログイン画面を実装したサイトの利用は単に見合わせます。
（私自身元々Flashアレルギー気味ですが）

と、言う感じなんですが、合格点はいただけますでしょうか？＞親コメントAC様