Shaw's Home Page(本館)

はてなダイアリーから引っ越しました。

マストドンのインスタンスを立てる際のSSL証明書設定

仕事でマストドンインスタンスを立てることになった。で、設定でちょっとだけはまったので履歴を残しておく。

そもそも、マストドンを自分でまったく使っていないので、現在どのくらい流行っているのかはわからない。知人でマストドンを使っているっぽい人も全然いないし、一時の盛り上がりはなんだったんだろう…って思わないでもないけど、そもそもマストドンというSNSの性質が、Twitterとは違ってクラスタ毎にインスタンス内で閉じる傾向が強そうなので、自分の観測範囲内では見えていないだけで、定着している人には定着しているんだろう。きっと。

さて、いざマストドンインスタンスを自分で用意する場合、方針がざっくりと2つある。Dockerを使う方法と、使わない方法だ。マストドン公式では、Dockerを使うインストール方法が説明されている。とは言え、わたしゃ最近自分でサーバを用意して運用するという立ち位置にいなかったこともあって、Dockerを利用してサーバを用立てたことがないし、Dockerの使用はできれば避けたい。ただ、社内インフラにDockerコンテナを自由に作っても良いという環境があったので、まずは勉強がてら、いったんそこでマストドンインスタンスをたててみる。

お世話になったのは、主にこのページ。
qiita.com

やるべきことはそれなりにあるのだけれど、面倒な作業はそれほどなさげである。ただ、Dockerの知識が皆無だったので、そこは必要最低限と思われる知識を入手しつつ作業をすすめる。はまりどころはproxy設定。もちろん社内インフラのネットワークは閉じているので、外部ネットワークと通信するには都度proxyを通す必要があったのだけど、その設定が複数箇所にかわれているので、インストースクリプトの実行→エラー→proxy設定調整→インストースクリプトの実行…みたいなサイクルをひたすらくりかえすことになった。マストドンのインストールだけじゃなく、そもそもyumの実行*1からしてproxyを通す必要がー…みないな。あと、ここではSSL証明書の設定は行わず。Let's Encryptを使いたくても、対象ドメインがローカルネットワーク用のものでインターネット上では正引きができないので、ちょっとどうにもならない感じ。まぁ、インストールの検証用なので、そこは割り切ることにする。

で、とりあえずDockerを使ったマストドン構築自体はなんとかなった。でも、これを本番環境でやるには自分の知識不足もあってかなり心もとない。さてどうしよう…。

そんなあなたにさくらのクラウド。どん!
cloud-news.sakura.ad.jp

いやー、便利便利。サーバ管理の経験が一度でもあれば、マストドンインスタンスを立てるだけならすぐにできちゃう。こちらはそもそもDockerを使わずにマストドンインスタンスを立てる方法なんだけれど、必要なミドルウェアやライブラリのインストールはすべてこのスタートアップスクリプトが実行してくれるので、こちらはさくらのクラウドと契約してドメインを取得するだけでほとんどやることはない。

一応、サーバリソースの上げ下げだったり、マストドンのバージョンアップ方法などを一通り試してみて、サーバ自体のセキュリティ設定も少々いじっておく。あと、さくらのマストドンスクリプトを利用すると、SSLサーバ証明書には自動的にLet's Encryptが導入されるんだけど、今回は一企業として運用するマストドンインスタンスということで、証明書は独自に取得したので、その取得した証明書をサーバに設定した。nginxの設定を自分で触るのもこれが初めてだったりするのだけど、ふーむ、こうなっているのか…。

ここここも参考にしつつ、諸処必要な設定作業は一旦完了。ブラウザでアクセスしてみると無事インスタンスが立ち上がっている。こんなに楽ちんでいいのだろうか!

でも、である。動作検証をしてみると、リモートフォロー機能が正常に働かない。外部のインスタンスのアカウントをリモートフォローしようとすると「リダイレクト先が見つかりませんでした」というエラーになる。逆に外部インスタンスから自分のインスタンスアカウントをフォローしようとしても失敗する。どういうことだってばよ…。

「リダイレクト先が見つかりませんでした」というエラーメッセージを元に、同じような事例がないか探してみると数件だけみつかる。さくらのクラウドを利用したマストドンインスタンスの多さを考えると、同じような状況で悩んでいる人がもっといても良さそうな気もするけど、これだけ情報が少ないということは、自分が設定した何かが良くなかったんだろう。そうなると心当たりも限られてくる。

数少ない情報の中では、このトゥートがちょっとした手がかかりになりそうだ。

どうも、nginxの証明書設定がぁゃしぃ…。今回あえてLet's Encryptを使っていないのだけど、一旦証明書設定をLet's Encryptに戻してみると、なんとリモートフォローが機能しているではないか。そうなると、自分で設定した独自証明書の問題だ。

で、nginxの証明書設定についてもう一度確認してみると、どうやらこういうことらしい。

nginxには、中間証明書を直接指定するディレクティブが用意されていないため、サーバ証明書と中間証明書を結合したものを「ssl_certificate」で指定します。

な、なんだと…。たしかに自分が設定した証明書には、サーバ証明書しか含まれていない。なので、独自に取得したSSL証明書レジストラから中間証明書を入手して、サーバ証明書と中間証明書を結合した証明書ファイルを作成し、改めてnginxに設定すると…。独自証明書でも無事リモートフォローが可能になった!

というわけで、マストドンの設定とはまったく関係なく、単にnginxの知識不足が招いた現象だったことが判明した。中間証明書が未設定の状態でも、WEBブラウザからはSSLなURLにアクセスできていた*2ので、ここにたどり着くまで少々時間がかかってしまった。

こういうこともあることだし、インストールが簡単だからってそれを構成しているシステムについて知らないと、どこかで落とし穴にハマることがあるんだよなぁ…と、改めて自分に言い聞かせたのであった。

*1:CentOS7環境での検証につき

*2:それなりに有名な認証局だったので、すでにブラウザには中間証明書がインストール済みだったんだろうか