弊社が提供しているホスティングサービスでは、接続先メールサーバの情報として【pop.<ドメイン名>】【smtp.<ドメイン名>】というような、エンドユーザーが所有しているドメインを使った接続情報を案内しています。
そのためメールサーバーにSSL通信を利用して接続するためには、接続先メールサーバの情報に沿った証明書を用意する必要があるので「Let’s Encrypt（https://letsencrypt.org/）」を使い、ワイルドカード形式の証明書を生成しメールサーバーに適用しています。
Let’s Encryptで発行される証明書は「3ヶ月」という短い有効期限となっているため、1年間に最低4回（複数のサーバを管理しているので、作業としては年間数十回以上）の更新作業が必要となります。
一般的な利用方法であれば、シェルプログラムなどを利用して自動更新することができますが、ワイルドカード形式の場合はDNS情報のテキストレコードにチャレンジトークンを設定し認証する必要があるため自動化することが難しいので手作業で行っています。
先日、とあるメールサーバに於いて、Let’s encryptで発行した証明書の有効期限が迫ってきたので今までの作業通りに証明書の更新作業を行ったのですが、しばらくして「今まで使えていたのに、急にメール送信ができなくなった」というお問い合わせをいただきました。
お問い合わせいただいた方の状況を確認すると、メールソフトの設定は送信・受信ともSSL通信を利用してメールサーバーに接続するようになっていて、受信に関しては問題はなく、送信に関してのみ問題が発生している状況でした。また、送信に関してはSSL通信を利用しない設定に変更することでメールサーバーに接続できる状況でした。
ということは、Let’s encryptで発行した証明書を更新したことで発生した間違いない状況でした。
「メールサーバの証明書は更新したことが原因ならば送信・受信の両方ができないならわかるが、送信だけができないとは、なぜだろう？」
そこでLet’s Encryptが生成した更新された鍵情報を確認してみると、秘密鍵の情報が今までみたことがないくらいにデータ量が少ない状況で生成されていました。
前回の証明書の更新の際には、このような状況ではなかったのでLet’s encryptに関して情報収集をすると、Let’s encryptで証明書を取得するときに利用する「certbot」というプログラムについて、新規に生成する証明書の暗号化方式を「ECDSA (secp256r1)」を規定値とするアナウンスがされていました。
（https://github.com/certbot/certbot/releases/tag/v2.0.0）
一方メールサーバーについて確認すると、証明書の更新の対象となったサーバーのメール機能は「qmail（http://qmail.org/top.html）」というアプリケーションを利用しており、こちらに関しても情報収集してみたのですが、qmailがECDSAに対応しているという情報をみつけることができませんでした。
つまり、Let’s encryptによって生成された証明書はqmailでは理解されない形式であったために送信だけが利用できない状況が生じていたということが言える結果となりました。
解決方法として、certbotには暗号化方式を指定する設定（–key-type）があったので、RSA方式で生成するように指定して証明書を再生成し、登録しなおすことで今まで通り、SSL通信を使ったメールの送信が行えるようになりました。
certbot certonly --key-type rsa --manual -d *.server1.example.com -m admin@server1.example.com --agree-tos --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory --cert-name server1.example.comお問い合わせはこちら
サイト上に掲載している情報はほんの一部です。
詳細な資料をご希望の方は、項目を入力し、ボタンをクリックしてください。
