Let's Encryptの画期性：無料よりも自動更新
今回は、Let′s Encryptについて話をしていきたいんですけど、 Let′s Encryptといえば証明書の発行サービスかなと思うんですが、
すごいざっくりとしたイメージで、無料で発行できてすごい便利だなって印象があるんですが、 他にも他の点で便利だったりとか、特筆すべきところとかってあったりしますかね。
そうですね、無料なのはそうなんですけど、それよりもAPIで証明書を自動更新できるようにして、 かつ有効期限も従来より短くしたっていうところの方が、
実は無料であることよりも画期的だったりします。 自動更新ができるようにしたっていうところが画期的だったというところなんですね。
そのAPIを実装したのがLet′s Encryptだったっていう感じ。 そうですね、Let′sEncrypt自身がアクミプロトコルっていうプロトコルを開発して、
それで実際に自動更新できるようにしたっていうところで、 それまでだと、やっぱりその証明書をどっかの会社のサイト行ってポチポチやって発行するっていうのが一般的だったんですけど、
Let′s Encryptはもうそういうポチポチやるんじゃなくて、 自動で、そういうシステムでちゃんと自動更新する仕組みにしてくださいっていうふうにしたんですよね。
そこが画期的だったというところなんですね、アクミプロトコル。
それが新しかったですね。
ちなみにそれまでの手動でポチポチしていって、 1年に1回、ないしは多分もうちょっと長かったのかなと思うんですけど、2年とか、証明書の有効期限ですね。
の時は特にこういうこのアクミプロトコルが出てくる前は、 そういう自動化みたいな話ってなかったんですかね。
自分も把握している限りはなかったですね。
ほうほうほう。
じゃあもう本当に、その時まではアクミプロトコルが出てきて、 Let′s EncryptがそういうAPI、自動更新のAPIを出すまでは、
証明書の切り替えっていうのは手動でやるのが普通だよね、 みたいないう世界観だったんですね。
そういう世界観でしたね。
やっぱりそれより前だと3年とか5年の証明書とかもあって、 そんなに頻繁に発生する作業じゃなかったんですよね。
たぶんちょっとずつ厳しくなっていて、 Let′s Encryptが出たぐらいは確か1年ぐらいになっていて、
やっぱりそろそろちょっと煩わしいよねってなってきたっていうのが たぶんその頃だったかなと思いますね。
なるほど。だんだん需要が高まってきた中で Let′s Encryptが出してきたっていうところなんですね。
そうですね。
ACMEチャレンジ：ドメイン所有権の証明方法
ちなみにこれ実際このアクミプロトコル、 片杉さんも自分のVPSとかで使ってるのかなと思うんですけど、
めっちゃ使ってます。
使う側からしたらどうやって使ってるんですかね、 具体的なところとして。
これがね、まずそのドメインを誰が持ってるのか っていうことを証明しないといけないじゃないですか。
そのドメインを保持してるかどうか。
自分がこのドメインを保持してますよってことを Let′s Encrypt側に証明しないといけないじゃないですか。
そうですね。証明書の場合は普通そうですよね。
持ってるっていうことを証明して、 証明書を発行してもらうみたいな感じですもんね。
そうしないとインシデントになっちゃうんで、 当たり前なんですけど。
なのでこのアクミチャレンジって呼ばれてるんですけど、
そのLet′s Encryptにこのドメイン持ってます、 自分持ってますよってことを証明するって必要があります。
基本的にチャレンジ、多分一番有名なのが HTTPチャレンジって呼ばれているやつだと思っていて、
これはウェブサーバー上で .wellknown.acmechallengeっていうファイルを置いて、
そこでトークンみたいなのを置いといて、
このトークン持ってるんで、 このドメインの所有者ですよみたいなことを証明していく。
っていうのが多分一番有名というか、 一番使われてるんじゃないかなとは思います、これが。
なんですけど、実は自分はあんまり使ってなくて、 このHTTPの方は。
そうなんですか?
なんでかっていうと、一台しかサーバーがなかったら、 別にサーバー上でこのファイル作ればいいんですけど、
例えばサーバーが複数台あったときに、 全部にデプロイしないといけないんですよね。
確かに。どこのサーバーに見に行くか分かんないからですよね。
分かんないから、だから全台にデプロイしないといけないし、 あとやっぱりそのHTTPだとその本番環境が動いてるんですよね。
要はユーザーに影響が出る可能性がある。
変な処理とかしちゃうとユーザーに対して実際に HTTP返してるサーバーに作業しないといけないから、
なんか影響が出る可能性があるんですよ。
あとそのHTTPを最初に始めるときに、
TLS証明書がない状態で始まるから絶対エラーになっちゃうんですよね。
一番最初は。
で実際結構世の中のサービスってこういうサービス多くて、
独自ドメインでブログサービスとか運営できますよって サービスいくつかあると思うんですけど、
大抵の場合HTTPチャレンジで社務者発行してるから、
まず最初はTLS証明書がない状態でスタートして、
しばらくエラー返ってくるんだけど、
レッツエンクリプトで証明書発行が成功したら、
TLS HTTPSで通信できるようになる。
みたいなサイトが多いですね。
なるほど。
そういうエラーってここから来てるんですね。
エラーってどういうことですか?
ウェブサイトでまだ一番最初TLSじゃなくて、
エラーになってしまうみたいな、
証明書まだ発行してないよというような状態のエラーなんですね。
そうなっちゃうんですよ。
HTTPでやっちゃうとどうしても。
そこがちょっと欠点かなと思ってます。
で他の方法もあって、
自分が普段使ってるのはこのDNSのチャレンジですね。
DNSの方は、
Underbar Acme Challengeというドット、
今回証明書発行したいドメイン名のテキストレコードに、
トークみたいなのを設定しておく。
そうすると、
このドメインのDNS変更できるんだったら、
この人はドメインの所有者だよねっていう風にやってくれる。
これのメリットとして、
なんで自分がこれを使うかっていうと、
本番のNginxとかHTTPサーバーが動いてるところは触らなくてよくて、
そのDNSのサービスだけ触ればいい。
DNSのサービスも、
API使えるところと使えないところがあるんで、
API使えるところじゃないと基本的には使えないんですけど、
自分はそのAWSのroot53使ってて、
そのAPI使えるから、
APIでDNSを書き換えることで、
その証明書を発行できるっていう風にできる。
なるほど。
このテキストレコードのバリューの部分ですかね、
に当たるチャレンジトークンって言うんですかね。
何て言うのかわからないですけど。
何て言うか自分も把握しないですけど、
トークンみたいなのを送りますね。
そのトークンを毎回書き換えてってことですよね。
そうです。証明書を発行するために書き換えてやってます。
ワイルドカード証明書もレッツエンクリと、
昔はできなかったんですけど、
今のレッツエンクリとはワイルドカード証明書を発行できるんですけど、
ワイルドカード証明書を発行したい場合は、
このDNSのほうを使わないと発行できないです。
なるほど。
このHTTPとDNSのほうと、
あと他にもあったりするんですかね、方法として。
実はもう一個だけあります。
ただあんまり使っている人はほとんどいないと思います。
ただせっかくなんで今回紹介すると、
TLSのALPNを使うチャレンジで、
以前HTTP2の話をしたときに、
ALPNはTLSの拡張で、
そのHTTP2が使えるよっていう情報を
平文で入れてくるっていう話をしたと思うんですけど、
そこを使います。
なるほど。
これのメリットとしては、さっき言った
エンジンXとかそのHTTPが動いているところを
維持しないといけないって話をしたじゃないですか、HTTPチャレンジでは。
TLS ALPNはそのTLSレイヤーなので、
基本的にはそのCDN側で
割と勝手にやれるところ。
ユーザーのHTTPサーバーを触らなくてよい。
ウェブサーバーとも違うし、
DNSとも違うし、
もう一個の外部サーバーみたいな形ですよね。
外部サーバーというか、これ基本的に
CDNとかが使う想定のやつで、
DNSってだいたいCDN事業者が持ってないことも多いし、
HTTPのレスポンスを勝手に書き換えちゃうと、
ユーザーとトラブルになる可能性が高いですよね。
けどTLSのALPNは
CDNが勝手に書き換えても、
特にユーザーからのクレームが来なそうじゃないですか。
そのCDN事業者だと、
そのTLSレイヤーが直接触れるので、
そこでやればユーザーに対して迷惑かけずに
できるよね、というところで
TLSのALPNを使うという方法もあるんですけど、
これこそってTLSの実装を維持しないといけないので、
一般的なアプリケーションエンジニアが
触れる領域じゃないんですよね。
まあそうですね。
エンジンXのモジュールでこれができるモジュールっていうのは
確か作ってる人いるんですけど、
我々がやるとすると、エンジンXでそのモジュールを入れてコンパイルして、
頑張って設定すれば使えるかなみたいな、
ちょっと自分使ったことないんだけど、
みたいな感じなんで、結構ね、我々みたいな
Webのエンジニアが使うのはかなりハードルが高いけど、
CDN事業者とかは使うと便利っていう感じなんですよね。
このTLSの方を使う利点としては、
CDNの方で勝手に
設定ができるっていう利点があるのかなと思うんですけど、
そういう大規模ホスティング向けみたいな感じの
機能なんですかね。
そうですね。それは確かドキュメントに明記されてて、
TLSのALPNで使うやつは基本的にはCDN事業者とか
大規模のホスティング事業者向けで、一般ユーザー向けではありませんよ
みたいなことがちゃんと書いてある。
なので我々が使うとしたらHTTPの方かDNSかどっちか
だと思ってもらって大丈夫です。
なるほど。具体的に言うとクラウドフレイヤーとかが
対応してたりするんですかね。
どこが使ってるかちょっと自分は知らないんだけど、
使うとしたらそういうCDNの会社が使う想定で
作られた機能って感じですね。
自分たちみたいなウェブサーバー、ウェブアプリケーションとか
触ってるような開発者からしたら、基本的にはDNSではなくて
DNSを使っていくっていう感じで
自動更新していくって感じなんですね。
で言うとやっぱりさっき言った通りHTTPの方が
実際には多分使われてると思います。
そうなんですね。
自分はDNSばっかり使うんだけど、
実際にはHTTP使ってる人の方が圧倒的に多いかなって思ってます。
でもさっき言った
一台だけのサーバー、複数台のサーバーがある場合は
基本無理ですよね。
無理ではないですね。ちゃんとデプロイすればいいって感じですね。
全てのデプロイサーバーに
全部デプロイしていくみたいな。
全てのサーバーにデプロイしてからチャレンジすればいいっていう。
ちなみにそのチャレンジってのが
分かってなかったんですけど
明示的にチャレンジAPIをコールするみたいな感じなんですか?
そんな感じですね。明示的に呼んで
で、絶縁クリストからリクエスト来て
大丈夫そうってなる。一応2回やるんですけど
1回やって大丈夫そうだったらもう1回やってくださいってなって
もう1回やって大丈夫だったら発行してくれるって感じになります。
なるほど。
このアクミプロトコルのチャレンジに関しては
アクミプロトコルのチャレンジに関しては
結構分かってきたかなと思うんですけど
このアクミプロトコルで他のチャレンジ以外のやつとか
あったりするんですかね?
ドメインの所有者であることを証明しないといけないので
そのアクミチャレンジは必須ですね。
その使えるのが今回紹介した3つで
実質的には2つって感じですね。
なるほど。
証明書クライアントツールの変遷とDNS運用
それでドメインの保有が確定するわけじゃないですか
このチャレンジで。
その後の処理があるんですかね?
それが終わったら基本的には発行してくれますね。
発行されるので発行されたものをダウンロードして
設置してみたいな感じになるっていう。
基本的にはダウンロードも自動で
CLIツールとかいくつか出てるんで
その手の使えばダウンロードとかも自動でやってくれるんで
そのチャレンジが通れば証明書が手に入るって感じになります。
Let's Encryptで
CLI使って証明書のダウンロードだったりとか
更新だったりするって話なんですけど
CLIに関してはSATBotっていう
Let's Encryptの公式ツールがあって
それ使ってるっていうような感じなんですかね?
一応公式だと思うんですけど
自分は使ってないですね。
SATBotは確かPython製なんですよ。
依存がめっちゃ多くて
依存全部入れないと動かないんで
結構動かすのめんどくさいんですよね。
自分は使ってなくて
昔はDehydratedってやつを使ってたんですけど
最近はLegoってやつを使っていて
こっちの方が個人的には便利だなって思ってます。
今はLegoっていうものを使っている?
そうですね。これが合成号で書かれていて
自分が普段やってるDNSチャレンジが
すごいやりやすくて
root53とかのDNSプロバイダーの
APIを自分で叩く機能があるので
LegoにそのAWSのクレデンシャルとかを
出せれば
全部root53自分で書き換えて
もう全部自前でやってくれるっていうのがLegoですね。
めちゃくちゃ便利ですね。
自分みたいにDNSでやってる人はすごい便利。
そういうのができるのも
アクミプロトコルが公開な仕様だから
みたいな感じなんですかね。
そうですね。アクミプロトコルは誰でも実装していいんで
公開されてるし誰でも実装していいんで
こういうクライアント結構たくさんあるんですよ。
Legoとかその前に使っていた
Dehydratedですね。
Dehydratedは
シェリースクリプト製で
フックスクリプトみたいなの設定できて
そこで自分だったら
root53のAPIと
シェリーアイツールで叩いて
このタイミングでこのトークンを更新してください
みたいな設定しておいて
みたいなのを昔やってたんですけど
この後たぶん話すんですけど
Let's Encryptの使用をいくつか使えない使用がDehydratedあったんで
Legoに移ったって感じですね。
なるほど。Legoの方だったらそういうフックで
自分で頑張ってシェリースクリプト書かなくても
Legoの方がサポートしてくれてるって感じなんですね。
そうですね。root53だったらLego自体がサポートしてるんで
シェリースクリプトとか書かなくても全部やってくれますね。
それはめちゃくちゃ便利ですね。
そうめちゃ便利です。
そういった形で証明書の更新をしているって話なんですけど
実際に証明書をダウンロードして配置して
更新完了みたいな感じじゃないですか。
実際に
証明書更新時のサーバーリロードと運用上の課題
サーバーのリスタートみたいなのが挟まるのかなと思うんですけど
Nginx使えば
ホットリロードみたいなことができるっていう感じなんですかね。
それでいうと
普通の機能を使った場合はNginxだとリロードしないと
証明書は更新されないですね。
なのでリロードは必要って感じです。
なるほど。サーバーの再起動は必要って感じじゃないですか。
リスタートはいらないですね。リロードは必要って感じですね。
リロードが必要ってこと。
なるほど。
それでリロードをして証明書の更新をするみたいな。
そうですね。
自分のVPSとかだと
Legoで証明書を作って
その後にまた別のタイミングで
Nginxをリロードしているので
それで新しい証明書が読み込まれて
TLS証明書が新しくなるみたいな感じになってますね。
具体的には
証明書の有効期限をギリギリにやるわけじゃないですもんね。
そうですね。3ヶ月の時は
1ヶ月になったらやってくださいねみたいな
そういう感じの温度感だったかなと思います。
なので大体半分ちょっと過ぎたぐらいになったら
ちゃんとやりましょうみたいな感じですね。
本当にギリギリにやるなよっていう話ですね。
他にレッドエンクリプトがサポートしている
アクミプロトコルで特徴的なところとかあったりするんですかね。
それかここ難しいなみたいなところとかって
あったりするんですかね。運用していく面で。
それでいうと
以前クラウドフレアDNS使ってたんですよ。
クラウドフレアDNSが使用変わって
今どういう仕様かわかんないんだけど
TTLの間クラウドフレア側が
キャッシュ持つようになったんですよ。
別にDNSなんで
そのTTLの間キャッシュするっていうのは
使用違反とかではないと思うんですけど
アクミプロトコルだと困るんですよ。
更新ができないですよね。
アクミプロトコルって2回やるから
1回やって大丈夫だったら
もう1回同じことやってできたらOKだから
1回やってその後にもう1回やろうとしたら
更新できてねえじゃんって言って
コケちゃうんですよね。
直後に2回目をやるから
キャッシュされちゃってるってことですね。
エラーになるって問題があって
すごく難しいですね。
困ったんだけど
当時自分はデハイドレート使ってたんで
シェルスクリプトルもスリープ入れて
TTLが切れるまでスリープ入れるっていう
ちょっと無理矢理な方法で解決したりしましたね。
ちなみにそのTTLは何秒くらいだったんですか?
60秒とか当時でしたからね。
なるほど。
60秒待ってスリープしてでもう1回リクエストしてっていうのを
逆に言えば
デハイドレートは
フックをかけるからそれができたっていう面でもありますよね。
そうですね。
レゴもフックスクリプトを出せた気はするんですけど
自分は今は使ってはないですね。
最悪フックの仕組みを使わないとできない可能性はあるんですけど
ただ今はルート53使ってて
キャッシュの仕組みとかないので
今のところは使わなくても普通に動いてますし
DNSを変更するんだったら
DNSサービスの仕様とかも理解しておかないと
レッツインクリットはうまく使えなかったりするっていうところですね。
確かに
内部で勝手にキャッシュされていて
60秒の間に2回チャレンジされるから
2回目コケちゃって
何か分かんないけどずっと更新されないみたいな
分かりづらくありますね。
ハマりポイントですね。
レッツインクリット自体のハマりポイントではないんだけど
実際に使うにあたって
結構ハマりポイントではあるかなと思ってますね。
難しかったですね。
CAAレコードとCTログ監視：Cloudflare DNSの挙動
今だったら問題ないっていう感じなんですね。
今は自分はルート53使ってるから
そこは困ってないですね。
何か他にあったりするんですかね。
これもレッツインクリットと直接関係あるわけじゃないんだけど
これまたクラウドフィラーの悪口みたいになってしまうんですけど
CAAレコードっていうのがあるんですよ。
CAAレコードって何かっていうと
よくある事件として
TLS証明書を勝手に発行されてしまって
よく分かんない
TLSの発行会社が勝手に発行して
例えばそれこそGoogle.comとかも
実際に発行されたりとかあったんですよ。
それは攻撃的な?
攻撃とかでGoogleが契約してない会社が
勝手にGoogleの証明書を発行しちゃうみたいな
なるほど。
それを防ぎたいっていうので
CAAレコードっていうのを書いておくと
例えばレッツインクリットしかこのドメインは
証明書発行しちゃいけませんよみたいなのが設定できる。
ですよね。CAAレコードっていうのを使うと。
なるほど。認証局を縛れるってことですね。
縛れるっていう。別にレッツインクリット以外にも
指定できるんですよ。もちろん。
そういうCAAレコードっていう機能があって
もちろんレッツインクリットも対応してるというか
これ対応してないとCAAとして認められないので
全部対応してます。
このCAAレコードで自分はレッツインクリットを
しか発行許可しないって設定にしたんですよ。
なのにレッツインクリット以外の証明書も
発行されていることがなんと判明しちゃったんですよ。
なぜ?
これホラーじゃないですか。
無視されている?
無視されているのかなと思って実際にCAAレコードを送ったら
追加されてたんですよ。CAAレコード。
レッツインクリット以外にも入ってきてて
けどクラウドフレアDNSの管理画面見に行っても
レッツインクリットしか書いてないんですよ。
クラウドフレアのDNSレコード一覧に
CAAレコードが出てこないんですね。
出てくるんですよ。出てきてレッツインクリットって書いてあるのに
実際にDNSのリクエスト送ると
設定と違うタイプが入ってくるんですよ。
隠し設定があるということ?
隠し設定があるのかと思っていろいろ調べたら
なんとクラウドフレアはCAAレコードを
設定してもクラウドフレアを使ってたら
勝手にクラウドフレアが使っているCAAを
勝手に追加するっていう仕様らしくて。
しかもこれがやばいのが見えないんですよ。
ダッシュボードには自分が設定した値書いてあるのに
実際にはクラウドフレアが勝手に追加したやつが返ってくるっていう。
実際にDigとかで
見てみると
実際にDigで見たんですけど
身に覚えのない
CAが追加されてるんですよ。CAレコードに。
これちょっとダメですよね。
自分ダメだと思ってるんですけど
これに対して怒ってる人が自分以外にいなくて
みんな困ってないのかな?
みんなそんな深いこと考えてないんじゃないかという気がしているんですが。
それはありつつも
これやられるんだったら他のレコードも書き換えられるよなという
気がしていて。
なんで自分がクラウドフレアDNSからRoot53に移ったかというと
これが理由です。
単純に信頼性がなくなりますよね。
CAレコードを勝手に書き換える会社は
使いたくないなってなってしまって
Root53に移りました。
厳しいですね。初めて知りました。
普通に自分でもクラウドフレアDNS使ってるんですけど
そもそもこういうところを見ないと
気にしないと気づかないところだとは思うんですが
こういう事例1個でも聞いてしまうと
単純に信頼性が損なわれるなと本当に思いますね。
確かに便利ではあって
結局クラウドフレアの機能を使うと思うと
クラウドフレアがテイルス証明書を発行できないと使えないじゃないですか。
それはそう。
CAレコード追加しているせいでクラウドフレアの機能が使えない
のはユーザーにとっては不利益ではあるんですよね。
いやーただ
全部リストでアップされて
ダッシュボード上で見れないっていうのが気持ち悪いですね。
自分が一番嫌だったのはそこですね。
ダッシュボードで自分が設定した値になっているのに
実際の値と違う値が返ってくるっていうのが
自分はかなり嫌でしたね。
気持ち悪い。単純に。
なので
それでクラウドフレアDNSはやめちゃったんですけど
CAレコードっていうのを使うと
レッツエンクリット以外の発行を許可しないっていう設定はできるんですよ。
自分はこれがあったんで
予防策として
CTログの監視を始めたんですよ。
なるほど。
CTログって前も特科の回で話したと思うんだけど
世の中の全てのTLS証明書って
今CTログっていうのに保存してるんですよね。
こういう証明書発行しましたって情報を。
そのCTログを見て自分のドメインのCTログを
具体的に言うとRSSを配信しているサイトがあるんで
そこで自分のスラックでRSSを公読することで
自分のドメインに対して
どういう証明書が発行されているのかっていうのを
CTログで見るようにしたんですよ。この件があって。
それを見ると
自分に身に覚えのないところから
発行されているっていうのが一目瞭然だったので
そういうのをやるようになりました。この件を受けて。
いやー
気持ち悪いですね。
この辺ってクラウドフレアの設計思想なんだと思っていて
例えば
AWS自分は普段結構使うこと多いんですけど
例えばAWSだと
root 53のところポチってやったら勝手に
CDNのクラウドフロントが勝手に立ったりとかしないじゃないですか。
しないですね。
クラウドフレアってDNSの設定いじると
勝手にクラウドフレアのCDN立ったりとか
結構いろいろ勝手に立つんですよ。
いろいろが。
確かに挙動的にいろいろマネージメントしてくれるって感じですよね。
全部いい感じにやってくれる代わりに
すごい統合されてるんですよね。CDNとかDNSが全体的に。
統合されてるし
シンプルにその機能だけじゃないみたいなの。
そんな感じで
DNSいじるとプロクシーみたいなのがデフォルト流行になってて
それは実際にCDN経由になるんですよ。
それがシームレスに全部できる。
けどAWSだと
RUDE50sではDNS以外一切できないし
クラウドフォントはCDNしかやんない。
やりたいんだったら一個一個サービスポチポチやらないといけない。
ここは設計思想が根本的に違うんだろうなとは思ってますね。
確かに今の説明聞いて
そうだなってすっごい納得しましたね。
クラウドフレアはいい感じにマネージメントする
AWSはこの表現が合ってるかどうかは置いといて
クラウドフレアと比べるとユニックス哲学的な感じで
いい感じにシンプルにまとめていく
っていうような思想というか
サービスの考え方の違いがありそうですね。
正直ユニックス哲学ではないと思っていて
個人的には
AWSは単純に縦割りなんだろうなと思っていて
サービスごとに
サービスごとに別会社みたいな組織構造になっていて
Root53はDNSだけをやる
みたいな感じになってるんじゃないかなとは思ってますね。
チームが分かれてるみたいな?
チームは完全に分かれてて多分APIでしか
通信できないから他のチームと
みたいな感じになってるんじゃないかなと
勝手に推測しています。
全てのサービスがマイクロサービスで
ユニックスがつながってるみたいな?
AWSは全部マイクロサービスになってるから
多分そうなってるんじゃないかなとは思ってますね。
作り方も違いみたいな感じですね。
設計手法が全然違うんで
実際便利だと思うんですよね。
クラウドフレアがっつり使うんだったら
絶対便利だと思うんですよ。
自分みたいにDNSだけ使おうとかってなると
何この挙動みたいになることがあるっていうところですね。
なるほど。
完全にロックインされればいいけどっていう感じですね。
それだったらめちゃくちゃ便利だと思いますね。
なるほど。
証明書の有効期限短縮とプロファイル：ショートライブ証明書の挑戦
CTログ監修して便利になったと思いきや
この後もまだ続きがあるんですよ。
なるほど。
どういう困難が待ち受けてるんですかね?
今ってさらに
前もブラウザー会だったかな?
話したと思うんだけど
TLS証明書の有効期限1年よりもっと短くしようってなってて
今多分半年ぐらいなんですよね。
けどこれもまだ緩和措置で
最終的には45日とか1ヶ月プラスアルファぐらいになる予定なんですよ。
最終的に。
レッツエンクリフトは今3ヶ月なんですよ。
レッツエンクリフトもまだ長い状態なんですよね。
45日に比べたら。
レッツエンクリフトも最終的に45日にしたい。
っていうところで
これを短くしたいって話があって
実はプロファイルってやつが選べるようになっていて
レッツエンクリフトって
今デフォルトで使ってるのがクラシックって呼ばれてるやつで
これはまだ有効期限90日なんですけど
TLSサーバーってやつもあって
これちょっと新しい仕組みなんですけど
これはもう既に有効期限45日になってるはずです。
TLSサーバーは先行してやってるんですよ。
短くなってるんですね。
もう一個やわいやつがあって
ショートライブルってやつがあって
TLSサーバーと設定はほとんど一緒なんですけど
唯一違うのが有効期限が
160時間で約6日しかないっていう。
すごいストイックですね。
めちゃくちゃストイックなやつがあって
やっぱりレッツエンクリフトは最先端いきたいみたいなのがあるんですよ。
デフォルトが45日になるんだったら
俺たちはもっと短いのをリリースしなきゃダメなんじゃないかみたいな
のが多分あって6日間っていう
かなり攻めたやつを出しています。
思想が強いな。
この3つが今選べるようになっていて
わざわざプロファイル変えてる人は
自分みたいな人間以外あんまりいないと思うんですけど
プロファイル変えると90日より短いやつが2つ使えるようになっている
っていう状況です。
ちなみにどういう人が変えるんですかね。
TLSサーバーの方が
新しい設定なんで
あと照明書のサイズが
ちょっと小さくなったりするらしいんですよ。TLSサーバーだと。
クラシックより。
ちょっとでも通信量を減らしたいとかだったらTLSサーバーの方が良い
って言われてるんですけど
まあたぶん気分だと思います基本的には。
先にやっときたい人みたいな。
最先端に行きたい人がTLSサーバーとかショートライブドを使うって想定だと思います。
なるほど。
プロファイルっていう機能でこういうのが切り替えられるようになったっていうのが1つ。
重要な点ですね。
これもアクミプロトコルの中に入ってるってことなんですかね。
アクミプロトコルの拡張として
アクミプロファイルっていうのができたんですよ。
なのでさっき言った
OSSのツールも
結局アクミプロファイルに対応してくれないと使えない。
一応
アクミプロファイルについては対応してくれてますね。
レゴもデハイドレデッドも対応してくれてます。
なのでこういうのを使おうとすると
今自分が使ってるツールが対応してるのかっていうのも調べないといけない。
基本はでもあれですよね。
プロファイル指定しないとクラシックに
フォールバックされるからってことですよね。
ほとんどの人はクラシックを使っているはず。
クラシックも近いうちに
45日になります。
クラシックのデフォルトの設定がどんどんTLSサーバーに近づいていくってことですよね。
他にはあったりするんですか?
これで
自分は6日か6日証明書を使いたいなと思って
仕事だと
6日証明書とかって絶対無理だと思ってて
例えば
6日証明書だと
3日後ぐらいに証明書を発行しようとして
発行できませんでした。
システムがエラーを起こしてできませんでしたってなった時に
例えば金曜日の夜だったりしたら
土日って人間が稼働していないじゃないですか。
終わりますね。
土日は2日間かもしれないけど
例えば3連休とかあるわけじゃないですか。
あとは普通にゴールデンウィークとか。
ゴールデンウィークとか長期休暇あるわけじゃないですか。
その時僕が休んでて壊れてるけど
6日証明書が有効期限切れましたとか言われても
困るじゃないですか。
だから6日証明書って自分現実的じゃないと思っていて
これ法人で使えないでしょ現実的にって
正直思ってるんですけど
会社で使えないからこそ
個人の趣味でやってるサーバーでは
使いたいなってのがあって
逆に仕事じゃ絶対できないから
ここでやらないと絶対触んないなと思って
だからあえて自分のサーバーは
ショートライブの6日証明書を使ってるんですよ。
すごい。じゃあもう3日に1回ぐらい更新してるって感じなんですか。
一応公式ドキュメントは確か1日に1回実行してくださいみたいになっていて
一応1日か2日ぐらいにガンガン実行してるはずですね。
ただそうなるとこれ困るのがあって
レッツインクリットってレートリミットが結構厳しいんですよ。
なんでそこレート制限かけちゃうんだろうなっていう気がするんですけど
シンプルに負荷の問題ですね。
なるほど。
サーバー側がレッツインクリットって世界中からとんでもない量
叩かれてるから桁違いに多いんですよ。
証明書発行が他の会社と比べても。
そりゃそうなんですが
6日間の有効期限が切れる証明書が出してるっていうことは
いっぱい叩いてくれっていうことなのかなってなんとなく思っちゃうんですけどね。
一応6日証明書出す前に頑張って負荷対策してレートリミットちょっと増えたはずなんですけど
それでも6日証明書がやばすぎるんで足りないんですよ正直。
事故矛盾に陥ってるんですけど。
そうですね。
なるほど。
なんでこれマジで困ったんですよ。
自分が実際にやったらもうあの実際の証明書を使えなくなって
レートリミットに引っかかってるから証明書発行できなくて
あの証明書を使えなくなったんですよ自分のサーバー。
これなんか試しでAPI叩いてたら普通にレートリミット制限に引っかかったってことですよね。
あの普通にあのもう更新のやつ自動更新する設定にしてたんだけど
なんか気づいたらレートリミットに引っかかっててなんか止まってた。
そんなに低いんですか。
なんかねちょっとちょっと自分のやり方が良くなかったんですけど
止まってたんですよ。
で一応これいろいろ調べた結果まずステージング環境があるんですよレッツエンクリプトには。
ステージング環境は証明書発行されない代わりに叩き放題なんで
まずそのレゴとかなんかそのシェラーツールとか使いたいから
ちょっと挙動確認したいですってなったらステージング環境のURL指定すれば
その本番のレートリミット消化することはない。
いいですね。ちゃんとテストサンドボックス環境が用意されてるってことですね。
あるのでそれは使って大丈夫なんですよ。
っていうのが一つとあとARIっていうやつがあって
あのなんかこれリニューアレッツエンクリプトに対して
あのこれあのリニューあのもう1回再発行するから
再発行予約しとくねみたいなのを登録できるんですよ。
ARIっていう仕様があって。
おーなるほど。あの事前に予約できるんですね。
事前にまた再発行しますよって予約しておくことができて
でこのARIっていうのを使うとそのレートリミット消化しないっていう仕様があって
おー。
でメーカー証明書を使う場合はこのARIを使ってちゃんと予約しとく。
うんうん。
証明書発行する時に次発行するんでって予約しとくっていう。
そうするとレートリミットは消化しないんで
そうやる必要があるってことが運用して分かりました。実際に。
なるほど。ちゃんとあのお作法にのっとって
あのちゃんとドキュメント通りにやりましょうよねっていうことなんですね。
まあドキュメントそんな丁寧なドキュメントあったか
ちょっと自分見つけられてないんだけど
自分が実際に運用した結果
そのステージン環境をちゃんと動作確認で扱うっていうのと
あとARIを使って証明書発行するときはARIを使って
ちゃんと次回の次回発行する時にレートリミット消化しないように
ちゃんと予約しとくっていうことが重要であることが
まあやっぱ実際に運用して分かったんですよ。
そうじゃないと普通に死ぬ。
やらないと分かんないですねこれは実際に
普通に死ぬ。
API叩いて6日間の更新をしないと分からないところですもんね。
そうなんですよ。
で実はこのARI今はちょっと分かんないんだけど
自分が対応したとき
デハイドレーテッドはARIに対応してなかったんですよね。
なるほど予約システムに。
予約できなくて
でLEGOはARIに対応してたんで予約できるって分かって
それでLEGOに移ったんですよそのタイミングで。
なのでその今はちょっと分かんないけど
当時はそのARIに対応してなかったので
ARIに対応したクライアントじゃないと
そのメーカー証明書は現実的に使えないっていう感じでしたね。
なるほどなんか
プロファイルには対応してるけども
その短期証明書のための仕組みにはまだ乗れてなくて
そこの対応ができてないから
実質使えないことになってたみたいな。
そうですね実質使えないんじゃないかな実際にはと思ってますね。
なんかスペック上は満たしてるけど
実運用では耐えられないみたいな
すごい難しい問題ですね。
そうですね実際に運用してこれ無理じゃんってなったって感じですね。
なのでその辺
これ知見です。
メーカー証明書使うんだったらARIに対応してるクライアントを使いましょう
っていうところで
ショートライブ証明書の運用における課題：監視と通知の破綻
他にもメーカー証明書いろいろ問題があって
まず自分もともとなんかサービスに忘れたんですけど
アラート鳴らすようにしてたんですよ
有効期限が切れそうだったらTLS証明書の
ニューレリックとかでアラートが来るみたいな
そういうのあるじゃないですか
例えばよくあるのって30日と14日と7日とかで
例えば30日でなんかウォーニングとかあって
7日だったらもうクリティカルみたいな
のが以前だと割とあるあるぐらいの設定だと思うんですけど
例えば7日前でクリティカルだと
メーカー証明書ってもう常にずっとクリティカルなんですよね
常に真っ赤っかですね
常に真っ赤っかで実際にメーカー証明書にしたら
自分毎日クリティカルのアラートがメールくるようになっちゃって
やばっと思って結局そのサービス使うのやめたんですよ
さっきその証明書切れたのしばらく実は気づかなかったんですけど
なんでかっていうとメーカー証明書でアラートを振っちゃったから
実際切れてるのも気づかなかったっていう
難しい
監視システムの方が対応できてなかったんですね
監視システムがメーカー証明書に対応してないから
メーカーだと常にクリティカルがなっちゃうって問題があって
この辺もやっぱ実際にやったから
いやこれ全然運用追いついてないじゃんみたいなのが分かってきたっていうのはありますね
最先端すぎるんですよね
最先端アプリって色々な問題が起こってて
あともう一個さっきCT録音してたじゃないですか
自分もメーカー証明書で2日に1回ぐらい証明書発行されてるから
毎日のようにCT録投稿されてるんですよスラックで
更新があるってこと
更新が実際あるから
そのスラックがたまに開くとすごい量投稿されてるから見ないんですよね
割れ窓理論みたいな感じ
割れ窓理論になってて結局CT録監視入れたのに多すぎて見れなくなってる
破綻してる
そうだから自分が今までやってきた監視も全部破綻してるんですよね
メーカー証明書にしたことによって
結局メーカー証明書これみんなどうするんだろうなと思いつつ
多分真面目に運用してるのは自分ぐらいしかいないんじゃないか
最近思っていて
自分以外発信してる人あまり見かけないから
マジで自分以外真面目にやってないんじゃないかってちょっと思っている
これ聞いてる人の中でメーカー証明書運用してる人いたら
ぜひコメントとか書いてほしいですね
みんなどうしてるんだろうな
一応今は安定して運用できてます
AIライトに対応したりとかして
今のところ安定してるんですけど
ただちょっと今監視できてないんですよね
そうですね
さっきの話でCT録の監視が機能しなくなってしまってるし
あと期限のやつも
普通にやると常にクリティカルになっちゃうからできてないし
みたいな感じでちょっと割と困ってますね
そのあたりまだできてない
それで言うともしかしたら監視しなくてもいいようにしないといけないってことなんですかね
いやでも監視してないと有効期限切れた時気づけないんですよね
最悪あれですよね
1日前とかには気づきたいけどその手段がないってことですよね
そうですね
なのでこのあたりちょっとどうするのか自分も悩んでいるので
もし解決策してる人いたら教えてほしいんですけど
レッツエンクリプトで最先端の6日勝負書を使うとまだ結構大変ではあります
レッツエンクリプト側から通知こないんですか
昔そういうのあったんですけど今はないはずですね
昔はメール通知の機能あったんですけどもう廃止されてるはずです
それがあったら2日前だけど大丈夫みたいな感じの通知来てくれたらすごい良いんですけどね
昔は来てました
いつの頃からかなくなりました
多分多すぎた証明書が
メール送るのも大変だからやめちゃったんだと思います
いやですよね
しかも6日証明書だと3日に1回送らないといけなくなるみたいな感じになるから
とんでもない量になっちゃうから無理だと思いますよ
じゃあ無理なのではないかという感じですね
6日証明書は
僕は会社で使えって言われたら無理でしょって言いますね
会社でどうやんねんみたいな話はすると思います
なるほど
ちょっと聞いてみたいのが片辻さん的に今だったら有効期限どのぐらいが適切だと思います
証明書有効期限の今後とACMEプロトコルの重要性
現実的に
45日決まってるので結局誰が何を言おうと45日になるんですよそのうち
そこまではね
そこまでは絶対になっちゃうんで
基本的には今だとTLSサーバーを使って45日になるので
Let's Encryptに興味があるんだったら
自分はプロファイルでTLSサーバー指定して
45日にするのが多分一番いいのかなと思っていますね
早めに45日になれておく
6日はさすがにね
ちょっとこれは自分やっててこれ無理じゃないと思ってるんで
やんなくていいと思います
ですね今の話聞いてると現実的には難しそう
現実的にはだいぶ難しいですこれ
ちなみに今45日は既定路線なんですけど
45日よりかもっといくんですかね
2週間とか
多分6日証明書をLet's Encryptが出したのはそれだと思うんですよ
45日より短くできないのか試したいんだと思うんですよ
実験ってことですね
多分実験で6日にしてみんないけるじゃんってなったら
多分6日になっていくかもしれない業界的に
なるほどこれを標準にしていこうみたいなところが出てくるかもしれない
6日でも全然いけるじゃんっていう人が出始めたら多分そうなるんですけど
今のところ僕やってていける気は全然してないです
あれですよねLet's Encryptだけじゃなくて他のサードパーティーだったりとか
あとはツールだったりとかがまだまだ全然追いついてないっていうところが課題点ですよね
6日の証明書は全く追いついてないですね
今後追いついてくる可能性ありますよね
45日についてはLet's Encrypt以外の証明書もなるので
多分追いついてくると思うし
実際悪夢プロトコルも昔はLet's Encryptだけだったと思うんですけど
最近は有名な例えばグローバルサインとか
有名なCAも悪夢プロトコルは結構前から実装してたりするし
やっぱ最近はこの状況で今までなかったけど
今実装してますみたいなところもちょっとずつ増えてきたって聞いてます
なのでそういう45日来るので
みんな今こぞって悪夢プロトコルを実装してるっていうのが今ですね
逆に言うと悪夢プロトコルに対応してないと
短期間証明書の対応ができないってことですよね
短期間じゃなくてシンプルに45日の既定路線の方が対応できない
もう既に半年になっちゃったんで半年ではもう結構きついと思うんですよね
手動更新きついですね
手動更新でやるのはなのでもう自動更新を全てのシステムで自動更新してくださいっていうのがもう既定路線なんですよ
多分それ会社によってはオンプレでまだ手で設定してますみたいな会社だと
そもそもやり方考え直さないといけない時期にもう来てますね
運用を切り替えないといけない時期
そもそも根本的に悪夢プロトコルをセットにしてシステムを更新しないといけない
なんかここら辺あれですよね
AIにこうやっといてみたいな言いづらいところじゃないですかぶっちゃけ
本番環境になるので難しいと思いますね
SSHして入ってやっといてみたいな感じになるかもしれないんですけど
なかなか難しいなとは思ってて
そうですねやっぱ本番環境の権限を渡すって難しいし
あと失敗した時にもう本当にサービス死んじゃうんでここって
大変だと思いますね
なんか本当にもうインフラエンジニアの方が
よしじゃあこうやってちゃんと自動更新にするぞみたいな方針を立てないと
ちょっと更新というか運用の変更っていうのはちょっとしづらいところかなと思いますね
そうですね環境によってはかなり難しいと思いますね
クラウドサービスとかでもう全部自動発行になってますよみたいな会社だったら
そんなに心配することはないと思うんですけど
オンプレでまだその証明書手で発行してるのを配置してるとか
そういう会社はこれからの悪味プロトコルを前提に
どう作り変えていくのかっていう話が出てくると思いますね
でしかもそれが来年とか再来年には確実に来るって感じ
もう来年ぐらいにはなってるんですかね
もう数年ぐらい余裕あった気がするんですけど
ただレッツインクルートについてはどうだったっけ
クラシックはね結構ギリギリまで2028年ぐらいまで
2027年に64日になって2028年に45日になるらしいですクラシックについては
じゃあレッツインクルートでそのぐらいなので他の証明書
認証機関に関してはもうちょっと
もうちょっと余裕あるんじゃないかなちょっとわかんないけど
まあまあまあでも早めに
45日にどこもなるのであんまり余裕はないんじゃないかなと思ってますね
なるほどちょっと結構いい感じの時間になってきたんで
ちょっとまとめていきたいなと思うんですけど
最初の自分の認識だとレッツインクルート
いい感じに無料で証明書を発行してくれるサービスかなとは思ってたんですけど
結構キワキワというかかなり実験的な機能とかも出してるし
そもそも自動更新のプロトコルを実装していったっていう
業界のパイオニア的なところあるんだなっていうのが
実際知れたんですけど今回のやつって
レッツインクルートで他に話し足りないだったりとか
こういうところもあるんだよみたいなのって最後あったりしますか
まあ大体話した気はするんですけど
アクミプロトコルってもともとレッツインクリプトが使ってるやつだよね
っていう認識だったと思うんですけど
今は低証明書の有効期限短くなるって決まっちゃったんで
レッツインクリプト以外もアクミプロトコルを使って
じゃあいかに自動更新低証明書を自動更新する仕組みを
インフラに組み込むかっていうのをずっとみんな議論してる段階なんですよね
なのでちゃんとここに乗れるようにしていかないと
レッツインクルート使わないとしてもアクミプロトコルを結局使わないと
多分無理だと思うので
そこをどう自分たちの業務とかそういうのに組み込んでいくのかっていうのは
大事かなと思ってますね
番組紹介とリスナーへの呼びかけ
ありがとうございます
ということで今回ここまでにしたいなと思います
リアウヨロズのOSSでは毎回一つのOSSを取り上げて
それについてカタツイてへんってことで技術的なところも深掘りながら
お話をしていく番組になっています
今後もその名の通りリアウヨロズのOSS取り上げていきたいなと思ってますので
ぜひお聞きのプラットフォームでフォローと高評価のほうをお願いします
またこのOSSや話題について取り上げてほしいなどありましたら
コメントとかあとはXなどで教えていただけると非常に嬉しいです
よろしくお願いします
あとは番組についての感想もお待ちしておりますので
ぜひともよろしくお願いします
Xなどでつぶやく際にはハッシュタグリアウヨロズのOSSを付けてくださると
見つけやすくなりますのでよろしくお願いします
それでは今回もありがとうございました
ありがとうございました
