Let's Encrypt：Tech Basics／Keyword
WebサイトのHTTPS対応が推奨されている昨今、無償かつ自動でSSL（TLS）証明書の発行や更新ができる「Let's Encrypt」が注目を集めている。Web系エンジニアを主な対象として、その仕組みやメリット、デメリットを解説。
「Let's Encrypt」とは、SSL（TLS）に利用できるサーバ証明書を無償で発行している認証局またはサービスのこと。2016年4月から正式なサービスを開始した。MozillaやAkamai、Cisco Systemsなどが支援しているISRG（Internet Security Research Group）という団体が運営している。ソフトウェアツールによって証明書の更新などの作業を自動化できる点も特長として挙げられる。
Let's EncryptのWebサイトSSLの普及を妨げている2つの要因
現在、プライバシー保護やセキュリティ強化の一環として、クライアントとWebサイトやメールサーバとの通信の暗号化が強く推奨されている。たとえ個人情報のような秘匿すべき情報を持たないWebサイトでも、改ざん防止といった理由から通信路の暗号化が求められるようになってきた。
そのための技術は、SSL（TLS）で既に確立されている。だが実際には、少なくとも次の2つの問題がSSLの普及を妨げている。
1つは、SSLの実装に必須のサーバ証明書を発行したり更新したりするのに費用が掛かることだ。安価なものでも、1枚で1年当たり1000円〜2000円ぐらいは掛かる。
もう1つは、SSLを実装するのに手間が掛かることだ。まず証明書の発行やWebサーバへの設定といった作業が必要になる。また証明書の「更新」も厄介である。証明書には通常、期限があり、数カ月あるいは数年ごとに更新が求められる。その際、証明書を発行してくれる会社との間で、CSR（Certificate Signing Request：証明書署名要求）を送信したり、メールで証明書を受け取ったり、費用を決済したり、といった手動でのやりとりが強いられる。
どちらの問題も、サイト数やドメイン数が多くなるにつれてコストと手間が増大してしまう。
Let's Encryptの目的と狙い
Let's Encryptは、こうした問題を解消することで、SSLによる通信路の暗号化を普及させることを目的としている。
まず費用の問題については、スポンサー企業の支援などによって、証明書の発行や更新、失効といったサービスを、全て無償で提供している。証明書を発行する認証局も自ら運営している。
手間の問題については、ソフトウェアツールによる自動化で解決しようとしている。具体的には、
- 認証局によるWebサイトとドメインの認証
- 証明書署名要求の生成と送信
- 証明書の発行と受け取り
- Webサーバの設定変更
- 定期的な証明書の更新
- 証明書の失効処理
といった処理をWebサイト管理者が手動で実施する代わりに、専用のクライアント（エージェント）プログラムで自動的に処理させる。
Let's Encryptの仕組み
認証局はサーバ証明書を発行する際、その要求元（Webサイト管理者あるいはWebサーバ）が対象のドメインを管理（あるいは支配）できることを、事前に確認（認証）する必要がある（前述の「認証局によるWebサイトとドメインの認証」に該当）。これが正しく実行されないと、対象のドメインに関する権限を何ら持たない何者かが正当な証明書を取得して、なりすましなどに悪用できてしまう恐れがあるからだ。
Let's Encryptでは、この最初の認証を次のような仕組みで自動化している。
Let's EncryptによるWebサイトとドメインの認証の仕組み「How It Works」を参考にして図示してみた。ここでは、Webサーバで認証用ファイルを公開するという認証方式を前提としている（DNSレコードで認証することも可能）。
（1）まず、サーバ証明書をセットアップしたいWebサーバから、対象のドメイン名（FQDN）などをLet's Encryptの認証局に伝える。
（2）（1）に応じて生成された認証用の一時的な番号と、同じく認証用のファイルとそれを配置すべきパスが、Webサーバに伝えられる。
（3）（2）から生成した認証用ファイルを、同じく（2）で指定されたWebサイト上の特定パスに配置する。
（4）クライアントプログラムが生成した秘密鍵で（2）の認証用番号を署名し、公開鍵とともにLet's Encryptのサーバに伝える。
（5）「http://＜ドメイン名＞/.well-known/acme-challenge/＜認証用ファイル名＞」が参照され、認証用ファイルがダウンロードされる。
（6）（4）と（5）が確認され、認証に成功したかどうかがWebサーバに伝えられる。成功すると、クライアントプログラムが生成したキーペアを用いて、以後の証明書の発行や更新、失効といった作業を自動的に実施できるようになる。
この認証がいったん完了すると、以後は手動操作なしで、以下のように証明書の発行ができるようになる。
Let's Encryptによる証明書の発行の仕組み前述の認証と同じく、証明書の発行もソフトウェアツールによって自動処理される。
（1）クライアントプログラムがCSR（証明書署名要求）を生成する。他の認証局の場合と同じく、CSRはWebサーバの秘密鍵で署名される。
（2）事前に認証済みのクライアントプログラムの秘密鍵で、（1）のCSRをさらに署名する。それを受け取ったLet's Encrypt認証局は、二重にかかっている署名を検証し、クライアントプログラムが認証済みであることなどを確認する。
（3）Let's Encrypt認証局は、自身の秘密鍵で署名した証明書をクライアントプログラムに渡す。
こうしたクライアントプログラムと認証局とのやりとりには、ACME（Automatic Certificate Management Environment）と呼ばれる通信プロトコルが利用される。
- ietf-wg-acme/acme（IETFでのACMEの作業グループ）［英語］（GitHub）
多くのWebサーバ／OSをサポート
以上のような仕組みや仕様にのっとって、Webサーバでの証明書の処理を自動実行するためのクライアント（エージェント）プログラムが多数提供されている。まず、LinuxやmacOS、BSD系のディストリビューションといったUNIX系OSでは、Let's Encrypt推奨の「certbot」が利用できる。
- certbotのWebサイト［英語］（電子フロンティア財団）
- certbot［英語］（GitHub）
Windowsについてはサードパーティー製ツールが幾つか提供されている。
- letsencrypt-win-simple（コマンドラインコマンド）［英語］（GitHub）
- ACMESharp（PowerShell）［英語］（GitHub）
- Certify for Windows（GUIアプリケーション）［英語］（webprofusion）
発行されるのは「正規」のサーバ証明書
無償のサーバ証明書と聞くと、自己署名証明書（いわゆるオレオレ証明書）を思い浮かべるかもしれない。
だがLet's Encryptが発行する証明書はそれと全く異なり、以前からある有償の証明書発行サービスと同じく、公的で正規の認証局と信頼の連鎖が結ばれている。
Let's Encryptで発行された証明書での信頼の連鎖これはLet's Encryptに発行してもらったサーバ証明書をWindowsで開き、［証明のパス］タブを選んだところ。
（1）ルート証明書。古くから認証局を運営しているIdenTrust（旧Digital Signature Trust）社によるルート認証局を表している。同社はLet's Encryptのスポンサーでもある。
（2）中間証明書。Let's Encryptが運営している認証局の1つを表している。
（3）このサーバ証明書。（1）（2）（3）と信頼の連鎖が結ばれており、自己署名ではないことが分かる。
また上記画面にある「DST Root CA X3」というルート証明書は、現在利用できる多くのコンピュータにプリインストールされている（詳細はすぐ下のリンク先ページを参照）。そのため、このサーバ証明書を組み込んだWebサイトに対し、訪問するエンドユーザーは何ら特別な操作をすることなく、HTTPS経由でWebページを閲覧できる。
- Which browsers and operating systems support Let’s Encrypt［英語］（Let's Encrypt）
マルチドメイン対応やメールサーバへの応用も可能
Let's Encryptでは、1枚で複数のドメインを証明できるSAN（Subject Alternative Names）対応の証明書も発行できる。
Let's Encryptによって発行された複数ドメイン（SAN）対応の証明書の例これは筆者が開発用Webサイト向けにLet's Encryptから発行してもらった証明書の例。
（1）10個以上のドメイン名を登録している。ちなみに初回の発行手続きはコマンドラインを操作しつつ、約1分で完了した。Let's Encryptでは証明書1枚につき100個までドメイン名を登録できる。
Let's Encryptによって発行された証明書は、Webサーバの他に、メールサーバ間のメッセージ配送やメーラとメールサーバ間の通信をSSLで暗号化する場合にも利用できる。ただし、証明書の自動更新には対応していないことがまだ多いようだ。
Let's Encryptではできないこと
いいことずくめに思えるLet's Encryptだが、できないことや対応していないこともある。
まず、組織認証型の証明書やEV証明書は発行しておらず、ドメイン認証型の証明書のみ対応している（これらの区別は「実践！ SSL証明書の買い方・選び方」を参照）。つまりドメイン自体は証明しても、その運営者までは証明してくれない。
また、今のところワイルドカード証明書も発行していない。ワイルドカード証明書は、例えば「*.example.jp」に合致するような不特定のサブドメインを証明できる（異なる階層のサブドメインは不可）。その大きなメリットは、証明書の枚数を減らしてコストを下げ、かつ更新時の手間を少なくできることだ。その点では、無償で自動更新の可能なLet's Encryptなら、前述のSAN対応の証明書で代替しやすいはずだ。
Let's Encryptの証明書の有効期間は90日（約3カ月）固定であり、もっと長い1年間あるいは3年間などには指定できない。そのため、更新作業の自動化は必須といえよう（これはLet's Encrypt側が狙っていることでもある）。ただし、それには前述のようなコマンドラインコマンドあるいはスクリプトのセットアップと実行が必要となる。
その他、レンタルサーバのようにユーザーが管理者権限を取得できないマネージドサービスでは、次の例のようにサーバ運営側がLet's Encryptに明示的に対応する必要がある。
執筆時点では、Let's Encryptにより、HTTPS化が誰でも簡単にできるというレベルにはまだ至っていない。それでも「無償」というインパクトは大きい。また自動化のためのソフトウェアツールも改良が続けられており、将来性は大いにある。もしエンジニアとしてWebサイトの設計や構築、運用に関わるなら、Let's Encryptの動向は注目した方がよいだろう。
Copyright© Digital Advantage Corp. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。