docomo 送受信失敗(SSL 接続エラー)

[HAYASHI Chifumi]

林と申します。

ながらく docomo メールの読み書きを mew で行ってきたのですが、
先週末 5月30日に気づいたのですが、いつのまにか 証明書関連エラーで送受
信ともできなくなってしまいました。
4月19日昼頃までは使えていて、その後 何も設定変更していませんでした。
ということで、docomo側の何らかの変更の影響を疑っているのですが、
何が変わったか変わっていないかの確認もまだできておらず、
mew 側での対処方法も ssl-verify-level を 0 にする 以外に見つけられずにいます。
どのように調べたら良いでしょうか?

mew-config-alist 抜粋は 下記の通りです。

| (setq mew-config-alist
| ...
| ("docomo"
| (proto "%")
| (user "～")
| (mail-domain "docomo.ne.jp")
| (name "HAYASHI Chifumi (林　千史)")
| (imap-server "imap.spmode.ne.jp")
| (imap-port 993)
| (imap-ssh-server nil)
| (imap-user "090～")
| (imap-ssl t)
| (imap-auth nil) ; nil=LOGIN,t=mew-imap-auth-list [t]; [CAPABILITY IMAP4REV1 LOGIN-REFERRALS AUTH=LOGIN] srasvh IMAP4rev1 2001.315
| (imap-delete 30) ; delete after 30 days from first access [t]
| (smtp-server "smtp.spmode.ne.jp")
| (smtp-ssh-server nil)
| (smtp-ssl t)
| (smtp-ssl-port 465)
| (smtp-user "090～")
| (smtp-msgid-domain "docomo.ne.jp")

*Mew debug* は添付の通りです。

関連バージョンは

| $ rpm -q centos-release emacs stunnel openssl
| centos-release-5-11.el5.centos
| emacs-21.4-24.el5
| stunnel-4.15-2.el5.2
| openssl-0.9.8e-34.el5_11
| openssl-0.9.8e-34.el5_11
| $

です。

メールサーバ・ポート について同様の設定で thunderbird では 読み書きできます。

mew-6.5 のままでしたが、mew-6.6 に上げても変わりませんでした。
--
林　千史 chi...@tree2.info

[HAYASHI Chifumi]

[Masamichi HOSODA]

林さん

細田といいます。

今までつかえていたものが急に使えなくなった、というところと、
*Mew debug* に

＞2015.06.01 16:07:54 LOG4[9946:47416793434432]: VERIFY ERROR: depth=2, error=unable to get local issuer certificate: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Ce

とありますので、
恐らくサーバ側の証明書を発行する認証局が変更になった、
のではないかと思います。（よくある話だと思います。）

また、同じく *Mew debug* に

＞2015.06.01 16:07:54 LOG7[9946:47416838189264]: Verify directory set to /home/chifumi/.certs

とありますので、このディレクトリ /home/chifumi/.certs 内に、
信用すべきルート証明書が一式入っているのだと思います。

このディレクトリ内には、
以前の相手先サーバのサーバ証明書に紐づくルート証明書は存在していて、
そのときはサーバ認証を通過（信用できると判断）できたんだけど、
現在のサーバ証明書に紐づくルート証明書はディレクトリ内に無くて、
サーバ認証を通過できなくなった（信用できると判断できなくなった）
ということだと思います。

Thunderbird は、どのルート証明書を信頼すべきか判断するために、
上記ディレクトリを見ず、別の場所を見ているというだけだと思います。
Thunderbird のルート証明書プールは Mozilla が良きに計らって更新しているので、
サーバ証明書を更新しても、エラーにはならないんではないかと思います。

上記ディレクトリは、
たぶん自分で更新しないと誰も更新してくれないのではないかと思います。

というわけで、
http://www.mew.org/ja/info/release/mew_9.html#SSL
あたりでも参照して上記ディレクトリの中身を更新すれば
もしかしたうまくいくかもしれません。

　細田 真道 <true...@trueroad.jp>

[HAYASHI Chifumi]

細田さん

林です。

いろいろヒントありがとうございます。

結論から言うと、証明書に変化があったらしいということで
docomo関連証明書をいったん削除して作り直したつもりが、
ルート証明書まで消してしまっていたのに気がつかなかった、
ということのようです。

エラーメッセージに出てくるのが DOCOMO でなく VeriSign というのが
気にはなっていたのですが、

| $ ps w|grep stunnel
| 3370 pts/9 Ss+ 0:00 /usr/sbin/stunnel /tmp/chifumi14888os2/mew14888CdT
| 13761 pts/7 S+ 0:00 grep stunnel
| $ cat /tmp/chifumi14888os2/mew14888CdT|sed -e '/verify/s/2/0/' | tee stunnel.conf-docomo465
| client=yes
| pid=
| verify=0
| foreground=yes
| debug=debug
| CApath=/home/chifumi/.certs
| [8941]
| accept=127.0.0.1:8941
| connect=smtp.spmode.ne.jp:465
| $ kill 3370
| $ stunnel stunnel.conf-docomo465 > ,stunnel.out 2>&1 &
| [1] 29342
| $ telnet localhost 8941 < /dev/null
| Trying 127.0.0.1...
| Connected to localhost.localdomain (127.0.0.1).
| Escape character is '^]'.
| 220 ESMTP Server Ready
| Connection closed by foreign host.
| $ grep -n VERIFY ,stunnel.out
| 37:2015.06.02 14:54:57 LOG5[27639:47080597137728]: VERIFY IGNORE: depth=2, /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
| 38:2015.06.02 14:54:57 LOG5[27639:47080597137728]: VERIFY IGNORE: depth=2, /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
| 39:2015.06.02 14:54:57 LOG5[27639:47080597137728]: VERIFY IGNORE: depth=1, /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International Server CA - G3
| 40:2015.06.02 14:54:57 LOG5[27639:47080597137728]: VERIFY IGNORE: depth=0, /C=JP/ST=Tokyo/L=Chiyoda-ku/O=NTT DOCOMO.INC/OU=Services Platform Department 02/CN=smtp.spmode.ne.jp

というのを見て、depth=2 の行がダブっていておかしいけれど、

| $ openssl s_client -connect smtp.spmode.ne.jp:465 -showcerts </dev/null |egrep 'depth| s:| i:'
| depth=3 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
| verify return:1
| depth=2 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
| verify return:1
| depth=1 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International Server CA - G3
| verify return:1
| depth=0 /C=JP/ST=Tokyo/L=Chiyoda-ku/O=NTT DOCOMO.INC/OU=Services Platform Department 02/CN=smtp.spmode.ne.jp
| verify return:1
| DONE
| 0 s:/C=JP/ST=Tokyo/L=Chiyoda-ku/O=NTT DOCOMO.INC/OU=Services Platform Department 02/CN=smtp.spmode.ne.jp
| i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International Server CA - G3
| 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International Server CA - G3
| i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
| 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
| i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
| $

とすると ちゃんと depth=3 depth=2 ... と出て、どうも
「OU=Class 3 Public Primary Certification Authority」な証明書が読めてなさそう、
ということで確認したら、.certs に確かに見当たりませんでした。
CentOS なので /etc/pki/tls/certs/ca-bundle.crt をさがすと、その中にはちゃんとありました。

今まで メールサーバの証明書(中間証明書も含む)は 添付 addcerts script で

| $ addcerts imap.spmode.ne.jp:993
| $ addcerts smtp.spmode.ne.jp:465

で作るが ルート証明書は ca-bundle 見て手作業でしたが、
けっこう面倒だし 今回のような時の復活もたいへんなので、
添付のような Makefile を作って

| $ (cd .certs; make)

で一括作成するようにしてしまいました。

上記の手順で .certs を作り直したら、
送受信ともに問題なく行えるようになりました。

どうも お騒がせしました。
--
林　千史 chi...@tree2.info