フリーWi-Fiに接続したらサイトに接続できない場合の話

 スマートフォンが普及してからだいぶ経ち、国外からの旅行者向け、観光誘致も込めてまちなかで使用できるフリーWi-Fiもだいぶ普及が進んできました。

おかげで飲食店などに入り、その店内でWi-Fi経由で調べ物をしたりするのにはとても便利だったりします。

しかし、フリーWi-Fiに接続した途端にサイトに接続できなくなることありますよね。あれ鬱陶しいですね。

これは少し仕方がない部分があって、これもまた最近広まっている、常時HTTPS通信によるものが影響してます。

何故繋がらなくなるのか

HTTPSの通信によって通信の内容は暗号化されています。その内容は利用者以外からは読み取れません。また、その通信内容を改ざんすることもできません。

フリーWi-Fiで繋がらなくなるのはこの通信に介入（実質的には一部改竄）し、Wi-Fiの事前認証情報にログインしていない場合はログイン画面に移動させようとします。
また認証されていない場合、ログイン画面と、一部の許可されたサイト（例えば店舗のウェブサイトなど）以外は通信を制限するようにしています。

この機能はフリーWi-Fiのルーターの機能によるもので、これをキャプティブポータル（Captive Portal）といいます。

そのためログイン画面に遷移させることもできず、外部のサイトへの接続も制限された結果、フリーWi-Fiにつないだ途端にウェブサイトにつながらない。という状態が発生します。

Bloggerで独自ドメイン+SSLが使えるようになっていたので設定にした

このブログは元々、blog.anoncom.net という名前でホストし、自分でホストしているVPS上でWordpressを用いて運用していました。

しかし元々アクセス数の少ないブログ＋その他サービスすべてを趣味程度で借りてるVPS1台で運用するには少々厳しくなってきたので、ブログだけを他のVPSに移し、Wordpress+Kusanagiで運用してみたりもしましたが、やはり管理が厳しい。

と諦めて、外部ブログホストサービスとして現在のBloggerに移ったが、当時、こちらではSSL通信を利用するには独自ドメインでの運用はできなかった。
現在自分のサイトのセキュリティ設定を高める（そんな必要性のないサイトだが技術検証も兼ねて）ためHSTSにより、anoncom.net およびドメイン配下のサブドメインではすべてSSL接続を強制するように設定しており、 blog.anoncom.net を利用する以上、SSL接続を避けることはできない。

そこで、しばらくは Bloggerデフォルトのドメイン（anon5r.blogspot.com）上でSSL接続を設定して運用してきた。

しかし昨今、Let's Encrypt でもワイルドカード証明書の発行ができるようになるなど、ブログホストサービスでも気軽にSSL証明書が利用できるようになったので、Bloggerでもそろそろ対応するだろう……と思っていたところ、ググってみると今年(2018年)からできるようになっていたようだった。

詳しい設定方法は公式のヘルプ、または他のブログ記事などで既に書かれているのでそちらを参考にするとして、この場合どのような証明書が発行されるかについて、軽く書く。

Let's Encryptがワイルドカード証明書に対応したので早速発行してみる

昨年（2017年）後半頃より、フリーSSLプロジェクトのLet's Encryptで、ワイルドカード証明書の発行対応（特定のドメインやサブドメインに限らず、*.example.com のようなサブドメインへの対応）を宣言していました。
元々の計画では2018年2月下旬を予定されていましたが、品質向上のため直前でリリース延期となっておりました。

それが本日（3月14日、現地時間で3月13日）、ついにリリースされました。

今回、ワイルドカード証明書の対応含め、ACME v2プロトコルにも対応になりました。
ワイルドカード証明書を利用するには、こちらのACME v2プロトコルの利用が必要になります。
また、これまでは証明書発行ドメインが向いているサーバ内に、認証サーバから接続し、それによって証明書発行時の所有者確認が行われていましたが、ワイルドカード証明書の取得にはDNS認証(DNS-01)を利用する形になります。

これまでと同様、コマンドラインからcertbotまたはcertbot-autoコマンドを利用して、証明書を発行するには以下の様にする必要があります。

ACME v2プロトコルを利用し、DNS認証を行うには、--manualオプションと、ACME v2プロトコル利用字のEndpoint （https://acme-v02.api.letsencrypt.org/directory）の設定が必要になります。

サイトをHTTP/2に対応させました

もっと早い段階で進めたかったのですが、前段階のSSLの設定とnginxのコンパイルをミスり続けていてなかなか実現出来ていませんでした。

nginxがHTTP2対応し出したため、早速対応させつつ、昨今のSSL関連セキュリティ事情の設定を見直し、SSLv3の対応を切ったり、暗号化スイートの設定を最適化させたりといったことを行っていたところ、なかなかどうして上手く動いてくれない状態が続いてしまっていました。

で、ようやく動いたこともあってメモ代わりにと。


現在、このブログをはじめ、anoncom.netドメインやその他いくつかの開発・管理サイトは1台の同一VPS環境上で稼働させており、全てnginxで稼働しています。

そのため、全てのドメイン上でそれぞれSSL関連の記述を書くと、それぞれでまた長くなるため、共通化出来るものについては１つにまとめ、includeで読み込むようにしています。
必要があればその時はincludeせずそれぞれのサイトで個別に記述すればいいし。

そんなわけで、各サイトは基本的に下記の様に設定しています。設定は全てnginx用です。


また、SSLで共通化出来る部分については ssl_common.conf という感じのファイルに記述し、これを各サイトの server{~}内で includeさせています。


ここまでの設定の通り、HTTP2対応するにも、SSL（というかTLS)が必要で、そうなると必然的にSSL証明書の準備をしなければなりません。
メインドメインの anoncom.net については先日キャンペーンを行っていたさくらのSSLでRapidSSLを購入して設定しました。
その他のドメインについては、無料で1年間使えるで有名なStartSSLや、以前に最大3年間、100ドメイン分無料で取得出来ると紹介されていた WoSign Free SSLを使ったりをしていました。
またつい最近ではLet's Encryptもようやくはじまり、一部（というか上記で取得しなかった残り分）はそちらを使ったりとして、何だかんだほとんどのページをHTTP2に対応させました。

それぞれの作成方法や設定方法などは既に他のブログなどで紹介されてるのでここでは割愛。

とまぁそんな感じでようやくにしてサイトをHTTP2に対応させることが出来ました。

Google Appsドメインでメール設定を自動化する

どうも、自分でも自分のブログの存在を忘れていたようなブログです。

最近のメーラーはメールアドレス（≒アカウント名）とパスワードを入れるだけで、メールサーバの設定は内部で自動で行ってくれたりするようになったりもしてるのですが、あれの設定どうやるんだろうって去年くらいに調べてました。

もっとも、Google Appsなんかの場合は最近の製品の場合、アカウント設定時にGmailアカウントとして選択することでそのまま設定出来たりするので必要なかったりもするのですが……。
もちろんこれはGoogle Appsなどの製品以外でもこれは応用出来るので、自前のサーバーで他者にアカウント提供する場合でも便利になります。


さて本題ですが、これを実現するには Autodiscover というMicrosoftがMicrosoft Exchangeで実現するために作った規格を使うみたいです。
https://technet.microsoft.com/ja-jp/library/bb124251(v=exchg.150).aspx


設定についてはとても簡単で、HTTPS接続出来る場所に、XMLで記述された設定ファイルを特定のパスに配置するだけです。

設置する設定ファイルは下記のように記述します。

Google Appsを使っている場合はこれをコピーして autodiscover.xml という名前で保存すればOKです。

このファイルを、メールで利用するドメイン名を利用したURLに設置する必要があります。
例えば、 your-name@mail.example.net というアカウントのメールを発行するのであれば、 https://mail.example.net/autodiscover/autodiscover.xml というURLでアクセス出来るようにする必要があります。
もしくは、 https://autodiscover.mail.example.net/autodiscover/autodiscover.xml というように、autodiscover. というサブドメインを設定し、その下に配置すると言うことも可能です。

後者については、例えば your-name@example.com というメールアドレスを利用していて、 https://example.com はサービス用URLであり、ドキュメントルート以降のパスは全てサービスURLとして自由に生成可能な状態としていた場合、 https://example.com/autodiscover というネーム空間を汚染してしまうため、そのような状態を回避することができるようになります。


既に例に挙げているとおり、これらの設定には基本的にはhttpsでアクセス出来るようにする必要がありますので、各自でメールドメイン毎にSSL証明書を用意する必要があります。
（SSL環境をどうしても用意出来ない場合は http://autodiscover.<メールドメイン>/autodiscover/autodiscover.xml のURLでも可能なようです）

StartSSLで1年間無償で使えるSSL証明書を取得するのもいいですし、DNSにCloud Flareを使っている場合、HTTPリクエスト時にCloud Flareを通過する設定にしていればSSL機能を無償で提供してくれますので、それで代替も出来ます。

また、最近はLet's EncryptプロジェクトでSSL証明書を無償で発行することも可能ですので、それらを利用してみるのもいいでしょう。


今回はGoogle Appsの設定をするものとして記述しましたが、冒頭でも触れていたとおり、autodiscoverは自前のサーバ設定にも有効です。 autodiscover.xml の<Protocol>内の各項目をそれぞれの環境に添った設定にしておけば
それが反映されます。


また、DNSのSRVレコードを設定出来る環境の場合、ゾーンファイルに下記の様にSRVレコードを設定することで、その設定を検出させることも可能なようです。

_imap._tcp 300 IN SRV 0   1 993 imap.gmail.com.
_pop._tcp 300 IN SRV 0   1 995 pop.gmail.com.
_smtp._tcp 300 IN SRV 0   1 465 smtp.gmail.com.
;;_autodiscover._tcp 300 IN SRV 0   0 443 autodiscover.example.com.