Compnet

仕事とか遊びとか、日々折々

2019-01-04(金)

ConoHa のメールサーバーを使おうとしたら SSL 証明書で難儀した話 (序説)

Posted by Nakane, R. in technical   

この年末年始に某社のメールサーバーを SaaS (?) のメールサーバーに移行することにしました。 今までのメールサーバーは VPS サービスの仮想マシンに Linux (いつもながらの Ubuntu) を入れて、そこに Postifx や Dovecot などを組みあわせて構築していました。 メールの送信に際しては SPF や DKIM に対応させ、受信時にも SPF・DKIM の検証、ウィルス チェックや spam 判定を行うようにしてあります。 しかし、SPF・DKIM はともかくとして、ウィルス チェックと spam 判定については対象が日々刻々と進化するために、これに遅れないような保守作業が負担であり不安でもありました。

そこで、ウィルス チェックや spam 判定までをまとめて見てくれるメール サービスを探して、ConoHa のメールサーバーに行き着きました。 ConoHa のメールサーバーは一種のアプライアンスみたいなもので、今まで自分自身で全て構築していたのメールサーバーの機能を全てひとまとめにしたかたちで提供いただける仕組みです。 何より、ウィルス チャックや spam 判定の保守作業の一切が ConoHa 側でやっていただける点が重要でした。

ConoHa のメールサーバーの利用の開始と設定についてはここに書いてあるので省略します。 しかし設定をしていく中で、運用を始めるときにはここに書いてある以下の箇所が問題になりそうだと気付きました。

※SSL有効時、メールソフトによっては共用SSLを用いている性質上、セキュリティ証明書に関するメッセージが表示される場合がございますが動作には問題ありません。 メールソフトによっては「セキュリティ例外の承認」などで設定することで、次回からのメッセージを表示しないようにすることが可能です。

ConoHa のメールサーバーを作成・設定を一通り行ってから、手元にあった Thunderbird と Outlook の二つのメーラーで接続を検証したところ、確かにどちらのメーラーでも証明書に関する警告が表示されます。 警告の内容は「他のサイトの証明書」や「対象のプリンシパル名が間違っています」といったものです。 SSL/TLS や STARTTLS による通信路の暗号化を行わなければ、証明書自体が不要なのでこういった警告は出なくなりますが、身だしなみとしても暗号化は今の世のマナーです。 メール サーバーの通信路を暗号化する事例が徐々に増えているようなので、メーラーとメール サーバーの間の暗号化はやはり欠かせません。

この証明書に関する警告はあくまでも「警告」なので、何について警告されているかさえ理解していればこれを無視して実行を継続しても問題ではありません。 Thunderbird の場合は「次回以降もこの例外を有効にする」にチェックを入れて「セキュリティ例外を承認」をクリックすればこれ以後は警告が表示されなくなります。 Outlook では「証明書の表示...」で表示した証明書のウィンドウで「証明書のインストール...」をクリックして、証明書をインストールしてから、このサーバーの使用を続ければいいはずです。 外のメーラーでもだいたい同じような操作で警告を表示しなくできると思います。

しかし残念なことに、Outlook ではこの警告をまったく表示させないようにはできません。 通常であれば証明書をインストールすれば次回以降は警告が表示されなくなりますが、ConoHa のメールサーバーは違います。 警告のポップアップで「このサーバーの使用を続けるますか?」に「はい」をクリックすれば、とりあえず Outlook を終わらせるまでの警告の表示は抑止できます。 ところが、証明書を何度インストールしようとも、ひとたび Outlook を再起動すると再び必ず警告が表示されます。

この原因ははっきりしていて、Outlook の証明書の情報を表示してよく見るとそれが分かります。 ConoHa のメールサーバーで使われている証明書は発行先が「*.tyo1.conoha.io」で、ConoHa のコントロール パネルに表示される接続先のサーバーの FQDN とは明らかに異なります。

証明書の発行先と Outlook に設定したサーバーの FQDN が異なるだけであれば、先に書いたようにその証明書をインストールすれば警告が表示されなくなります。 今回のように証明書をインストールしても警告が表示され続けるのは、証明書の発行先にワイルド カード ‘*’ (アスタリスク) が含まれているためです。 最新の Outlook 2019 に至る全ての Outlook では、このようなワイルド カードを含む発行先の証明書が扱えません。 つまりは、サーバーから送られてきたワイルド カードを含む発行先の証明書を Outlook は検証できないということで、このために Outlook は常に警告を表示してしまうのです。

ConoHa のメールサーバーを皆に使ってもらうには、Outlook を起動する度に表示される警告をなんとかしなくてはなりません。 毎回毎回、警告を無視 (「はい」をクリック) してもらう運用では、たとえ僅かとはいえ使う人の苛立ちを増すことに繋がります。

そこで考えたのは、メーラーと ConoHa のメールサーバーの間にプロキシ サーバーを置いて、そこで証明書をなんとかする方法です。 メーラーからの送受信はプロキシ サーバーに対して行い、プロキシ サーバーはそれを ConoHa のメールサーバーに転送し、ConoHa のメールサーバーからプロキシ サーバーへの返答をプロキシ サーバーがメーラーに転送する形にします。 この形態であればメーラーが通信する相手はプロキシ サーバーになるので、プロキシ サーバーに正しい証明書が設定してあればメーラーで警告が表示されることは起こりません。 ConoHa のメールサーバーから送られてくるワイルド カードを含む証明書については、プロキシ サーバーで無視するように設定できればここでも警告が出るようなことにはなりません。

プロキシ サーバーを使えば証明書の問題が解決しそうなことは分かりました。 次はどのようにこれを実現するかです。 最初は stunnel と nc を組みあわせればなんとかなるくらいの、なんとも安直な思いつきでした。 POP3s や IMAPs のようにセッションの当初から SSL/TLS で暗号化していればうまくいくかもしれません (試していません)。 しかし、STARTTLS を使ったセッションの途中から SSL/TLS による暗号化に切り替わる通信に対応するのは、どう考えても一筋縄ではいきません。

そんなことを考えながらインターネットの海を漂っていたら、Dovecot がプロキシ機能を持っているという情報を見つけました。 最後に Dovecot を触ったのは 2 年ほど前と思います。 まったく意識していなかったのですが、そのときにはすでにプロキシ機能を提供していたようです。 しかも、Dovocot 2.3 からは Submission ポートによる SMTP サービスにも対応しています。

Dovecot にプロキシ機能があるのならばと、Dovecot のドキュメントの「Proxying」や「IMAP and POP3 session proxying」、「Submission」のページを読んで試行錯誤を行い、なんとか実装に漕ぎつきました。 その際の設定をこの場で報告しようかと思いましたが、雑文に文字数を費やしてしまったので次の記事で紹介します。

Comments