最終更新日: | すべてのドキュメントを見る
このドキュメントは、ホスティングプロバイダーや大規模ウェブサイトをLet's Encryptと統合する場合、またはLet's Encryptのクライアントソフトウェアを開発する場合に役立つアドバイスを提供しています。
変化への計画
Let's EncryptとWeb PKIは、時間の経過とともに進化し続けます。Let's Encryptを使用するすべてのサービスを容易に更新できることを確認する必要があります。Let's Encrypt証明書に依存するクライアントも展開している場合は、これらのクライアントが定期的に更新されることを特に確認してください。
将来、これらの事項が変更される可能性があります。
- 私たちが発行するルート証明書と中間証明書
- 証明書の署名に使用しているハッシュアルゴリズム
- エンドエンティティ証明書の署名に同意するキーの種類とキー強度チェック
- そしてACMEプロトコル
このような変更については、常に可能な限り事前に通知することを目指しますが、何らかのコンポーネントに深刻なセキュリティ上の欠陥が見つかった場合、非常に短期間またはすぐに変更する必要がある場合があります。特に中間的な変更については、使用する中間体をハードコーディングしないで、中間体は変更される可能性があるため、ACMEプロトコルのLink: rel="up"ヘッダーを使用してください。
同様に、利用規約（ToS）を更新する際に、利用規約のURLを変更する可能性があります。ToSのURLをハードコーディングするのを避け、代わりにLink: rel="terms-of-service"ヘッダーを使用して、使用するToSのURLを決定してください。
新しい攻撃が暗号スイートまたはプロトコルバージョンで見つかった場合に、TLS構成を最新の状態に保つ方法も必要になります。
更新の取得
上記のような重要な変更に関する低頻度の更新を受信するには、当社のAPIアナウンスメントグループを購読してください。これは、クライアント開発者とホスティングプロバイダーの両方にとって役立ちます。
メンテナンスと停止に関する高頻度の更新については、当社のステータスページにアクセスし、右上の「購読」をクリックしてください。これは、ホスティングプロバイダーにとって最も役立ちます。
また、ACMEアカウントに有効なメールアドレスを使用してください。期限切れの通知を送信したり、アカウント固有の問題について連絡したりするために、そのメールアドレスを使用します。
加入者とは誰か
当社のCPSと加入者契約には、加入者とは証明書の秘密鍵を保持している者であることが記載されています。ホスティングプロバイダーの場合、それはプロバイダーであり、プロバイダーの顧客ではありません。ユーザーが自分で展開するソフトウェアを開発している場合は、ソフトウェアを展開しているユーザーです。
アカウント（登録とも呼ばれる）の作成時に提供された連絡先メールアドレスは、加入者に送信する必要があります。証明書の期限切れを警告したり、当社のプライバシーポリシーの変更について通知したりするために、このアドレスにメールを送信します。ホスティングプロバイダーの場合、これらの通知は顧客ではなく、あなたに送信する必要があります。休暇中の場合に備えて、複数の担当者が通知に応答できるように、メーリングリストまたはエイリアスを設定することをお勧めします。
つまり、ホスティングプロバイダーの場合、顧客のメールアドレスを送信したり、顧客に加入者契約に同意させたりする必要はありません。制御するドメインに対して証明書を発行し、それらを使用するだけで済みます。
アカウントは1つ？それとも複数？
ACMEでは、1つのアカウントを作成してすべての承認と発行に使用したり、顧客ごとに1つのアカウントを作成したりできます。この柔軟性は価値があるかもしれません。たとえば、一部のホスティングプロバイダーは、顧客ごとに1つのアカウントを使用し、アカウントキーを異なるコンテキストに保存して、アカウントキーが侵害されてもすべての顧客の発行が許可されないようにしたい場合があります。
ただし、ほとんどの大規模ホスティングプロバイダーには、単一のアカウントを使用し、対応するアカウントキーを適切に保護することをお勧めします。これにより、同じエンティティに属する証明書を簡単に識別し、連絡先情報を簡単に最新の状態に保ち、必要に応じてレート制限の調整を容易に行うことができます。多くの異なるアカウントを使用している場合、レート制限を効果的に調整することはできません。
マルチドメイン（SAN）証明書
当社の発行ポリシーでは、証明書ごとに最大100個の名前が許可されています。すべてのホスト名に個別の証明書を使用するか、少数の証明書に多くのホスト名をグループ化するかについては、ユーザー次第です。
ホスト名ごとに個別の証明書を使用すると、プロビジョニングと廃止に伴うドメインの論理的な追加と削除に必要な部分が少なくなります。個別の証明書を使用すると、証明書のサイズも最小限に抑えられるため、低帯域幅ネットワークでのHTTPSハンドシェイクを高速化できます。
一方、多くのホスト名を持つ大きな証明書を使用すると、証明書の管理全体数を減らすことができます。TLSサーバーネームインジケーション（SNI）をサポートしていないWindows XPなどの古いクライアントをサポートする必要がある場合、証明書ごとに固有のIPアドレスが必要になるため、各証明書に多くの名前を入れることで必要なIPアドレスの数を減らすことができます。
ほとんどの展開では、どちらの選択肢も同等のセキュリティを提供します。
証明書とキーの保存と再利用
Let's Encryptの価値の大きな部分は、新しいウェブサイトのプロビジョニングの一部として自動発行を可能にすることです。ただし、同じウェブサイトに対して新しいフロントエンドを繰り返し作成する可能性のあるインフラストラクチャがある場合、それらのフロントエンドは最初に永続的なストレージから証明書と秘密鍵を使用しようと試み、証明書がない場合、または既存のすべての証明書の期限が切れている場合にのみ新しい証明書を発行する必要があります。
Let's Encryptの場合、これにより、できるだけ多くの人に効率的にサービスを提供できます。あなたにとって、これは、Let's Encryptの状態に関係なく、必要なときにいつでもウェブサイトを展開できることを保証します。
例として、多くのサイトで、必要に応じて新しいフロントエンドインスタンスをプロビジョニングするためにDockerを使用し始めています。Dockerコンテナが起動時に発行するように設定し、証明書とキーを永続的に保存しない場合、一度に多くのインスタンスを起動するとレート制限に達する可能性があります。最悪の場合、すべてのインスタンスを一度に破棄して再作成する必要がある場合、どのインスタンスも証明書を取得できず、レート制限が期限切れになるまで数日間サイトが中断される可能性があります。ただし、この種の問題はレート制限に固有のものではありません。Let's Encryptが何らかの理由でフロントエンドを起動する必要があるときに使用できない場合、同じ問題が発生します。
暗号キーは生成された物理マシンから決して離れてはならないという展開の哲学もあることに注意してください。このモデルはLet's Encryptでも問題なく機能しますが、マシンとそのデータが長寿命であることを確認し、レート制限を注意深く管理する必要があります。
チャレンジタイプの選択
http-01 ACMEチャレンジを使用している場合は、Let's Encryptにチャレンジを実行する準備ができたことを通知する前に、各フロントエンドにチャレンジレスポンスをプロビジョニングする必要があります。多数のフロントエンドがある場合、これは困難になる可能性があります。その場合、dns-01チャレンジを使用する方が簡単です。もちろん、多くの地理的に分散されたDNS応答者がある場合は、各応答者でTXTレコードが使用可能であることを確認する必要があります。
さらに、dns-01チャレンジを使用する場合は、古いTXTレコードをクリーンアップして、Let's Encryptのクエリへの応答が大きくなりすぎないようにしてください。
それでもhttp-01チャレンジを使用したい場合は、HTTPリダイレクトを利用することを検討してください。各フロントエンドを、すべてのXYZに対して/.well-known/acme-validation/XYZをvalidation-server.example.com/XYZにリダイレクトするように設定できます。これにより、発行の責任がvalidation-serverに委譲されるため、そのサーバーを適切に保護する必要があります。
中央検証サーバー
上記の2点に関連して、多くのフロントエンドがある場合は、少数のサーバーを使用して発行を管理することが理にかなっている場合があります。これにより、http-01検証のリダイレクトを使用しやすくなり、証明書とキーを永続的に保存する場所が提供されます。
OCSPステープリングの実装
多くのブラウザは、サイトをロードするときにLet's EncryptからOCSPを取得します。これはパフォーマンスとプライバシーの問題です。理想的には、サイトへの接続は、Let's Encryptへの2番目の接続を待つべきではありません。また、OCSP要求は、ユーザーがどのサイトにアクセスしているかをLet's Encryptに伝えます。当社には優れたプライバシーポリシーがあり、OCSP要求から個人が特定できる詳細を記録することはありませんが、そもそもデータを受信したくないと考えています。さらに、ブラウザがLet's Encryptサイトを初めて訪問するたびにOCSPを提供するための帯域幅コストは、インフラストラクチャ費用のかなりの部分を占めることを予測しています。
OCSPステープリングを有効にすることで、ウェブサイトのパフォーマンスを向上させ、ユーザーのプライバシー保護を強化し、Let's Encryptができるだけ多くの人々に効率的にサービスを提供できるように支援できます。
ファイアウォール設定
Let's Encryptを使用するには、ACMEクライアントを実行しているマシンから送信ポート443のトラフィックを許可する必要があります。ACMEサービスのIP範囲は公開しておらず、予告なく変更される可能性があります。
「http-01」ACMEチャレンジでは、インバウンドのポート80トラフィックを許可する必要があります。検証を実行するIP範囲は公開しておらず、予告なく変更される場合があります。
注：WebサーバーへのプレーンHTTPアクセスを常に許可し、HTTPSにリダイレクトすることをお勧めします。これは、ポート80接続を拒否またはドロップするWebサーバーよりも優れたユーザーエクスペリエンスを提供し、同じレベルのセキュリティを提供します。
すべてのチャレンジにおいて、権限のあるDNSサーバーへのインバウンドポート53トラフィック（TCPおよびUDP）を許可する必要があります。
サポートされているキーアルゴリズム
Let's Encryptは、長さ2048、3072、または4096ビットのRSAキー、およびP-256またはP-384 ECDSAキーを受け入れます。これは、アカウントキーと証明書キーの両方で当てはまります。アカウントキーを証明書キーとして再利用することはできません。
RSA証明書をデフォルトで提供し、サポートを示すクライアントに（はるかに小さい）ECDSA証明書を提供するデュアル証明書構成を使用することをお勧めします。
デフォルトでHTTPS
ホスティングプロバイダーの場合、制御するすべてのホスト名に対して証明書を自動的に発行し、HTTPSを構成すること、およびHTTP URLをHTTPS相当物にリダイレクトするかどうかをユーザーが設定できるようにすることをお勧めします。既存のアカウントではこの設定をデフォルトで無効に、新しいアカウントではデフォルトで有効にすることをお勧めします。
理由：既存のWebサイトには、いくつかのHTTPサブリソース（スクリプト、CSS、画像）が含まれている可能性があります。これらのサイトが自動的にHTTPSバージョンにリダイレクトされると、ブラウザーは混合コンテンツブロッキングによりこれらのサブリソースの一部をブロックします。これにより、サイトの機能が損なわれる可能性があります。しかし、新しいサイトを作成してHTTPSにリダイレクトされることがわかった人は、HTTPサブリソースを含めようとするとすぐに機能しないことがわかるため、HTTPSサブリソースのみを含める可能性が高いです。
デフォルトのmax-ageを60日に設定したHTTP Strict-Transport-Security（HSTS）ヘッダーを顧客が設定できるようにすることをお勧めします。ただし、この設定には、顧客がHTTPSを提供しないホスティングプロバイダーに移行する必要がある場合、ブラウザーのキャッシュされたHSTS設定によりサイトが使用できなくなるという警告を添える必要があります。また、顧客とホスティングプロバイダーの両方で、HSTSヘッダーにより証明書のエラーが致命的なエラーになることを認識しておく必要があります。たとえば、名前の不一致や証明書の期限切れに関するブラウザーの警告をクリックして先に進むことができる場合が多いですが、アクティブなHSTSヘッダーを持つホスト名では、ブラウザーはそのようなクリックを許可しません。
更新時期
有効期限の3分の1が残っている時点で証明書を自動的に更新することをお勧めします。Let's Encryptの現在の90日間の証明書の場合、これは有効期限の30日前に更新することを意味します。
10,000を超えるホスト名に対して発行する場合は、更新を一括して大きなチャンクにまとめるのではなく、小規模な実行で自動更新することをお勧めします。これにより、リスクが軽減されます。Let's Encryptに更新が必要なときに障害が発生した場合、または更新システムに一時的な障害が発生した場合、すべての証明書ではなく、少数の証明書にのみ影響します。また、当社のキャパシティプランニングも容易になります。
開始を迅速に行うために、すべてのドメインの証明書を一括発行しても問題ありません。その後、通常更新するよりも1日前に一部の証明書を更新し、2日前に一部の証明書を更新するなど、1回限りのプロセスを実行することで、更新時間を分散できます。
定期的なバッチジョブを自動的に構成するクライアントソフトウェアを提供する場合は、常に特定の時間に実行するのではなく、1日のランダムな秒数で実行するようにしてください。これにより、Let's Encryptが時間または分の開始時に任意のトラフィックのスパイクを受け取らないようにします。Let's Encryptはピーク負荷を満たすために容量を準備する必要があるため、トラフィックスパイクを減らすことでコストを抑えることができます。
失敗の再試行
更新の失敗は、致命的なエラーとして扱うべきではありません。指数バックオフパターンを使用して、証明書ごとに1日1回を最大限に、発行サービスに段階的な再試行ロジックを実装する必要があります。たとえば、妥当なバックオフスケジュールは次のとおりです。1分後に1回目の再試行、10分後に2回目の再試行、100分後に3回目の再試行、4回目以降の再試行は1日後。もちろん、管理者がドメインごとまたはグローバルに早期再試行を要求する方法を用意する必要があります。
再試行時のバックオフとは、発行ソフトウェアが成功だけでなく失敗も追跡し、新しい発行を試みる前に最近失敗があったかどうかを確認する必要があることを意味します。繰り返される失敗は永続する可能性が高いため、1時間に何百回も発行を試みるのは意味がありません。
すべてのエラーは担当管理者に送信する必要があります。これにより、特定の問題を解決する必要があるかどうかを確認できます。