Rakuten Technology Conference 2017でLet's Encryptの事例を発表してきた
楽天さんが開催された
「Rakuten Technology Conference 2017」でLTしてきました！
発表内容
5分間のLTということもあり、かなり駆け足で発表してしまったので
捕捉しつつ内容について説明していこうと思います。
証明書の発行の仕方（例）について
certbot コマンドを使用した例を出してます。
今回の発表ではDNS-01認証を選択していますが、
このcertbotでのDNS-01認証はアクセストークン（チャレンジレコード）の
TXTレコード登録はサポートしてないので、その辺を自動化したい場合は、
発表中に出てくる「lego」などを使用しましょう。
legoについては下記記事で紹介してます。
Let's EncryptのDNS認証による証明書発行/更新の自動化をやってみた https://blog.haramishio.xyz/post/000002/>
アーキテクチャについて
証明書の発行は、Jenkinsを使用しています。
ここはなんでもいいと思いますが、SANsを使用して何十個もドメインを含めた場合、
証明書の新規発行に30分以上は確実にかかります。
時間制約があるAWS Lambdaなどでは実施しづらいので注意してください。
また図中の右側はプロジェクト単位ごとに存在します。
つまりプロジェクトにつき1つの証明書を発行するようにしてます。
プロジェクトではsand環境やstaging環境などあると思いますが、
すべて同じ証明書を参照するようにしてます。
この方法だと1プロジェクトにつき100ドメインしか指定できませんが、
そんな数のドキュメントを1プロジェクトで使うこともないだろうというのと
100を超えてももう1個証明書を発行すればいいだけなので特に問題にはなりません。
実装について
LEクライアントは上記に書いた「lego」を使ってます。
legoを選択した理由は、Route53に対してアクセストークンの書き込みを自動で行ってくれるからです。
もちろんRoute53に対する捜査権限が必要ですが。
またLEの認証方式は現時点で以下の3つが使えます。
HTTP-01およびTLS-SNI-01はPort80または443での認証を行います。
具体的には、LEが指定するディレクトリにアクセストークンファイルを設置しに来ます。
対象ドメインの指定の場所にファイルを置くことができ、LEがそのファイルに対してhttpアクセスできれば
認証が通ったことになります。
これは非常に便利でWebサーバーの設定をしておけば
発行と更新は勝手にやってくれます。
ただこの認証方式のデメリットは、
Port80または443を外部に全開放しなければならない
ということです。
本番公開しているサーバーにだったらこれでもいいんですが
開発環境や管理ツールなど外部に公開したくない環境では使いづらいです。
そのため「DNS-01」認証を使用しました。
最後に
ということで資料の補足でした。
LEをどう運用していこうか悩まれている方の参考になれば幸いです。
楽天テックカンファでLTをするという貴重な機会をいただいたのでよかったです。（自分から応募したけど笑）
またLT全体としても、とても多岐にわたる発表内容で勉強になりました！
来年もあれば参加したいな～と思ってます(｀・ω・´)
では！
