前の記事で書いたように、この年末年始に某社のメールサーバーを ConoHa のメールサーバーに移行しました。 しかしながら通信路を暗号化するための証明書の問題で、メーラーに Outlook を使うと毎起動の度に 証明書の警告が出ることが分かりました。 これをなんとかしようとメーラーと ConoHa のメールサーバーの間にプロキシ サーバーを置いて、メーラーからの送受信はプロキシ サーバーに対して行い、プロキシ サーバーはそれを ConoHa のメールサーバーに転送し、ConoHa のメールサーバーからプロキシ サーバーへの返答をプロキシ サーバーがメーラーに転送する形にします。 この形態であればメーラーが通信するのはプロキシ サーバーになるので、プロキシ サーバーに正しい証明書が設定してあれば、メーラーで警告が表示されることは起こりません。 ConoHa のメールサーバーから送られてくるワイルド カードを含む証明書については、プロキシ サーバーで無視するように設定できればここでも警告が出るようなことになりません。

この記事では、このプロキシ サーバーを実現するために使った Dovecot の設定を紹介します。

Read more...

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

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

Read more...

Web サイトを SSL 対応にしたり、ログイン時の認証をクライアント証明書で行うようにするときには電子証明書を使います。 本ブログでも、このようなことを記事に書いています。 このときに使う電子証明書は StartSSL で発行したものを使い、記事にもそのように書いています。

しかし、昨年 (2016年) に証明書発行に関する問題がいくつも発覚したことで、Mozilla の Firefox や Google の Chrome などの主要なブラウザーが、StartSSL (これを管理する StartCOM 社) が発行した証明書を信頼できない証明書として扱うようになりました。 StartSSL は一般に公開された認証局の中で数少ない、無料で証明書を発行してくれる認証局です。 発行できる証明書は DV 証明書で、有効期間がサーバー証明書が 1 年、クライアント証明書が 2 年にという条件が付きますが、なによりも無料というのは実験的な使用には十分に魅力でした。

Read more...

先の記事で、Azure の仮想ネットワークにポイント対サイト (P2S) 接続するときに必要になる、ルート証明書とクライアント証明書の作り方を書いた。 そこで Azure の P2S 接続につかう証明書は「自己署名証明書が推奨」されており、商用認証局で購入した者ではセキュリティ的に問題が生じると記した。

筆者個人の推測ではあるが、ここにその理由を述べる。

Read more...

Azure に ポイント対サイト (P2S) 接続をする際に必要な、ルート証明書とクライアント証明書をWindows の makecert.exe コマンドを使って作成する方法を先の記事で書いた。 加えて、作成した証明書の内容を前の記事に書いた。 それを元にして、Linux の OpenSSL で同様な証明書を作成してみる。

Read more...