最終更新日:
Let’s EncryptとACMEプロトコルの目的は、HTTPSサーバーをセットアップし、人間の介入なしに、ブラウザが信頼する証明書を自動的に取得できるようにすることです。これは、Webサーバー上で証明書管理エージェントを実行することで実現されます。
テクノロジーの仕組みを理解するために、Let’s Encryptをサポートする証明書管理エージェントを使用して、https://example.com/をセットアップするプロセスを見ていきましょう。
このプロセスには2つのステップがあります。まず、エージェントはWebサーバーがドメインを制御していることをCAに証明します。次に、エージェントはそのドメインの証明書を要求、更新、および失効させることができます。
ドメイン検証
Let’s Encryptは、公開鍵によってサーバー管理者を識別します。エージェントソフトウェアがLet’s Encryptと初めて対話するとき、新しい鍵ペアを生成し、サーバーが1つ以上のドメインを制御していることをLet’s Encrypt CAに証明します。これは、アカウントを作成し、そのアカウントにドメインを追加するという従来のCAプロセスに似ています。
プロセスを開始するために、エージェントはLet’s Encrypt CAに、example.comを制御していることを証明するために何をする必要があるかを尋ねます。Let’s Encrypt CAは、要求されているドメイン名を調べ、1つ以上のチャレンジのセットを発行します。これらは、エージェントがドメインの制御を証明できるさまざまな方法です。たとえば、CAはエージェントに次のいずれかの選択肢を与える可能性があります。
example.comの下にDNSレコードをプロビジョニングするか、http://example.com/の既知のURIの下にHTTPリソースをプロビジョニングする
チャレンジとともに、Let’s Encrypt CAは、エージェントが鍵ペアを制御していることを証明するために秘密鍵ペアで署名する必要があるnonceも提供します。
エージェントソフトウェアは、提供されたチャレンジのセットの1つを完了します。上記の2番目のタスクを完了できるとしましょう。つまり、http://example.comサイトの指定されたパスにファイルを作成します。エージェントは、提供されたnonceにも秘密鍵で署名します。エージェントがこれらの手順を完了すると、検証を完了する準備ができたことをCAに通知します。
次に、CAは、複数のネットワークパースペクティブからチャレンジが満たされていることを確認する責任があります。CAはnonceの署名を検証し、Webサーバーからファイルをダウンロードし、期待されるコンテンツがあることを確認しようとします。
nonceの署名が有効で、チャレンジが確認された場合、公開鍵によって識別されるエージェントは、example.comの証明書管理を行う権限があります。エージェントが使用した鍵ペアをexample.comの「承認された鍵ペア」と呼びます。
証明書の発行と失効
エージェントに承認された鍵ペアがある場合、証明書の要求、更新、失効は簡単です。証明書管理メッセージを送信し、承認された鍵ペアで署名するだけです。
ドメインの証明書を取得するために、エージェントはPKCS#10 証明書署名リクエストを構築し、Let's Encrypt CAに、指定された公開鍵でexample.comの証明書を発行するように依頼します。通常どおり、CSRには、CSR内の公開鍵に対応する秘密鍵による署名が含まれています。エージェントは、Let's Encrypt CAが承認されていることを知るために、example.comの承認された鍵でCSR全体にも署名します。
Let's Encrypt CAがリクエストを受信すると、両方の署名を検証します。すべて問題がなければ、CSRの公開鍵を使用してexample.comの証明書を発行し、エージェントに返します。CAは、証明書を多数の公開証明書透明性（CT）ログにも提出します。詳細については、こちらを参照してください。
失効も同様の方法で機能します。エージェントは、example.comで承認された鍵ペアを使用して失効リクエストに署名し、Let's Encrypt CAはリクエストが承認されていることを確認します。その場合、ブラウザなどの依存当事者が失効した証明書を受け入れるべきではないことを知ることができるように、通常の失効チャネル（つまり、OCSP）に失効情報を公開します。
