postfix とdovecot (SMTP Auth) でvirtual　その４(Lets encryptをsnapdで)

Lets Encrypt証明書の更新プログラムインストール

今まではepel ＋certbotのインストールで済ませてきたのだけれど、snapdに置き換わったということで、インストールの記録。途中、参考サイトのとおりだとエラーが出てた部分を修正した手順にした。これが終わっていないとdovecotもpostfixも中途半端な設定のままテスト、インストール後に変更という流れになるので、一気に行うとしたらこれから始めたほうが良い。（でも、一つ一つのコンポーネントを確認しながらするなら、SSLは後のほうが良いかも)

インストール手順

# dnf install snapd
（出力省略）

# systemctl enable –now snapd.socket
Created symlink /etc/systemd/system/sockets.target.wants/snapd.socket → /usr/lib/systemd/system/snapd.socket.

snapdは常駐daemonなので、socketを作るということなんだなと思う。enableで自動起動もあると思うけど。

# ln -s /var/lib/snapd/snap /snap

このシンボリックリンクはクラシックタイプのアプリケーション用だそうで。CentOSは自動じゃないとか？

# systemctl status snapd
● snapd.service – Snap Daemon
Loaded: loaded (/usr/lib/systemd/system/snapd.service; disabled; vendor preset: disabled)
Active: inactive (dead)

起動状態を確認してみると、この時点で停止している。これは、コマンドを実行しようとするとエラーになる原因じゃないか？と考えた次第。

# systemctl start snapd
# systemctl status snapd
● snapd.service – Snap Daemon
Loaded: loaded (/usr/lib/systemd/system/snapd.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2021-05-03 21:43:44 JST; 1s ago
Main PID: 551929 (snapd)
Tasks: 8 (limit: 6082)
Memory: 46.3M
CGroup: /system.slice/snapd.service
└─551929 /usr/libexec/snapd/snapd
May 03 21:43:44 ik1-341-30827.vs.sakura.ne.jp systemd[1]: Starting Snap Daemon…
May 03 21:43:44 ik1-341-30827.vs.sakura.ne.jp snapd[551929]: AppArmor status: apparmor not enabled
May 03 21:43:44 ik1-341-30827.vs.sakura.ne.jp snapd[551929]: daemon.go:347: started snapd/2.49-2.el8 (series 16; classic; devmode) centos/>
May 03 21:43:44 ik1-341-30827.vs.sakura.ne.jp snapd[551929]: daemon.go:440: adjusting startup timeout by 30s (pessimistic estimate of 30s >
May 03 21:43:44 ik1-341-30827.vs.sakura.ne.jp snapd[551929]: helpers.go:105: error trying to compare the snap system key: system-key missi>
May 03 21:43:44 ik1-341-30827.vs.sakura.ne.jp systemd[1]: Started Snap Daemon.

# snap install core
2021-05-03T21:44:52+09:00 INFO Waiting for automatic snapd restart…
core 16-2.49.2 from Canonical✓ installed

起動してからcoreのインストールを行うと、他サイトで出力例が出ていたようなエラーが発生しない。

# snap refresh core
snap “core” has no updates available

# snap install –classic certbot
certbot 1.14.0 from Certbot Project (certbot-eff✓) installed

ここまででcertbotをインストール。最後にCentOSでは自動で張ってくれないシンボリックリンクを作る。

# ln -s /snap/bin/certbot /usr/bin/certbot

# certbot –version
certbot 1.14.0

インストールしたバージョンを確認して完了。

証明書の取得

# certbot certonly –standalone

これはDNSを変更してからしか行えなかったので、それまでは移転前のサーバで取得した証明書をコピーして適用した。

証明書の更新テスト

既に証明書のファイルが存在している場合は-0001のように連番が降られるんだなと気づきがあったりした。

自動更新タイマーの設定

　このコマンドで自動的に定期更新するっていう記述を見たのだが…

# snap start –enable certbot.renew

# snap services
Service Startup Current Notes
certbot.renew disabled inactive timer-activated

確認用のコマンドを打つとdisabled でinactiveって出てしまう。変だなと思ったので下記のコマンドで確認。

# systemctl restart snap.certbot.renew.timer
# systemctl status snap.certbot.renew.timer
● snap.certbot.renew.timer – Timer renew for snap application certbot.renew
Loaded: loaded (/etc/systemd/system/snap.certbot.renew.timer; enabled; vendor preset: disabled)
Active: active (waiting) since Wed 2021-05-05 17:29:14 JST; 5s ago
Trigger: Wed 2021-05-05 23:19:00 JST; 5h 49min left

May 05 17:29:14 mail.redalarm.jp systemd[1]: snap.certbot.renew.timer: Succeeded.
May 05 17:29:14 mail.redalarm.jp systemd[1]: Stopped Timer renew for snap application certbot.renew.
May 05 17:29:14 mail.redalarm.jp systemd[1]: Stopping Timer renew for snap application certbot.renew.
May 05 17:29:14 mail.redalarm.jp systemd[1]: Started Timer renew for snap application certbot.renew.

これを見る限りは動くし次も取得するように見えるのだが…snap services の結果は変化がなく、disabled inactiveに。

# systemctl enable snap.certbot.renew.service
Created symlink /etc/systemd/system/multi-user.target.wants/snap.certbot.renew.service → /etc/systemd/system/snap.certbot.renew.service.

試しに上記のコマンドでenableを発行してみた。

# systemctl status snap.certbot.renew.service
● snap.certbot.renew.service – Service for snap application certbot.renew
Loaded: loaded (/etc/systemd/system/snap.certbot.renew.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Wed 2021-05-05 18:14:14 JST; 2s ago
Process: 3054 ExecStart=/usr/bin/snap run –timer=00:00~24:00/2 certbot.renew (code=exited, status=0/SUCCESS)
Main PID: 3054 (code=exited, status=0/SUCCESS)

May 05 18:14:13 mail.redalarm.jp systemd[1]: Starting Service for snap application certbot.renew…
May 05 18:14:14 mail.redalarm.jp systemd[1]: snap.certbot.renew.service: Succeeded.
May 05 18:14:14 mail.redalarm.jp systemd[1]: Started Service for snap application certbot.renew.

# snap services
Service Startup Current Notes
certbot.renew enabled inactive timer-activated

上記のようにsnap servicesも変化が起こった。つまり、CentOSの実装に寄せたやり方をしないとダメということなんだろうか？多分、更新はされるんだろうし、自動起動も行われると思うんだけれど、確認できるのがかなり先だったから安心を得るためにもこの手順で構築するのが良いかと思っている。

更新時のpostfix,dovecot再起動スクリプト

# POST_SCRIPT=”/etc/letsencrypt/renewal-hooks/post/reload.sh”
# echo -e ‘#!/bin/bash\nsystemctl reload postfix dovecot’ >${POST_SCRIPT} && chmod +x ${POST_SCRIPT}

このコマンドの発行の仕方はさくらインターネットのスクリプトから。なるほどねーって思う。

(2021/10/1 追記)
当初、systemctl reload … と記載したが、dovecotの証明書がreloadでは更新されないことが分かった。iOSなどで期限切れになった場合、アカウント設定の削除、再設定などが必要で大変手間取ってしまった。reloadで大丈夫と思ったのは、rpm をアップデートする際に再起動されていたから発見しにくかったのかもしれない。大変申し訳ないのですが、systemctl restart で設定してみてください。

と思っていたら、9/30の問題はlets encryptのルート証明書問題だった。早とちり。ということは、iOSのメールソフトウェアのほうが対応できていなかったという気がする。(iOSは古いルート証明書の延長を認めなかったというだけで、対応できていないというより、しなかったというほうが正しいかもしれない)

Let’s Encrypt証明書を使ったメールサーバからの送受信がiOSでエラーになる場合の対処方法
当面、証明書の許可をiOSのほうで行ったが、3か月後再びエラー。再度証明書許可が面倒だったので調べた。ISRG Root X1の証明書の強制変更したうえで、fullchain.pemを使う方法じゃないと中間証明書が入ってこないのでエラーが解消されないという状態だった。(2022/1/07 追記)

# vim /etc/letsencrypt/renewal/****.redalarm.jp-0001.conf
—-
#renew_before_expiry = 30 days
version = 1.14.0
archive_dir = /etc/letsencrypt/archive/mail.redalarm.jp-0001
cert = /etc/letsencrypt/live/mail.redalarm.jp-0001/cert.pem
privkey = /etc/letsencrypt/live/mail.redalarm.jp-0001/privkey.pem
chain = /etc/letsencrypt/live/mail.redalarm.jp-0001/chain.pem
fullchain = /etc/letsencrypt/live/mail.redalarm.jp-0001/fullchain.pem

#Options used in the renewal process
[renewalparams]
account = 97083cf83392e4930a3e8eb2a518ec48
authenticator = standalone
server = https://acme-v02.api.letsencrypt.org/directory
post_hook = /etc/letsencrypt/renewal-hooks/post/reload.sh
preferred_chain = ISRG Root X1　（←　2022/01/07対応にて入った。）

このころになると、コマンドで設定ファイルを…っていうポリシーにかまってられないとばかりにvimで直接ファイル変更という手順になってしまっている。反省。赤字部分を追記している。

cert.pem の記述からfullchain.pemの記述に変更

# vim /etc/postfix/main.cf
# vim /etc/dovecot/conf.d/10-ssl.conf

postfix の変更箇所

[root@mail ~]# fgrep letsencrypt /etc/postfix/main.cf
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.************/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail. ************/privkey.pem

dovecotの変更箇所

[root@mail ~]# fgrep letsencrypt /etc/dovecot/conf.d/*
/etc/dovecot/conf.d/10-ssl.conf:ssl_cert = </etc/letsencrypt/live/mail. ************/fullchain.pem
/etc/dovecot/conf.d/10-ssl.conf:ssl_key = </etc/letsencrypt/live/mail. ************/privkey.pem