まずは「サーバー証明書の検証」を知る前に

APOP 認証というのはパスワードのみの暗号化です。この場合メールの内容を見る気がある人には見られてしまいます。
SSL/TLS というのは通信の全ての暗号化です。この場合メールの内容をそんなに簡単には見られません。

まずは「SSL/TLS で暗号化する」を選択した状態で、「ログ」タブで「Debug」にチェックを入れて、接続して見ましょう。
　

以下のような出力がされます。

Debug:SSL/TLS のバージョンは TLSv1.2 です。 Debug:暗号化方式は ECDHE-RSA-AES256-GCM-SHA384 です。 Debug:bit 数は 256 です。 Debug:SSL/TLS のタイムアウトは 7200 です。 Debug:+OK @nifty pop server at conssluserg-**.nifty.com starting. . . . . . 接続に成功しました

これはサーバー（メールサーバーのこと）とクライアント（使っているパソコンのこと）で通信をして暗号化についてネゴシエートした結果です。
これだけでも結構セキュリティは高まったといえるのですが、サーバーがなりすまされているとしたらどうなるでしょう。
通信内容は筒抜けになります。このような攻撃を中間者攻撃（man-in-the-middle 攻撃）といいます。

これをチェックするのが「サーバー証明書の検証」です。

最初は OpenSSL を使って ＰＯＰ３、ＩＭＡＰ４ over SSL/TLS プロトコルを調べて、そのままコーディングをするもんだと思っていました。

色々と調べてみると様々な攻撃に対処するためにプロトコルはどんどん複雑になっています。
更に互換性のため TLSv1.2 ばかりでなく他のバージョンもコーディングしなければなりません。

OpenSSL にはそれに対して SSL_connect() という強力な関数があり、暗号化についてのネゴシエートを全てやってくれます。

今後 TLS のバージョンアップがあったとしても、OpenSSL のバージョンアップで済みそうです。

証明書とは以下のような感じです。前節のホスト名である「pop.nifty.com」の証明書です。

発行者と発行先（所有者）及び有効期間が必ずあります。所有者の身分は発行者が保証するというものです。

上記の例では「Cybertrust」の日本支社っぽいですね。

では発行者の身分はだれが保証してくれるのでしょう。さらにその上の発行者が保証します。

「証明のパス」タブをクリックしてみましょう。

「Cybertrust Japan Public CA G3」の身分は「DigiCert Baltimore Root」さんが保証するとしています。

その上はどうなるのでしょう。際限がなくなりますね。絶対的に信頼できる発行者が必要になります。その発行者の証明書をルート証明書といいます。

実はサーバーは自分の身分を証明するために SSL/TLS 通信途中で証明書を送ってきます。まずはピア証明書（通信相手が所有者の証明書、上記の例）及び存在すればその上位の証明書を送ってきます。これらの証明書の並びを証明書チェーンといいます。

所でサーバーが検証用のルート証明書も送ってくるとしましょう。（実際送ってくる場合と送ってこない場合がありますが．．．）
これで検証するのでは意味がないですね。なりすましされたらルート証明書が偽装できてしまいます。

という事はクライアント（使っているパソコンのこと）に信頼できるルート証明書が無いと検証ができません。そんなものあるのでしょうか？

実は Windows には元からルート証明書が組み込まれています。「certmgr.msc」を起動してみましょう。

上図のようにツリーを開いて、その中の「Baltimore CyberTrust Root」を起動（ダブルクリック）し「証明のパス」タブを選択してみましょう。どこかで見た名前ですね。

これでなんとかホスト名である「pop.nifty.com」の身分が保証されそうです。

クライアント側でルート証明書にアクセスしなければならないという事は、ここは OpenSSL ではできません。

実はルート証明書の実態はレジストリにあります。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\ROOT 等
a! Reg Analyzer 等で見てください

OpenSSL は Unix で開発されたという経緯があります。Unix にレジストリという概念はありません。

アクセスするには CryptoAPI という Microsoft が用意した関数を呼ばなければいけません。

証明書に有効期限があるという事は言いましたが、有効期限前に失効することがあります。

証明書を発行してもらうには証明機関（上記の例だと CyberTrust社 とか、ＣＡという、キャビンアテンダントではない）に発行を頼まなければならないですが、基本的には有料になります。

所有者がこのお金を払えなくなったとか、所有者がＣＡとケンカ別れをして他のＣＡに頼むことにしたとか。

このような場合、証明機関がＣＲＬ(証明書失効リスト)に登録することになります。

証明書チェーンを検証しただけでは検証は完成しません。証明書チェーンのＣＲＬに当該証明書が無いことを検証しなければなりません。

それはどうやったらわかるのでしょうか。

実は証明書の中にＣＲＬの情報が載っています。

証明書の「詳細」タブを開いてフィールドの「ＣＲＬ配布ポイント」を選択してみましょう。ＣＲＬのＵＲＬが書いてあるではありませんか。

これをダウンロードできるのではないかと試しに上記ＵＲＬをブラウザーに指定すると見事にダウンロードできます。

ダブルクリックすると内容が出てきます。「失効リスト」タブをクリックすると以下のように出てきます。

ＣＲＬ の取り扱いですが、OpenSSL がファイルをダウンロードして決まったところに保存しなければならないのに対して、 CryptoAPI はＣＲＬ配布ポイントを求めるのに CryptGetObjectUrl()、ＣＲＬを得るのに CryptRetrieveObjectByUrl()、 ＣＲＬを検証するのに CertVerifyCRLRevocation() と API が充実しています。

特に CryptRetrieveObjectByUrl() は勝手にインターネットに接続して取得してくれます。

よって ＣＲＬ の検証は証明書を CryptoAPI で使える形に変換して、これらの関数を使うことにしました。

ＰＯＰ３、ＩＭＡＰ４ と SSL/TLS とはどういう関係になるのでしょうか？

こういった問題を出しておいて何ですが、答えは関係が無いんです。
ちょっと言い方に語弊がありますが．．．。

SSL/TLS は ＰＯＰ３、ＩＭＡＰ４ のユーザ認証をする前に暗号化のネゴシエートをします。
ユーザＩＤを送る前に暗号化のネゴシエーションが終わっていなければいけないので、よく考えれば当然といえば当然ですが．．．。
従って暗号化のネゴシエートの相手サーバーは ＰＯＰ３、ＩＭＡＰ４ のサーバーである必要はありません。
さらに言うとユーザＩＤとパスワードもいりません。

Doubtful Mail Checker を使う場合、ホスト名は ＨＴＴＰサーバー（Ｗｅｂサーバー）でもいいんです。
ユーザーＩＤとパスワードは嘘っぱちを入れておけばいいのです。
ただポート番号はちゃんと入れておかないといけません。

代表的なポート番号を以下に示します。
ＰＯＰ３ over SSL/TLS：995
ＩＭＡＰ４ over SSL/TLS：993
ＨＴＴＰ over SSL/TLS（ＨＴＴＰＳ）：443

まず今使っている@nifty のＰＯＰサーバー pop.nifty.com がどういう証明書を送ってくるのか、面白そうだから検証してやれ！。

あ！アバストなんだ。アバストの無料アンチウイルスを使わせてもらっているんだけど、アバストは証明機関もやっているんだ！。
手広くやっているものだなあ。

じゃあYahoo のＰＯＰサーバー pop.mail.yahoo.co.jp も見てみよう。びっくり！。このサーバーもアバストなんだ。

Gmail のＰＯＰサーバー pop.gmail.com も見てみよう。またまたびっくり！。このサーバーもアバストなんだ。

ちょっとおかしいぞう？。本当かなあ？。じゃあアバストのインストールされていない環境で試してみよう。

有名どころの証明書チェーンを、アバストをインストールしていないパソコンからチェックしました。

プロトコル	ホスト名	中間発行者	ルート証明書
ＰＯＰ３	pop.nifty.com	Cybertrust Japan Public CA G3	Baltimore CyberTrust Root
ＰＯＰ３	pop.mail.yahoo.co.jp	Cybertrust Japan Public CA G3	Baltimore CyberTrust Root
ＰＯＰ３	pop.gmail.com	GTS CA 1O1	GlobalSign
ＰＯＰ３	outlook.office365.com	DigiCert Cloud Services CA-1	DigiCert Global Root CA
ＰＯＰ３	pop.aol.com	DigiCert SHA2 High Assurance Server CA	DigiCert High Assurance EV Root CA
ＩＭＡＰ４	imap.mail.me.com	Apple IST CA 2 - G1/OU=Certification Authority	GeoTrust Global CA
ＨＴＴＰ	www.nifty.com	Cybertrust Japan Public CA G3	Baltimore CyberTrust Root

outlook.office365.com に接続したら「ピア証明書のホスト名を確認できません」というエラーが出てしまった。

ピア証明書に問題があるなら、それをデバッグモードで取得しよう。

あれ？発行先が「outlook.com」になっている。これはホスト名と違う。

ホスト名と照合するのはここ以外にもある。それを見てみよう。

何か「*」がいっぱいある。いったいこれは何なのかネットで調べてみよう。

ワイルドカード証明書っていうんだ！

「*.office365.com」に「outlook.office365.com」をマッチさせなきゃいけないんだ。

きっとホスト名（厳密にいえばドメイン名を除いたホスト名）の変更などに対応するためこういうものを用意しているんだな。

早速 Doubtful Mail Checker でもサポートしておこう！

「サーバー証明書の検証」は中間者攻撃（man-in-the-middle 攻撃）に対応するためですが、ハードウエアで考えると以前見たこの図のようになります。

イントラネット内ならサーバー管理者がＬＡＮの配線を変えてしまったり、ＤＮＳ（サーバー名とＩＰアドレスの対応表を管理するサーバー）をいじくって変えてしまうという事が考えられます。

インターネットの中では配線をいじくるという事はプロバイダーならできるのかもしれませんがよくわかりません。

さすがに作者はプロバイダーではありませんので。

ここでプロバイダーというのは、純粋にインターネット接続業者という事で考えています。
プロバイダー自体で持っているメールサーバーに関してはイントラネットと同様に容易です。
他社のメールサーバーまで中間者攻撃ができるのかよくわかりません。

またインターネットのＤＮＳを変えることができるのかはよくわかりません。

管理者が善意であることが必須です。

ではソフトウエアとしては方法はあるのでしょうか？