「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。EncryptやACMEプロトコルによるDV証明書取得の自動化に伴い、証明書の取得と設定が簡単になってきました。一方で、ACMEをツール化したものが増えるに従って、ACMEってそもそもどういう動きになっているのか、とか、自分たちの用途でどういう使い方がありえるのかとかが余計にわかりにくくなってきており、どこまで自動化できるかもよくわからない場合が多いのではないでしょうか。的な動きを実現したいと考え、ACMEの通信の中で各種処理を別のスクリプトでhookできるdehydratedとngx_mrubyを応用して実現可否も含めてPoCを実装してみました。FastContainerという考え方については、以下の記事をご覧ください。ようするに、リクエスト契機で必要な設定やWebサーバの立ち上げをやってしまって、裏でタスクを回すみたいな処理を極力避けるようなピタゴラスイッチ的なアーキテクチャ(FaaSとかも似ている)のことを指しております。hatenanews.com結果、結構簡単にできてしまったので、そのための便利メソッドをNginx::SSL::ACMEとしてngx_mrubyに取り込み、nginxのサンプル設定も同封しました。下記PRがその内容になります。v1.19.2でExperimentalな機能としてリリースしています。github.comこのPRで実現しているフローを簡単に図にすると以下のようになります。図にあるとおり、とあるngx_mrubyが動いているサーバにAレコードを向けさえすれば、最初のHTTPSのアクセス時に動的に証明書を取得してredisに保存してからレスポンスを返し、2回目以降はredisから証明書データを取り出して返すようになります。実際に上記の動きをnginx.conに書くと、以下のようになります。ここで利用しているNginx::SSL::ACMEクラスは既にngx_mrubyのコアに導入済みなので使うことができます。}}この設定の特徴としては、どんなドメインであっても、Aレコードが向いていれば自動に証明書を取得しにいってHTTPS通信がはじまること、それらをnginxの設定を変えることなく動的に実現できることです。後は、ドメインに応じて動的にこれまたngx_mrubyでバックエンドサーバへのプロキシ先を選択するようにしておけば、nginx自体の設定もシンプルにしておくことができます。0m0.007sというように、一番最初のアクセスは証明書取得のため数秒かかりますが、2回目以降はredisのデータ経由でシュシュっとレスポンスを返せています。Encryptのstagingで試しているため–insecureを使っています)また、例えばホスティング的には最初の環境の用意の時点であれば、遅くても問題ないのでそういうドメインがどんどん増えていくようなサービスにおいては実用に足るかなと思います。このPoCでは、証明書更新についてはまだ未実装ですが、ここまでできればその処理もさほど難しくないでしょう。いうことで、是非ngx_mrubyを様々な証明書管理や動的処理にご活用下さい。はてなブログPro研究者と技術者をやっています。詳しくはリンクの「研究・開発業績ページ」を御覧ください。さくらインターネットに入社して1年が経ちました非厳密計算で確率的に解釈するコンピューティングへの流れラストオーサーとしての国際会議投稿やジャーナル執筆のサポートについてviを:wqや:q!、あるいはZZで終了するのとではどちらが効率的か自分の研究開発に自信を持つためには月別アーカイブリンク研究・開発業績ページ旧ブログ検索はてなブログをはじめよう!matsumoto_rさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。