メールサーバ - 証明書・接続拒否・中継確認 - unable to load RSA private key


 クラウディア　
1.　概要
2.　状況
3.　オチ
4.　後始末 
1.　概要


　本章の前の方で書いているかと思いますが、現在、メールサーバに対する、「smtp」や「pop3」「imap」については、「SSL」を通してアクセスするようにしています。
　証明書は、「Let's Encrypt」より取得しています。

　メールサーバは、２台たてておりまして、１台がメイン。
　もう一台は、単にメインのサーバにログを送るだけの役割です。


2.　状況


　詳細をいきなり書くと、ばればれなので、ちょっとぼかして書きますが。
　サブのマシンの方で、証明書の更新がありまして。
　ちょうどその日に、メール関連の「ports」に更新があったので、、メールサーバを再起動しましたらば。
　「smtpd ssl」と「pop3d ssl」が起動しないのだ。

　焦りますわなぁ。
　起動しないものを再度起動してみると、ログに。



Mar  4 12:15:19 nt smtpds[39093]: 1709522119.616688 tcpserver: fatal: unable to load RSA private key



　てな表示があります。


3.　オチ


　バカすぎるので、途中経過は省略します。
　実は、メールサーバの証明書に関しては、メインもサブも同じものを使用していたのです。

　サブの証明書更新スクリプトにサブマシンのなにかが更新されたら、サブマシンのメールサーバ証明書も更新するように記述してあったのですが。
　これは、必要なかった。
　速やかに、メインのマシンから証明書を持ってきて、置き換えたら、起動できるようになりました。

　メインのマシンの証明書が更新されたら、自動で、サブマシンの証明書を更新するには、どうしたらいいのか・・・。
　という問題は、残ってしまっているのですが・・・。


4.　後始末


　まぁ、後始末といいますか。
　メイン側にある。



/パス/cert.pem



　を持ってきて、サブマシンのものを更新するスクリプトは、下記のように書きました。



#!/bin/sh
export CRYPTOGRAPHY_OPENSSL_NO_LEGACY=1

/usr/local/bin/certbot \
    renew \
    --standalone \
    --pre-hook "/usr/local/etc/rc.d/apache24 stop" \
    --post-hook "/usr/local/etc/rc.d/apache24 start"

sftp -i ~/.ssh/メインの鍵ファイル -b バッチファイル ログインユーザ名@メインマシン名

if [ /tmp/cert.pem -nt /パス/cert.pem ]; then
  cp -p /tmp/cert.pem /パス/cert.pem
fi



　2～8行目は、もともとのサブマシンの証明書ファイルを更新する処理です。
　10行目で、「sftp」を使って、メインマシンの証明書を取得しています。
　12～14行目で、取得したメインマシンの証明書が新しければ、サブマシンの証明書を更新しています。
　証明書更新の際に、メールサーバのデーモンを再起動すべきかがよくわからない。
　更新が発生したときに、確かめるしかないかなぁ。

　「sftp」については、ちょっと苦労しました。
　「sftp」でバッチファイルを使う方法については、「FTP クライアント - sftp コマンド」をご参照ください。

　「sftp」でログインするのは、「root」ユーザではないのですが・・・。
　一度、「root」ユーザで、ログインユーザで、メインマシンに「sftp」でつないで。



~/.ssh/known_hosts



　に記録しておかなければならないし。
　ログインの際の鍵ファイルも。



~/.ssh/



　の中において、適切なパーミッションをつけておかなければ、なりません。