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
  • DNS-01

HTTP-01およびTLS-SNI-01はPort80または443での認証を行います。
具体的には、LEが指定するディレクトリにアクセストークンファイルを設置しに来ます。
対象ドメインの指定の場所にファイルを置くことができ、LEがそのファイルに対してhttpアクセスできれば
認証が通ったことになります。

これは非常に便利でWebサーバーの設定をしておけば
発行と更新は勝手にやってくれます。

ただこの認証方式のデメリットは、
Port80または443を外部に全開放しなければならない
ということです。

本番公開しているサーバーにだったらこれでもいいんですが
開発環境や管理ツールなど外部に公開したくない環境では使いづらいです。

そのため「DNS-01」認証を使用しました。

最後に

ということで資料の補足でした。
LEをどう運用していこうか悩まれている方の参考になれば幸いです。

楽天テックカンファでLTをするという貴重な機会をいただいたのでよかったです。(自分から応募したけど笑)
またLT全体としても、とても多岐にわたる発表内容で勉強になりました!
来年もあれば参加したいな~と思ってます(`・ω・´)

では!