Posts for the month of March 2013

さくらのVPSでIPv6 (6rd)

まえがき

とあるサーバをアップグレードしたいと思い、 さくらのVPS(v3) SSD 1G IK01 を仮契約してしまいました。レビューについてはまた後ほど書きたいと思います。

ほんだい

さて、さくらインターネットでは6rdを用いて、サーバにグローバルIPv6アドレスを割り当てる実験を行なっており、VPSや専用サーバなどエンドユーザがroot権限を持っているサーバならば使用できます。

なにした

さくらインターネットのサイトに​6rd設定方法は載っているので詳しいセットアップ方法は割愛します。
IPアドレスの打ち間違いに気をつけましょう。それでしばらく行き詰っていました。

どうなった

つながったかどうかを判定するのに、一旦サーバにSSHで接続し、そこからわたしがひいきにしている​筑波大学 WORD編集部のサイトをwgetしてみました。

コマンドおよび出力: 

[email protected]:~$ wget -O /dev/null -6 www.word-ac.net
--2013-03-16 07:10:54--  http://www.word-ac.net/
Resolving www.word-ac.net (www.word-ac.net)... 2001:200:0:7c06:0:ac:3c:212
Connecting to www.word-ac.net (www.word-ac.net)|2001:200:0:7c06:0:ac:3c:212|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `/dev/null'

    [ <=>                                   ] 40,059       246K/s   in 0.2s    

2013-03-16 07:10:55 (246 KB/s) - `/dev/null' saved [40059]

そして、ローカルから新サーバにping: 

[~]$ ping6 2001:e41:123:abcd::1341:398                   ch[email protected] 07:20:37
PING 2001:e41:123:abcd::1341:398(2001:e41:123:abcd::1341:398) 56 data bytes
64 bytes from 2001:e41:123:abcd::1341:398: icmp_seq=1 ttl=57 time=44.5 ms
64 bytes from 2001:e41:123:abcd::1341:398: icmp_seq=2 ttl=57 time=25.9 ms
64 bytes from 2001:e41:123:abcd::1341:398: icmp_seq=3 ttl=57 time=26.0 ms
^C
--- 2001:e41:123:abcd::1341:398 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 25.944/32.170/44.530/8.741 ms

なんかへんだ

時々pingが通らなくなることがあるのですが、実験サービスなので安定性についてはしょうがないですね。 pingが通らなくなっても、サーバからのIPv6接続は問題なく行えます。しかもサーバからどこかへIPv6接続したあとこのサーバへpingするとしばらくの間は通るので、不思議です。

どうでもいいこと

  • さくらインターネットの6rdでは、/64のIPv6アドレスブロックがもらえるので、末尾64ビット (数字で言って16桁) は自由に決められます。某メイド長にちなんで ::1341:398 とかやってみたり。
  • WORD編集部のサイトのIPv6対応は、日本で30番目だそうです。

よんだ

​6rd - Wikipedia
​VPS（仮想専用サーバ）のさくらインターネット
​6rd設定方法（Ubuntu10.10編）
​さくらのVPSの Ubuntu 12.04 環境で IPv6 アドレスを使う

SSL中間証明書を改良してAndroidに対応させた

およそ3週間の間多忙で何もアウトプットできていなかったくりすです。

nginxのSSL証明書をAndroid上で信頼されないという報告を受けていたのですが、先程対応が完了したのでシェア。

問題

このnginx上では​RapidSSLを採用しており、その親ベンダは​GeoTrust, Inc.であるわけですが、この両者の中間証明書をインストールしないと、一部の端末では証明書が正しく使用できませんでした。

原因

2010年頃からRSA (1024bit) は暗号強度上の理由から廃止されており、それに伴い諸CA証明書も2048bitに順次入れ替わっております。しかし、これに伴い互換性確保のために中間証明書のインストールが必須となるので、これを正しく設置していない場合SSLエラーが発生するわけです。

気を付けないといけないのは、RapidSSLの場合はRapidSSLの中間証明書と、その上位のGeoTrustの中間証明書の両方が必要であるということです。

対策

  1. RapidSSL, およびGeoTrustの中間証明書をそれぞれ入手します。
    参考文献の3番目のテキストファイルは、この2つの証明書がバンドルになったものなので、それを引っ張ってくればよいでしょう。 
    $ wget https://knowledge.rapidssl.com/library/VERISIGN/INTERNATIONAL_AFFILIATES/RapidSSL/AR1548/RapidSSLCABundle.txt

  1. 自分のサーバ用の証明書とこれらを連結します。 
    # cat /path/to/the/downloaded/RapidSSLCABundle.txt >> /path/to/your/ssl/cert.pem
  1. nginxを再起動します。 
    # service nginx restart

これだけの手間でしたが、Android 4.0.3で正常に読み込まれたことを確認しましたので、一安心。

NISTの文書によると、今年の末までに1024bitのRSAは廃止され、2048bitに移行するものとされています。

参考文献