Google(では無いけれど)のサイト証明書の自動更新を試してみる

Googleのサイト証明書を取得してみる(2)で、サイト証明書は取れた。
なので、今度は自動更新の準備をすることにした。
例によって、AIさん全面依存で進める。

先ずはcertbotで何か準備をするらしい。(まるで理解していない)

–webroot -w server root path は一回だけ使う。pathを変更したら、もう一回設定し直すのだろう。(推測)
-d web site name は、ほぼ固定になるね。
すると /opt/local/etc/letsencrypt/renewal/niwakan.k-in.co.jp.conf と言うファイルに1行追加された。

この1行だ。
webroot_path = /Volumes/Works/Library/www/niwakan,
これで、どこに書き込む?のか解るのだろう。(知らんけど)

実際に動作確認をする。
% sudo /opt/local/bin/certbot certonly -d niwakan.k-in.co.jp

全く意味が判らないので、Google翻訳さんの出番である。

デバッグログを /opt/local/var/log/letsencrypt/letsencrypt.log に保存しています。
ssl_module は静的にリンクされていますが –apache-bin が指定されていません。セッションチケット機能は無効化されません。

ACME CA での認証方法を選択してください。
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
1: Apache Web Server プラグイン (apache)
2: ローカルで HTTP サーバーを起動し、/.well-known/acme-challenge/ リクエストパス配下で必要な検証用ファイルを提供します。HTTP サーバーがまだ稼働していない場合に適しています。HTTP チャレンジのみ(ワイルドカードは非対応)。(standalone)

3: 指定された webroot パス内の .well-known/acme-challenge/ ディレクトリに、必要な検証用ファイルを保存します。別途 HTTP サーバーが稼働しており、その webroot パスからファイルを提供している必要があります。HTTP チャレンジのみ(ワイルドカードは非対応)。(webroot)
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
適切な番号 [1-3] を選択して [Enter] キーを押してください(キャンセルする場合は ‘c’ を入力): 1
証明書の更新時期ではありません

要求されたドメインまたは証明書名と完全に一致し、かつ有効期限が迫っていない既存の証明書が存在します。
(参照: /opt/local/etc/letsencrypt/renewal/niwakan.k-in.co.jp.conf)

どうしますか?
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
1: 現在の証明書をそのまま使用する
2: 証明書を更新・置換する (CAのレート制限が適用される場合があります)
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
適切な番号 [1-2] を選択して [Enter] キーを押してください (キャンセルする場合は ‘c’ を入力): 1

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
証明書の更新時期ではないため、処理は行われませんでした。
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

対話型だから、crontabには登録できない。
でも、この辺はAIさんにでも、Geminiさんにでも聞けば教えてくれるから問題ない。
早速、AIさんに聞いたら教えて貰えた。
こうである。

ただ、–webrootは既にconfig fileに書き込まれているから必要ないだろう。取っ払ってしまう。
そして、shell scriptを書く。

そしてcrontabに登録する。

実際にsudo /usr/local/sbin/update_cert.shと起動したら、問題が起きた。

Saving debug log to /opt/local/var/log/letsencrypt/letsencrypt.log
Missing command line flags. For non-interactive execution, you will need to specify a plugin on the command line. Run with ‘–help plugins’ to see a list of options, and see https://eff.org/letsencrypt-plugins for more detail on what the plugins do and how to use them.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /opt/local/var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

これじゃ更新できない。
『certbot 自動更新 apache』でググる。
一番上に「Apache 2.x + Certbot(新規、自動更新)」があったので、そこを探す。
certbot renewこれだけで良いらしい。
実際にやってみた。
sudo certbot renew

綺麗に終わったので、crontabを書き直す。

土曜日にしたのは、serverが日曜日の夜更けに再起動するから。
最大30日間の猶予があるから、1日の時間差があっても証明書には影響が無いだろうと、こうした。

週一回の確認にした理由はこうだ。
「更新は30日前からなので、更新確認は15日くらいで良いのでは?」との問いに、AIさんは

実行間隔を「15日に1回」など、少し長めの間隔にするアプローチでも技術的には全く問題なく、証明書は絶対に切れません。

ただ、実はインターネット全体の運用(CertbotやLet’s Encryptの公式ガイド)として、「15日ごとではなく、週1回(なんなら毎日)」実行することが推奨されているのには、ある『笑えないセキュリティ上の大人の事情(リスク回避)』があります。

なぜ「週1回」や「毎日」実行が推奨されるのか?
理由は単純で、「GoogleやLet’s Encrypt(認証局)のサーバーが、その15日に1回のタイミングで、たまたまメンテナンスや障害で落ちていたら、次のチャンスが15日後(つまりもう期限切れ寸前)になってしまうから」です。

と、言うことで認証局側のお薦めだからでした。
確認は、2ヶ月後となりますね。
それまで待ちましょう。(多分忘れているなぁ)

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)