Let’s Encrypt の証明書を更新したら sendmail と courier-imap に接続できなくなった話。

三ヶ月に一回 Let’s Encrypt の証明書の更新があるわけだけど、今回はハマった・・。なのでちょっと書いておきます。

Let’s Encrypt の SSL 証明書更新後はちゃんと openssl コマンドを利用して確認するんだけど・・。

 
・https の確認

$ openssl s_client -connect running-dog.net:443 | openssl x509 -enddate | grep notAfter

 
・sendmail の確認

$ openssl s_client -connect mail.running-dog.net:587 -starttls smtp | openssl x509 -noout -dates

 
・imaps の確認

$ openssl s_client -connect mail.running-dog.net:993 | openssl x509 -noout -dates

 
まぁ、これらのコマンドを打って確認できるのは証明書の日付くらいか・・。サービスが実際に正常動作しているかは、やはり、ログを見ないと解らないか・・。

 
今回の Let’s Encryp の SSL 証明書更新後のハマりポイント。

 
1. Apple のメールアプリが imaps サーバに接続できなくなった
macOS や iOS などのメールアプリが根こそぎ imaps サーバに接続できなくなった。 macOS に Thunderbird をインストールしてそこから imaps サーバにアクセスすると特に問題なくアクセスできる・・。

macOS のメールアプリからアクセスすると、ログには以下のように残っていました。
あぁ・・。 moacOS 側のアプリのキャプチャ無くてすみません・・。

imapd-ssl[39496]: ip=[<略>], couriertls: connect: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher

 
なんか、おかしい・・。macOS 上の SSL 証明書を「キーチェーンアクセス」から削除してもダメ・・。

まぁ、ログを見ると cipher が足りない風な感じはしているのよねぇ・・。

と、いうことで Apple 製品の SSL 系 cipher についての記載を調べてみると以下の URL が見つかりました。

https://support.apple.com/ja-jp/guide/security/sec100a75d12/web

上記を読むと『 ECDHE_ECDSA_AES および ECDHE_RSA_AES』が必要なようです。僕は imap サーバに courier-imap を利用している(この記事の執筆時点にインストールされているバージョンは courier-imap-5.2.2 です)のだけど、この二つの cipher を /usr/local/etc/courier-imap/imapd-ssl の設定に追加しました。

こんな感じになりました。

TLS_CIPHER_LIST="ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES128-SHA:DES-CBC3-SHA:ECDHE_ECDSA_AES:ECDHE_RSA_AES"

 
随分と長くなりました。で Apple 製品のメールクライアントからアクセスすると無事に接続できるようになったのでありました。ふぅ・・。

 
2. sendmail が他のメールサーバから Relay を受け付けなくなった
imapd に接続できないのはまぁ、良いんだけど、こっちはダメージでかいですね。届くはずのメールが届かないのでおかしいなぁ・・。と、思っていたら sakura インターネットからのメールがエラーになっていて・・。

ログを確認すると、こんな感じ。

sm-mta[76876]: STARTTLS=server, error: accept failed=-1, reason=no shared cipher, SSL_error=1, errno=0, retry=-1, relay=<略>.sakura.ne.jp [<略>]

 
なんか、こちらも cipher が足りない感じ。orz

しょうがないので /etc/mail/sendmail.cf の O CipherList をちょっと変更。

#O CipherList=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:
O CipherList=ALL
#O CipherList=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:

 
当初設定したていたのはコメントアウトしてある一番上の行。どの cipher が足りないのか解らないので真ん中の O CipherList=ALL 行を有効にして全ての cipher で対応できるようにして、ログを確認。そーすると、ちらほらメールを受信し始めました。ふぅ。
で、更にログを眺めいてたら以下のログを発見。

sm-mta[33084]: STARTTLS=server, relay=<略>.sakura.ne.jp [<略>], version=TLSv1.2, verify=NO, cipher=ECDHE-ECDSA-AES256-GCM-SHA384, bits=256/256

 
なるほど。新たに ECDHE-ECDSA-AES256-GCM-SHA384 を追加する必要があるのね。と、いうことで O CipherList の設定は一番下の行にして、sendmail を再起動したら無事に復活したのでありました。

 
ふぅ。それにしても Let’s Encrypt の SSL 証明書を更新しただけで、メールの送受信ができなくなるとは恐ろしいことだぁ・・。

https は全然問題なかったのだが・・。

それにしも証明書の更新後の確認は日付だけでなく、ログの確認であるとか、実際にポートに接続して確認する必要があるかなぁ・・。今後の課題ですな。

 
と、いいつつ Let’s Encrypt だけでなく google や Apple は SSL 証明書の期限をさんが月にしよう。キャンペーンをしているけど・・。大変になる頻度が増えるかな。