Scribble at 2022-06-02 10:32:22 Last modified: 2022-06-02 14:15:20

数年前から或る史跡のプロモーション・サイトを SAKURA のクラウドでホストしている。昨今は SSL サーバ証明書として多くのレンタル・サーバが Let's Encrypt をサポートしているし、企業や官公庁でも導入が進んでいる。

ちなみに、企業のサービス・サイトや公的な機関が Let's Encrypt のような無償のサーバ証明書を使うことに不安を感じる方がいるかもしれないし、どこの証明書を使ってるか調べる方法も知らずに「導入事例がない」などと何の根拠もなく言う人だっている（調べたらいくらでもある筈だが。ssl.dentsu-east.co.jp: 電通東日本とか www.dentsu-ok.co.jp: 電通沖縄とか・・・それにしても、グループで使ってる証明書がバラバラだな。地元の業者の言いなりなのか）。しかし、いまやそんな不安に根拠はないし、そもそもエンド・ユーザはサーバ証明書の CA なんて気にしていない。企業として情報の通信について、どういう態度をとっているのかを知るシグナルとしてブラウザの鍵アイコンを見ているのだ。なので、企業で Let's Encrypt を使ってもそれだけで何か重大な問題だというわけではない。それどころか、企業向けにも特別な証明書を発行してきたイギリスの Comodo とオランダの DigiNotar という二社のサーバ証明書が偽造されていたという事件が起きて2011年頃は大騒ぎだったわけである。既存の証明機関が攻撃されたのでは、HTTPS 通信を普及させるというキャンペーンが進まない。そういうこともあって、Let's Encrypt のようなプロジェクトも強力に展開されたのだと言える（不安はあっても「タダ」には勝てないというわけか）。

あと、日本の SNS ではおなじみの立命館大学の上原哲太郎という人物は、情報セキュリティの研究者として企業が Let's Encrypt を利用することに否定的な意見を言っていた一人だが、その根拠は Twitter とか、あるいは国内の情報科学研究者だけが利用している『情報処理』みたいな〈雑誌〉（あえて「学術誌」とは呼ばない）でも語られず、結局は上記のように無知な人々と同レベルの錯覚（ていどの低い情報セキュリティ関係者によくいるタイプだと、無料は怪しい、GAFA は信用できない系の陰謀論という理由もありえる）でものを言っているにすぎないと分かる。HTTPS 通信の信頼性なんて、エンド・ユーザには本当のところ分からない。通信工学の素養もなければ暗号論の簡単な代数すら理解していない人々が、いったいどうやって公開鍵暗号の仕組みを知った上で HTTPS の是非を判断できるのか。しかも、それぞれのサーバが使っているサーバ証明書を〈保証〉する CA が、数学や情報工学の理屈としてだけでなく、現実に安全であると保証できるなんて、情報セキュリティの実務家でも不可能な話だろう。僕が日頃から、公衆に目を向けず、業界人や国家官僚との関係しか考えていない機関だと侮蔑している情報セキュリティ大学院大学の教員で、CA の安全性を理屈ではなく事実として保証できる人間が一人でもいるだろうか。

とまぁ、Let's Encrypt の擁護とか正当化をしたいわけではなく、ごくふつうにどういう案件でも最近は使っていると言いたいだけだった。そして、ご承知のように Let's Encrypt は有効期間が（自分自身で revoke しない限り）最大で３ヵ月と決まっているため、なんらかの自動更新を仕組みとして採用するか、あるいはサイトの運営側からすれば実質的な「自動更新」となるようサーバの運用を誰かに任せるかを選ぶことになる。レンタル・サーバでは、もちろんサーバごとにたくさんのドメインがぶら下がっているため、自動更新を毎日のようにプログラムで実行しているだろう。あまりこういう実務を手作業でやっている事例はない筈だが、僕のように手作業で更新している事例も皆無ではない。

手作業には、もちろん「更新するのを忘れてしまう」という重大なリスクがある。しかし、自動更新のプログラムに任せておいても、更新を失敗してしまうリスクはあるため、こういうことはいずれにしても運用の中に手作業で確認したり実行する手間が不可欠だ。こういうことをプログラムや「システム」と雑に呼んでいる何かに任せておけばいいという発想は、システム開発に携わる者としては「３流」と言っていいし、仕事としてやっているならリスク管理が必須の企業人としても「３流」と言わざるをえない。

とは言え、サーバの管理もできる僕のような強力な人材が敢えて手作業で SSL サーバ証明書を更新する正当な（あるいは仕方のない）理由などあるのだろうか。あると言えばあるし、現にその理由があるからこそ僕は手作業で更新する方が（安全かどうかは保証できないが）安心なのである。

手動で更新している理由としては、第一に、Let's Encrypt の管理ツールである certbot というスクリプトの挙動が、cron で実行した際に思ったほど安定していない場合があることだ。手動なら正しく更新できるのに、cron で実行すると失敗するという変な挙動がある。そして、同じ SAKURA のクラウドで同じような仕様のインスタンスとしてサーバを構築しても、certbot を cron で問題なく更新できているサイトもあれば、そうでないサイトもあるという、かなり不安定な状況を経験している。もちろん、原因が何なのかは調べているが、いまのところはっきりとした結論は出ていない。よくあるのは、certbot コマンドで "webroot" のオプションを指定しなかったせいでルート・ディレクトリを見失っているのではないかという可能性だが、３か月ごとに自動更新で問題ないサイト（サーバ）でも、僕は webroot のオプションなんて crontab の設定につけていない。

0 3 1 * * /usr/bin/certbot renew -q --deploy-hook "systemctl restart httpd" 2>&1 | Mail system.info@DOMAIN.co.jp

こんな具合で、毎月１日の午前３時に実行しているが、この設定で何の問題もない（そして、問題が起きるサーバでも全く同じ設定で cron に登録している）。

手動で更新している第二の理由は、更新する際は Let's Encrypt の管理団体側から確認のために弊社の管理するサーバへ通信してくるわけだが、これは必ず〈HTTP〉通信だ。しかし、得てして「常時HTTPS化」などという安っぽいスローガンで SSL サーバ証明書を付け焼刃で導入するウェブ制作会社とか開発会社の未熟な人々がよくやる間違いとして、常に全てのリクエストを HTTPS へのリクエストに転送したり書き換えるような設定をサーバに導入してしまうことがある。もちろん僕はそういう愚行などしないけれど、かといって HTTP でのリクエストをそのままにしておくのも良くないのは確かだ。よって、Let's Encrypt の管理団体からのリクエストだけを http:// として処理するように Apache の mod_rewrite モジュールで処理するという手法が使われることも多い。ただ、僕はそういうやり方が適切かどうか確証がない。そういう抜け穴を作ることで自らサーバを脆弱にしている可能性もあるからだ。よって、手動で更新するときだけ HTTP でレスポンスできる状態にして、普段は HTTP のリクエストを全て一律に HTTPS へと転送している。

第三の理由は、snapd のようなパッケージ管理ツールでインストールされた certbot の場合など、特別な条件では自動で certbot が systemd の timer を使って更新処理するようになっている。でも、ディフォールトでは毎日２回も更新処理を実行するというのは、僕にはバカげた設定に思えるので、そういう無駄な仕組みは敢えて使いたくない。ドメインを、サブドメインも含めて数個しか運用していないサーバで、いったい何の理由があって毎日、しかも２回ずつ certbot を実行しなくてはいけないというのか、僕には DevOps のプロとしても理解に苦しむ。単なる計算資源とネットワーク帯域の浪費でしかないだろう。

それから、頻度だけが問題なら設定を書き換えたらいいだけなのだが、問題はそれだけではない。systemd はデーモン（サービス）の制御に使われるもの（デーモン管理用のデーモン）だが、これをただの更新プログラムの制御に流用するという発想は、僕にはどう考えても危険だと思える。しかも、未熟なサーバ技術者に限って、こんな使い方を "cron alternative" つまりナウいテクニックだと言ってイージーに広めたがるものだ。また、systemd.timer には処理に失敗したときのメール送信という機能がサポートされていないため、管理目的に追加のスクリプトを組む必要があったり、〈仕事で使うには〉それなりの手間がかかるのも事実である。なお、僕は systemd そのものの是非（特に、その中央集権的な systemd の仕様が UNIX の哲学に反していて排他的だという批判がよくある）については、ここで議論したいとは思わない。物事には運用レベルと運用すべき対象のレベルというものがあって、この階層を無視して「便利」というだけの理由で、root ユーザが使うようなツールで単なるスクリプトを実行するといった愚行は避けなくてはいけない。