ホーム 記事タイプ 技術発信 KUSANAGI環境でSSL(Let’s Encrypt)が自動更新されなくてspiritsがプライバシーエラーになってしまった件について
KUSANAGI環境でSSL(Let’s Encrypt)が自動更新されなくてspiritsがプライバシーエラーになってしまった件について
 

KUSANAGI環境でSSL(Let’s Encrypt)が自動更新されなくてspiritsがプライバシーエラーになってしまった件について

2020年10月14日、9時42分頃から12時頃まで、SSLの期限切れによって当サイトが『プライバシーエラー』という閲覧しづらい状態になっておりました。本件の原因調査と対応をOSDN室の青井室長に依頼し、無事解消いたしました。お騒がせしました。「せっかくだからこの話を記事にして共有しましょうよ!」とアピリッツの社内からも声があがりましたので、青井さんが今回の原因と、それをどうやって解決したかについて即まとめてくれました。(アピスピ編集部 白石)

本件の発生時刻は本日(2020年10月14日)、午前9時42分から11時43分で、後述しますがKUSANAGI移設作業の90日後にあたります。

この事象はKUSANAGIを利用されている方すべてに起こり得る内容であり、またWordPress・KUSANAGIの構成に限らずLet’s EncryptによるSSL証明書を利用している方のお役にたてるかもと思い記事公開するものです。

まず、原因はLet’s Encryptが「自動更新されていなかった」ことによるSSLの期限切れ。
「手動更新による解決」を実施の上、改めて「自動更新を設定」した事で同じ理由での再発は防げるかと思います。

原因:「自動更新されていなかった」は本当か?

元々spiritsはAWSの弊社開発環境の片隅を間借りして細々と動かしていましたが、「元気玉作戦に向けて管理画面のレスポンスを高速化しないと書いてくれる人に無用なストレスを与えてしまう」との理由で高速化する事になりました。

高速化の手法はEC2から『超高速CMS実行環境 KUSANAGI』への移設に決まり、7月の中頃にその移設作業を行いました。

移行作業時のチェックに『自動更新の設定』がなされているかを確認したはずなのにおかしいな……。
さっそくコンソールに入って確認しました。

[root@ip-XX-XX-XX-XX log]# crontab -l
#* * * * * /root/.kusanagi/provision-check.sh > /dev/null 2>&1
07 03 * * 0 /usr/bin/kusanagi update cert

やはり自動更新の設定はしてありました。

自動更新設定してあるはずが……

では、cron自体が実行されていないのでしょうか。確認してみます。

[root@ip-XX-XX-XX-XX log]# less /var/log/cron
Oct 11 03:01:01 ip-172-31-43-185 run-parts(/etc/cron.hourly)[8069]: starting 0anacron
Oct 11 03:01:01 ip-172-31-43-185 run-parts(/etc/cron.hourly)[8078]: finished 0anacron
Oct 11 03:07:01 ip-172-31-43-185 CROND[8422]: (root) CMD (/usr/bin/kusanagi update cert)
Oct 11 03:10:01 ip-172-31-43-185 CROND[8789]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Oct 11 03:20:01 ip-172-31-43-185 CROND[9303]: (root) CMD (/usr/lib64/sa/sa1 1 1)

cronは動いている……。

OKOK、ワカッテキタヨー! kusanagi update cert で調べたらいっぱいエラー報告出るモンネ!

[root@ip-XX-XX-XX-XX log]# /usr/bin/kusanagi update cert
完了しました。

ん?何事もなく通った。

更新されたSSLを見て絶望する自分

アイエエエエ!? クロン!? クロンナンデ!?

という事で調査でわかったのは「自動更新は設定されていたが、失敗し続けていた。しかも手動実行では成功した」という事実でした。

手動で実行して通るものが、2ヶ月あまり失敗しつづけた原因とは……。

困った時はやっぱりアピリッツ

そうだ、困った時はアピリッツに頼んでみよう!ということでWebシステム開発部隊に相談してみることに。

すると、数分でトップエンジニアの浅田さんなど、数人のエンジニアから様々な救いの手が!

一瞬で返ってくる的確なアドバイス

cronのログ、rootへのメール、letsencryptのログそれぞれを一緒にチェック。

ログから次々と読み解かれる情報

という訳で cron の設定を変更することにしました。

[root@ip-XX-XX-XX-XX log]# crontab -l
#* * * * * /root/.kusanagi/provision-check.sh > /dev/null 2>&1
07 03 * * 0 /bin/bash -lc "/usr/bin/kusanagi update cert"

総括

というわけで、総括です。

  • KUSANAGIを(特にAWS上)利用している皆様。cronでPATHが読めていない恐れがありますので、crontabを見なおしてください。
  • KUSANAGI側の修正を祈ります(後ほど報告予定)
  • 困った時はアピリッツ!

以上!ご迷惑おかけしました。

蛇足

浅田さんの今回の名言です。

オススメの記事です。是非読んで浅田さんのチャーミングさを感じてください。

記事を共有

最近人気な記事