IHANet RPKI ROOT CAの構築

RPKIとは資源割り当てを証明するPKIで、使われ方としては、今のところはBGPでの経路のOriginASが正しいものかの証明に使われ始めているっぽい。

RPKIのPKIとしての構造は、RIRやNIR(JPNICだけ?)がCAを持ってて、全部を束ねるROOT CAは無い。なので、トラストアンカーは各RIRとかNIRのCAのものを入れる形になる。各RIRとかNIRのCAはその組織が管理しているIPアドレスとAS番号を管理してるぜ!というCA証明書を持ってて、さらにその下の組織(ISP)とかのCAに対して署名している。ISPとかのCAは経路情報のデータ(ROA)に対して署名をしている。
みたいな構造になっている。。。

これらをルータがとってくるのではなく、間にキャッシュサーバというサーバがいる。ROAや証明書などが置かれているのはレポジトリと言って、rsyncで根こそぎとってくる漢らしいプロトコルである。順番から言うと、トラストアンカーに記載してあるURIに対して、rsyncを行なうそのディレクトリ内にある子どもの証明書にあるURIにrsyncを行って。。以下繰り返しをやることで再起的にファイルをとってくるしくみ。そのあと、キャッシュサーバ内で検証までして、最終的にはrpki-rtrプロトコルを使って、BGPルータとやりとりする感じです。

BGPといえばIHANetということで、IHANetでも2年ほど前からRPKIをやろうとしてたんだけど、caの立て方は比較的わかりやすいのですが、rootの立て方がわからず、、、頓挫していたのですが、最近やる気がでてきたので一気に立ててしまいました。

立て方はhttp://rpki.net/wiki/doc/RPKI/Installation/FromSourceを参考にしました。

ここに書いてある、必要なパッケージをインストールしたあと、MySQLは起動している状態にし、
rsyncdの設定も追加しておきます。

rsyncd.conf例

./configure && make && make installでインストールしてしまいます。

ROOTDは普通は動かないようになっているので、rpki.confを書き換えます。
主に書き換えたのは下記の通り

次に、rootの鍵と証明書の作成をしました。まずはconfファイルを作ります。

IHANET用なんで、リソース全部指定してます。。次に鍵の作成と証明書の作成をします。

できた鍵と証明書をインストールします。

次にデーモンを立ち上げます。

立ち上がったら、ROOTレポジトリの設定をします。
今回は

と設定したので、ihanetを作ります。

次にWEBUIの設定をします。WEBUIからROAの発行ができます。多分普通に触る人はこの画面経由になるはず。
今回の設定は下の通り。WSGIScript動かすってだけです。なおドメイン名は専用に用意しましょう。

ユーザ用のhandleとWEBユーザを作ります。
ユーザ用のhandleは

webユーザの作成は、はじめにsuperuserを作ります。

このユーザでWEBGUIにアクセするするとユーザ作成ができます。その時にhandleとして先ほど作ったものを指定します。

次に子にprefixやASを委譲します。下記のようなファイルを作ります。

asn.txt

ip.txt

これで、委譲完了しているはずです。

WEB-UIからROAの発行ができるようになっています。

あとは、rpki-rtrサーバなrcynicの立ち上げです。
この辺を見ればなんとなく設定できます。
https://www.nic.ad.jp/ja/rpki/howto-setuproacache.html

なお、設定ファイルは下記のようかかんじです。

Let’s Encrypt betaに参加してみた

巷で話題のLet’s EncryptのベータのInviteが来たのでやってみた。

Invite mailに記載してある通り、githubからプログラム一式を発行するドメイン名のAレコードが向いてるサーバに持ってくる。

git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt

このあと、mailにあるQuick Startだと下のコマンドを打つと、良しなにやってくれると書いてある。

これを実行すると、必要なモジュールをダウンロードして、実行可能な環境を整えてくれたのち、
メールアドレスの入力画面が出る。
letsencrypt−mail
証明書を発行するドメイン名の入力をして
02domain
コケました。
03fail
どうもWEBサーバが立っていると、letsencrypt-autoが80番をlistenできないのでダメな模様。
Apache落とせってか。。。。
ドメイン名認証の部分を、HTTPで認証用のファイルが取れるかどうかで判定してるっぽい。

マニュアル見ると、–webroot, –webroot-pathなるオプションがあるので、今回はこっちでやってみます。
今回はusagi.cafeというドメイン名のDocumentRootのパスを設定してます。

04
Webroot Authenticator (webroot)を選択してEnterすると

どうやら証明書ができたようです。
/etc/letsencrypt/live/usagi.cafe/
ディレクトリを見ると4つのファイルができてました。

ちなみに、一番最新のファイルへのリンクが/etc/letsencrypt/live/$DOMAINに置かれるようなので、
WEBサーバの設定もこのパスを指定するのが良さげです。

cert.pemは発行された証明書でRSA2048bit,ハッシュアルゴリズムはSha256と今時なRSAですね
subjectはドメイン認証しかしてないのでCNだけです。

chain.pemは中間証明書が入ってます。

cert.pemとchain.pemをセットにしたのがfullchain.pemです。
最後privkey.pemは暗号化なしの状態でした。

とりあえず、証明書はできたのですが、この証明書の期間が90日しかありません。
というのも、letsencrypt-autoを使って自動更新するという流儀のようです。。

というので、コマンドhelpみて作ったのがこれです。

こんな感じのをcronに登録して、その都度graceful掛ければよさげです。

最後にTLSAレコード突っ込んで終わり。。

MacOS/IOS のVPN用の構成プロファイル

構成プロファイルを作る機会があったので、テンプレートを上げます。

 

.jprs

http://nic.jprs/

NSは全部で3つ
tld1.nic.jprsはAS7500 (JPRS)
tld2.nic.jprsはAS2914 (NTTComで、JPRS割り当て、専用線かなにか)
tld3.nic.jprsはAS12041(Afilias Canada)

ちなみに65.22/16がAfiliasで、tld3.nic.jprsと同じ/24の中には
tld3.nic.nttもある。

というか、tld1.nic.ntt,tld2.nic.nttもJPRSのお隣のアドレスなので、
多分これはNTTからの受託案件なんだろう。

[root@ns wordpress]# dig @m.root-servers.net jprs ns +norec

; <<>> DiG 9.9.4-RedHat-9.9.4-18.el7_1.1 <<>> @m.root-servers.net jprs ns +norec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER< ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;jprs. IN NS

;; AUTHORITY SECTION:
jprs. 172800 IN NS tld2.nic.jprs.
jprs. 172800 IN NS tld3.nic.jprs.
jprs. 172800 IN NS tld1.nic.jprs.

;; ADDITIONAL SECTION:
tld1.nic.jprs. 172800 IN A 103.47.2.1
tld2.nic.jprs. 172800 IN A 117.104.133.16
tld3.nic.jprs. 172800 IN A 65.22.40.1
tld1.nic.jprs. 172800 IN AAAA 2001:dda::1
tld2.nic.jprs. 172800 IN AAAA 2001:218:3001::1
tld3.nic.jprs. 172800 IN AAAA 2a01:8840:1ba::1

;; Query time: 16 msec
;; SERVER: 2001:dc3::35#53(2001:dc3::35)
;; WHEN: 土 7月 11 00:15:11 JST 2015
;; MSG SIZE rcvd: 226