OpenWrt で Let's Encrypt (with acme.sh)

このブログ記事を最初にまとめた当時（2020-11-11）には気付かなかったが、現在（2023-12-06）ではいつの間にか、OpenWrt のパッケージモジュールとして acme が用意されており、さらには LuCI から使うための luci-app-acme までも存在している。以前の僕はこれらの OpenWrt パッケージについて知らなかったので、acme.sh の公式サイトの説明に従って一般的な Linux マシンとしてインストールし、コマンドを実行して使用してと、愚直に自力の作業をしていたものである。今では OpenWrt の acme.sh についての公式の説明も存在するので、それに従って作業すれば、ほとんど苦もなく完了できる。

だが、acme.sh の実行による Let's Encrypt からの証明書の発行が半自動化されたとはいえ、DNS や NGINX などと連携させる必要があり、総合的な話としては一定の知識を要するので、ここにまとめておきたいと思う。

Web ルートの準備

acme.sh では証明書の発行時の身元確認の方式として、Web ルートに .well-known/acme-challenge という一時的な隠しフォルダを作成し、そこにユニークな文字列からなるファイル名を持ったファイルを設置して、インターネット側から http://（ドメイン名）/.well-known/acme-challenge/（ファイル名）にアクセスできるかどうかで、確認するという形になっている。

このため、いきなり、acme を使うのではなくて、先に DNS 側でドメインが OpenWrt ルーターの IP を指し示すように設定しておき、さらに OpenWrt ルーター側では、NGINX の設定で、そのドメイン名での http アクセスが /www 以下に対応付けられるようにしておかなければならない。

DNS の設定

A レコードでデフォルトドメインがルーターの IP アドレスを指し示すように設定している他、CNAME で www がデフォルトドメインの別名であるようにしている。CAA レコードは今回の趣旨とは全く関係がないオマケで、無関係の他者が勝手にこのドメイン名を使った証明書を作成することを防ぐためのものである（参考）。

ローカルディレクトリーの用意

ローカルの /www/.well-known/acme-challenge を Web 側からアクセスする acme のチャレンジ用に使うことにするが、acme プログラムが直接操作に使うのは /var/run（メモリー上に設置された一時ファイル）なので、次のようにしてシンボリックリンクを作成しておく：


mkdir /www/.well-known/
ln -s /var/run/acme/challenge/ /www/.well-known/acme-challenge

NGINX の設定

/etc/nginx/init.d/（ドメイン名）.conf：


server {
    listen 80;
    server_name （ドメイン名） www.（ドメイン名）;

	location /.well-known/acme-challenge/ {
		root /www;
	}
}

そのドメイン名に関して、acme が一時的に作成する .well-known/acme-challenge が HTTP（ポート 80）で Web からアクセスできるようにしておくことが必要である。ドメインのルート設定（root）は必ずしも /www にしておく必要はないが、この設定では、ローカルの /www/.well-known/acme-challenge/ 以下が acme のチャレンジ用に使われることになる。

「そのドメイン名に関して」というのは server_name のことである。他のドメイン名用の設定でポート 80 を利用するかどうかは関係ない。

以上のようにして、たとえば、test.txt をチャレンジ用ディレクトリーに置いてみて、http://（ドメイン名）/.well-known/acme-challenge/test.txt に Web ブラウザーからアクセスできるかを確認して、問題ないのであれば、次に acme を使った作業に進んで問題ないだろう。

acme を使う


opkg update
opkg install luci-app-acme

もちろん、LuCI から luci-app-acme をインストールしても構わない。LuCI から一旦ログアウトして、ログインし直すと、Services > ACME certs という新しいメニューが増えているのがわかる。

やることはまず、この Acme certificates の Account email（更新通知などが来る管理用のアドレス。ドメイン名と関係なくても構わない）を適当に設定し、Save。

そのようにした上で、新しいドメイン設定項目を追加（Add）するか、既存のドメイン設定を選ぶ（Edit）かして、そのドメインの子ウィンドウを開く：

General Settings タブの Enabled を有効（✅）にし、Domain names をデフォルトドメインと、www 付きのサブドメインの両方をリストアップしておく。さらに Challenge Validation タブの Challenge method で「Webroot」を選んだ上にルートディレクトリーを指定して Save し、元の画面に戻ってから Save & Apply すればよい。設定が保存（Save）されるだけでなく、Apply により GUI の背後で acme.sh が実行され、ドメインの認証と証明書の発行が行われる。

処理の様子と結果はシステムログで確認できる：


Sat Dec  9 23:40:20 2023 daemon.info acme-acmesh: Running ACME for test.com
Sat Dec  9 23:40:20 2023 daemon.info acme-acmesh: /usr/lib/acme/client/acme.sh -d test.com -d www.test.com --keylength 2048 --accountemail tester@test.com --server letsencrypt --webroot /www --issue --home /etc/acme

（何らかのエラーが発生した場合には、上で acme-acmesh が実行している 2 行目のコマンド内容に --debug オプションをさらに追加して手動で実行してみるとよい。）

/etc/acme/（ドメイン名） 以下に fullchain.cer と、（ドメイン名）.key が置かれており、これを NGINX で使えばいい。

NGINX の該当ドメイン用の設定に反映する

/etc/nginx/init.d/（ドメイン名）.conf：


server {
    listen 80;
    server_name （ドメイン名） www.（ドメイン名）;

	location /.well-known/acme-challenge/ {
		root /www;
	}

	location / { # デフォルトでは https へのリダイレクト
		return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl;
    server_name （ドメイン名） www.（ドメイン名）;

    ssl_certificate     /etc/acme/（ドメイン名）/fullchain.cer;
    ssl_certificate_key /etc/acme/（ドメイン名）/（ドメイン名）.key;

    root /www/（ドメイン名）;
    index index.html;
}

上の NGINX の設定では、http:// を https:// にリダイレクトする設定にしている。下の server ブロックが https:// 用の設定であり、今回 acme によって半自動作成された fullchain.cer と（ドメイン名）.key を使っている（fullchain ではない通常の（ドメイン名）.cer も作成されるが、Apache 用に作成されるもので、NGINX には不要である）。

証明書の発行と NGINX の設定変更が無事に終ったならば、NGINX をリスタート（単なるリロードでは証明書まで再読み込みされないので注意）する：


service nginx restart

（NGINX の設定に問題がなければ、リスタートに成功する。問題がある場合、エラーになって、新しい設定の反映が拒否される）

CRON

acme は、自動更新のため、crontab（CRON ジョブ用の設定ファイル; /etc/crontabs/root）にも追記する。crontabは、OpenWrt では LuCI の System > Scheduled Tasks でも閲覧・編集が可能である：


0 0 * * * /etc/init.d/acme start

このような記述が追記されている。つまり、毎日 00:00 に 1 回、acme をサービスとして走らせているようだ。その時に、更新期限が迫っているドメインに関しては、更新するものと思われる。

設定ファイル

以上の作業の結果は、/etc/config/acme や、/etc/acme と、/etc/nginx/init.d/（ドメイン名）.conf の設定内容、crontab に存在することになる。

/etc/config/acme
acme が使う設定ファイル。LuCI からも閲覧・操作ができる。
/etc/acme
acme の管理下にある各ドメインの設定や、証明書などのファイルが置かれているディレクトリー
/etc/nginx/init.d/（ドメイン名）.conf
NGINX の各ドメインに関する設定ファイルで、証明書や暗号鍵を記載する
crontab (/etc/crontabs/root)
CRON が acme を毎日 1 回サービスとして走らせ、その結果 acme は更新が必要な場合には更新しようとする

備考：Used for nginx / uhttpd オプションについて

基本、これらのオプションは使わない。本来、セキュリティ上の観点からも LAN 向けで WAN（Web）向けには非公開で使われる前提の LuCI 用の証明書には OpenWrt の自己署名証明書が使われるが、ドメインの証明書を LuCI 用にも流用したい場合のオプションである。

備考：Standalone モードについて

OpenWrt の acme.sh モジュールでは Standalone モードでの acme チャレンジは上手く動かすことができなかった。公式のドキュメントでも、基本的には Webroot モードで解説されているので、無理に Standalone モードで行う必要はないと思う。

コメント

コメントを投稿

このブログの人気の投稿

清水俊史『上座部仏教における聖典論の研究』

清水俊史さんという仏教学者（佛教大学出身）が、東大教授（花園大学卒→東大編入 or 再入学？）の馬場紀寿氏と論争の末、アカハラ被害に遭い、さらには出版妨害に遭った（参考： 日本テーラワーダ仏教教会 事務局長 佐藤哲朗さんの YouTube 動画 ）という、問題作であるこの本を読んだ。 佐藤さんが紹介している Amazon の書評リンク にもある通り、この清水さんの本は、馬場氏の（今の東大教授としての地位へとつながる博士論文を母体とした）デビュー作『上座部仏教の思想形成――ブッダからブッダゴーサへ』の内容を完全否定するものである。 主に、清水さんの本の 3 部構成のうちの第 1 部がそれ（馬場説の完全否定劇）に該当する。 総括 第 1 部では、ブッダゴーサやダンマパーラに帰せられる著作群を主な材料として、小部の成立を軸とした三蔵の形成過程を考察した。以上をまとめれば、仏滅後からブッダゴーサを経てダンマパーラに至るまでに、三蔵は次のような段階を経て成立したと推定される。 仏滅後に残された様々な教えは、仏弟子たちによって、その内容に応じて律蔵と『長部』『中部』『相応部』『増支部』という経蔵四部とに収められ、僧団内にいる長部誦者や持律師と呼ばれる専門家たちがこれを伝承していった。この律蔵・四部から漏れた様々な種類の経典（主に偈頌経典）は、他の四部に比してより在家的・通俗的な蔵外文献として伝承され、『ジャータカ』と『ダンマパダ』の例外を除いて専門の誦者や伝持者は僧団内に存在しなかった。 これら四部の外側に累積していった蔵外文献（主に偈頌経典）は、 後に経蔵の第五部「小部」として三蔵内に組み込まれるが、経蔵が五部に再編成された後も小部の構成は固定的ではなく流動的であった。そのため、小部のうちには、成立が早いとされる『スッタニパータ』『ダンマパダ』といった韻文経典のみならず、成立が遅いと考えられ る『義釈』『無礙解道』といった教理書も収められている。このような編纂事情ゆえに、上座部における小部の伝持形態は、「小部」というーまとまりのセットで伝持するという意識が希薄であり、各々の文献単位で別個に伝持されていった。 また、小部の成立だけでなく、阿毘達磨蔵七書と律蔵附随の成立も遅いことが考えられるが、これら小部・阿毘達磨蔵・律蔵附随の成立の具体的な先後関係は不明であ
続きを読む

シークエンスパパともの先見の明

イメージ
先日、シンクロニシティ的に、故・シークエンスパパともが 2 年前に行った未解決事件に対する霊視が、ギャル霊媒師飯塚唯氏が最近行った霊視と、互いに補完し合うような内容であるということを ブログに 認 したた めた ばかりである。 ところで、さらにもう一つの、パパともの霊能力に関する（僕にとって）シンクロニシティ的なタイミングで到来した情報が発生した。 シークエンスはやとものチャンネルの動画などを観るようになったのがきっかけで、YouTube のお勧めに、オカルト系のチャンネルが多数表示されるようになってきたのだが、その一つに「都市ボーイズ」という都市伝説を中心としたオカルト系チャンネルがあった。こういうものを観だしたらキリがないので、基本はスルーしていたのだが、その都市ボーイズ（放送作家の岸本誠と早瀬康広のコンビ）がチャンネルにはやともがゲストで出演して生霊鑑定を行っていたのを観たので、そこから芋蔓式に都市ボーイズのチャンネルの動画も何本か観たりするようになった。 都市ボーイズはやせの黒魔術 当初は、はやせ（早瀬康広）に「黒い呪いのようなものがまとわりついている」という、はやともの生霊鑑定の結果を深掘りすべく、関連する動画を追った。はやせは、呪物コレクターであり、その上、最近（約 10 ヶ月前に公開された動画）、「呪いを飼い馴らして、黒魔術的な力を自分のものにする」という修行というか通過儀礼を行っていたというのである。 儀式を無事に終えて台湾系の呪術師に合格が認められたはやせは、「数年以内に自動的に能力が開花し、自分で自覚するだろう」と言われたという。 都市ボーイズはやせを怒らせた霊能者 そのようなはやせを擁する都市ボーイズだが、先日、「【テレビの闇】インチキ霊能力者にテレビ出演邪魔されました！【インチキ霊能者】」という刺激的なタイトルの動画が、たまたま僕が暇だった時、公開されたばかりのタイミングで見つけてしまったので、早速その動画を観た。 約 1 年前、とある霊能者の霊的な〝脅迫〟によって、はやせはテレビ出演を直前で降板させられてしまったそうである。 僕は、テレビは観なくなって久しい人間で、それこそ霊能者というとシークエンスはやともの言う「心霊第 3 世代」の宜保愛子で止まっていて、江原啓之ですら雑誌の見出しで名前を知っ
続きを読む

シークエンスパパとも 本物の霊能力

イメージ
シークエンスはやともを知ったきっかけ TV を見ない僕がシークエンスはやとも（YouTuber。吉本興業所属）の存在を知ったのは、今年の春（3 月か 4 月）の頃だったと思うが、YouTube でふと宜保愛子の動画を探していて、彼が宜保愛子を称賛するものを見つけて以来だったと思う。 それ以来いくつかの彼の動画をちょくちょく観るようになって、彼の霊能力が父親（シークエンスパパとも）譲りであり、パパともも息子のはやともに勧められて（癌闘病の傍ら）YouTuber として活躍していたのだが、残念ながら今年 1 月末に逝去していた、ということなどを知るようになった。 シークエンスパパともを知ったきっかけ はやとも流れでパパともの動画を観るきっかけになったのは、画面脇のお勧めに出ていた親子対談の動画を見たのが切っ掛けだった。 そこでのパパともの宮本武蔵に関するコメント（「晩年の宮本武蔵は一生懸命仏像を彫ったりしていたが、（若い頃）子供の道場主を殺したりしていたことによる怨霊は除霊できなかった」）に少しシビれた。息子のはやともが、まだ若いせいもあって、ちょっと話がマクロな（思想論や社会論的な）方向に行くと、厨二病的な傾向があるのには食傷気味な感じがあった。一方で、パパともの宗教・倫理観的な考えの方がその点、人間的な深さを感じるものがあったので、それがパパともに興味を引かれたきっかけだった。 パパともの霊能力に衝撃を受けた理由 そこで、初めて、パパとものチャンネルの動画もいくつか観たりしたのだが、「未解決事件を霊視する」という中々に攻めた企画を初期にやっていて興味深かったのだが、中に、上野の不忍池での事件（僕自身はこの 2006 年の事件については知らなかった）を扱ったものがあった： 「あっ！」と思ったのが、奇しくも前日（2023-06-28）、全く別のチャンネルの別の動画で、霊媒師が同じ事件を霊視するという企画のものを観ていたのだった： 千原せいじの YouTube チャンネルで、彼がコラボをしている飯島唯という通称・ギャル霊媒師の方が霊視をしている。 パパともの動画は 2021-05-12 と 2021-05-15 に公開されたものであるのに対し、ギャル霊媒師の動画は 2023-06-28 公開であり、僕はたまたま公開
続きを読む