外部のネットワークからdekiwikiへアクセスすることも増えてきたのだが、そうなると気になるのが途中経路におけるスニフィングだ。それに対しての最も簡単なソリューションはhttpsアクセスを行うことなので、その設定を行ってみることにした。

方法は、調べてみるとopengarden.orgのHow do I…Provide HTTPS access to Deki Wiki?で説明されていて、今使っている最新のバージョンでは問題なく出来そうな雰囲気で記述してあるため、この内容を見つつ、これまでVirtualHost *:80と書いてあった部分をVirtualHost *:443へ変更を行った。

余談だが、実は社内のサーバは*.example.comというドメインに対しての証明書として作ってあるため、同じドメイン内の違うサブドメインはNameVirtualHostで振り分けることが出来る。ただし社内用なのでオレオレ証明書にならないために鍵は管理者が厳密に管理の上、USBメモリで物理的に渡している。

ついでに全アクセスをhttps化したいので、VirtualHost *:80の設定はmod_rewriteを用いてrewriteルールを記述し、httpアクセスは全てhttpsへ転送するようにした。

が、ここで問題１つめが発生した。dekiwikiは日本語も直接URLに含め、内部ではPATHINFOを用いて文字列処理を行っているようなのだが、コンテンツ名に ? が含まれると文字が途中で分断されてしまう。どうも内部的な処理とApacheの文字処理がおかしいのだと思うが、これをうまく解決する方法を見つけることが出来なかった。「PATHINFO Apache 文字化け」、のようなキーワードで検索すると、Windows環境ではまっている人を何人か見つけることが出来るが、おそらく同種の問題なのだと思う。mod_encodingを使えば解決できるかもしれないと考えたものの、パッケージがメンテナンスされていない雰囲気だった上yumで導入できないこともあり、httpアクセスは全てhttpsでのドキュメントルートへ転送し、もう一度ページを移動してもらうこととした。結果、http向けのVirtualHost設定は下記のようになった。AllowEncodeSlashesを書いておかないとひどいめにあうので注意(ひどいめにあった)。

<VirtualHost *:80>
        ServerName wiki.sensignal.org
        RewriteEngine On
        RewriteCond %{SERVER_PORT} !^443$
        RewriteRule ^/.*$ https://%{HTTP_HOST}/ [L,R,NE]
        AllowEncodedSlashes On
</VirtualHost>

だが、その決定をしておおむねうまく動きそうな中、また次のはまりポイントが出てきた。サイトナビゲーション部分のURLがhttpsにならないのだ。

サイトナビゲーションとは、右画像のような、dekiwiki左端に出ているドキュメントツリーをうまく表示してくれる仕組みなのだが、ここのソースを見ると相対パスではなく絶対パスで表示している。そのせいでリンク先がhttpになってしまい、トップへ転送され続けるという困ったことになってしまっている。

調べること小半日、かなりソースコードを追いかけた(phpからc#の部分からDBの中身までorz)結果、問題はかなり上の方に書いたこの文章「これまでVirtualHost *:80と書いてあった部分をVirtualHost *:443へ変更を行った」というところにあった（がーん）。実はここで書かねばならぬ、SSLEngine On、という１行を書き忘れていたがために、Apacheが80番と同じ挙動をしていたというもの。証明書がブラウザへ送られてきていたので、まんまと引っかかってしまったが、Apacheは443番へのアクセスの場合、証明書を送ってきてくれるものの、HTTP_PORTは80のまま、SSLは稼働せずという非常に中途半端な扱いにしてしまうらしい。そのため、見かけ上はhttps通信が出来ているように見えるものの、URLは全然書き換わらないという悪夢におそわれることになった。

解決したからいいようなものの、思い切り脱力してしまった。