一部環境からメールが届かない原因はSSL証明書(ECC)の種類だった

この記事は、作成日から6年経過しています。内容が古い可能性があります。またこの記事は、大幅なデザイン変更前に書かれたものですので、レイアウトが崩れている可能性があります。ご了承ください。

 以下のような3点セットのエラーがメールログに出る背景はいくつかありますが、私がネットで調べる限り(英語・日本語)、今回の背景に該当する記事はありませんでしたので、記事にしておきます。

  • SSL_accept error
  • warning: TLS library problem
  • lost connection after CONNECT

これは当社で起きた実例ですが、一般的に利用されるRSA版のSSL証明書ではなく、ECC版のSSL証明書をメールサーバに設定したことが原因でした(ここでは、RSA版は、いま一番普及している一般的なSSL証明書、ECC版は次世代のSSL証明書と思ってお読みください。詳細なECC版SSL証明書とRSA版SSL証明書の違いについては、「小悪魔女子大生のサーバエンジニア日記(ECC版SSL証明書インストール体験記その1)」をご参照ください)。当社は試験的にECC版を一部の社内限定のWebページで設定していますが、私のミスで、メールサーバにもECC版を設定してしまいました。

 設定したのは2018年6月中旬ですが、今月の中旬までの2か月、一切気づきませんでした。というのも、特にメールの送受信で問題がなかったからです。しかしながら、ある取引先から、「メールを送るとエラーが返ってくる」という連絡をいただき、ログファイルを調査したところ、上記の3点セットが見つかりました。

 原因の特定はさほど難しくはありませんでした。メールサーバを現サーバに移設してから1年間、安定して動いていたので、設定に問題がない前提で問題解決を図りました。すると、2か月前に変更した箇所が証明書の場所だということがわかり、ECC版が設定されていることがわかったので、RSA版に設定しなおしたら問題なく当該の取引先からのメールが届きました。

 要するに、相手側のサーバが当社のサーバにつなごうとする際に、ECC版の証明書に対応していないサーバの場合、エラーがでます。そこで、当社に受信するサーバのどれだけがECC版でエラーがでるかを以下の条件でざっくりと何件あったか調べてみました。

 条件1:7月29日~8月20日のメールログ
 条件2:時間をかけるほどのものではないので、ザックリとした正規表現処理のみをおこなっています。
 結果:14メールサーバ(FQDNベースです。ドメインベースでは6件です)。
 説明:6件、つまり、6社のうち3社はメールサーバが一つでそこからトライして、当社がはじいたものです。残りの3社は、複数のメールサーバを保有し(3つ~5つ)、そのサーバを変えて、当社のメールサーバに送信し続けました。この複数保有する3社は最終的には、ECC版証明書を読めるメールサーバから送信され、当社では受信しています。つまり、実際に受信できなかったのは3社で、そのうち、2社はあまり読んでいないメールマガジンの発行元でした。1社が今回の事案が発覚したきっかけとなった会社様です。

 つまり、かなり該当数が少なく、1%にも満たない量です。もちろん、届かない危険がある以上、メールサーバでの利用は避けるべきですし、当社も避けますが、多くのサーバがECC版に対応していることは、幸か不幸か今回の事案のおかげで理解できました。

 

  • URLをコピーしました!
  • URLをコピーしました!

コメント

コメントする

目次