Let’s Encrypt ACME：証明書の自動化と更新の確実な管理

ACMEのプロセスと分離された鍵の役割

ACMEは、クライアントと認証局間の通信を標準化するものであり、運用環境全体を標準化するものではありません。 クライアントはまずACMEアカウントを使用し、その後、1つまたは複数のドメイン名に対する注文を作成します。サーバーは、各識別子について認証を要求します。この認証が成功して初めて、クライアントは証明書署名要求（Certificate Signing Request、略してCSR）を用いて注文を確定し、発行された証明書を取得することができます。.

1. アカウントキーを生成するか、既存のACMEアカウントを使用して、注文を作成します。.
2. 要求された識別子ごとに、指定されたチャレンジを提示し、認証が完了するのを待つ。.
3. 証明書用に個別の鍵ペアを生成し、そこからCSRを作成して、注文を確定します。CSR内の公開鍵は、確定依頼を認証するためのアカウント鍵と一致してはなりません。.
4. 証明書と証明書チェーンを取得し、安全に保管した上で、指定されたTLSエンドポイントに配布する。.

仝 ACMEアカウントキー ACMEサーバーに対して、そのアカウントのクライアントを認証し、プロトコルメッセージに署名します。一方、CSRで使用される秘密鍵は、後のTLS識別情報に属するものです。 RFC 8555では、2つの異なる鍵クラスが要求されています。CSRの公開鍵は、既知のアカウント鍵と一致してはならず、特に、ファイナライゼーション要求を認証するアカウント鍵と同一であってはなりません。クライアントとサーバーは、この分離を確認する必要があります。.

DNS-01では、3つ目の機密性の高い要素が追加されます。それは、DNS-APIへのアクセス権限です。 Let’s Encryptは、Webサーバー上に完全なDNS APIのアクセス情報が存在すると、攻撃を受けた際の被害が著しく拡大すると指摘しています。そのため、運用上のセキュリティ対策として、トークンには必要なチャレンジレコードのみを変更できる権限を付与すべきです。あるいは、DNSの検証を別のシステムで行うことも可能です。.

アカウント鍵、証明書鍵、およびDNSアクセスは、それぞれ異なる信頼領域を構成します。アカウントと証明書に異なる鍵ペアを使用することはプロトコルの要件であり、これらを別々に保管すること、アクセス権を厳格に制限すること、および独立した鍵ローテーションプロセスを実施することは、さらに重要な運用上の措置となります。 これにより、DNSトークンが侵害されたとしても、証明書の秘密鍵やACMEアカウントへのアクセスが必ずしも可能になるわけではありません。.

自動化によって、誤った前提条件が解消されるわけではありません。到達不可能なポート、誤ったルーティング、不適切なDNS委任、あるいは範囲が広すぎるアクセス権などは、注文作成が自動化されていても、運用上の問題として残ります。 ACMEは反復可能なプロセスを加速させますが、権限管理の概念、アカウント鍵と証明書鍵の規定された分離、安全な保管、および実際に発行された証明書の管理については、運用担当者が自身の環境において確実に実施する必要があります。.

インフラにぴったりのチャレンジ

このチャレンジは、認証局が識別子に対する管理権限をどのように検証するかを規定するものである。したがって、これはネットワーク経路、DNS管理、およびTLS終端から導き出されるべきであり、特定のクライアントツールに対する一律的な優先順位に基づいて決定されるべきではない。 HTTP-01、DNS-01、およびTLS-ALPN-01は、それぞれ異なる種類の管理方法を規定しており、それに応じてインフラストラクチャや権限に対する要件も異なります。.

一般に公開されている単一のウェブサイトについては、 HTTP-01 たいていは最も直接的な方法です。クライアントはリソースを /.well-known/acme-challenge/ ポート80経由でLet’s Encryptにアクセスする準備が整っています。1つのドメインが複数のAレコードまたはAAAAレコードの宛先を指している場合、このリソースは、検証リクエストが到達する可能性のあるすべてのシステムからアクセス可能でなければなりません。そうしないと、時折発生する検証エラーが生じます。.

ワイルドカード証明書（対象：） *.example.org それに対して、以下は必須である DNS-01. クライアントは、そのために以下のURLにTXTレコードを公開します。 _acme-challenge.example.org. 。これは、動的なサブドメインや分散型Webサーバー、あるいはロードバランサーなど多くの環境に適しています。なぜなら、単一のHTTPインスタンスが検証ファイルを提供する必要がないからです。ただし、信頼性が高く、自動化可能なDNS変更が前提となります。.

ポート80が利用できないリバースプロキシは、 TLS-ALPN-01 ポート443でのTLS終端を制御しており、かつ使用されるクライアントがこのチャレンジをサポートしている場合に限り、これを適用できます。 検証は通常のWebファイルではなく、専用のTLS接続を介して行われます。したがって、この方式は特殊なプロキシやホスティングインフラストラクチャには特に適していますが、HTTP-01の一般的な代替手段としては適していません。ここでもワイルドカードはサポートされていません。.

どの手法も一概に優れているとは言えません。HTTP-01はシンプルなウェブサイトにおいてDNSへのアクセスを削減し、DNS-01はワイルドカードに対応し、検証をWebパスから切り離します。一方、TLS-ALPN-01は既存のTLSチェックを的確に活用します。 重要なのは、選択したチャレンジが実際のフェイルオーバー、IPv4、およびIPv6のパスで機能し、その権限がそれぞれの運用モデルに適合していることです。.

ARI、プロファイル、およびより短い稼働時間

と一緒に ACME 更新情報 (ARI) では、更新のロジックが、ローカルで設定された基準日から、ACMEサーバーが推奨する時間枠へと移行します。 クライアントは既存の証明書についてこの情報を照会し、その時間枠内でランダムなタイミングを選択します。これにより、更新を時間的に分散させたり、特別な事象が発生した際に意図的に前倒ししたりすることが可能になります。.

ARIは標準化された拡張機能ですが、インストール済みのクライアントやホスティングパネルすべてに自動的に備わっている機能というわけではありません。 Let’s Encryptは、既存のエンドポイントに対して後方互換性のある新しいACME機能を提供できますが、個々のインストール環境でそれが利用されるかどうかは、そのバージョンや実装状況によって異なります。したがって、大規模な環境では、クライアントがARIを照会しているか、時間枠を遵守しているか、更新を再同期していないかを確認する必要があります。.

また、Let’s Encryptは注文を証明書プロファイルに割り当てます。明示的にプロファイルを選択しない場合、デフォルトでは「クラシック」プロファイルが適用され、現在の有効期間は90日間です。このプロファイルは tlsserver 有効期間は45日間で、未決済の承認および注文についてはより短い期限が設定されており、DNS名は最大25個までです。. shortlived こちらも短いオブジェクト有効期間を採用しており、有効期間は約160時間で、DNSおよびIP識別子をサポートしています。.

プロファイルの選択にもクライアント側のサポートが必須であり、サーバーのドキュメントのみに基づいて判断すべきではありません。 プロファイルは、有効期間や識別子のほか、その他の特性においても異なります。したがって、アプリケーションやインベントリ管理ツールは、一様な処理の流れや、すべての証明書にコモンネームが存在することを暗黙の前提としてはいけません。.

計算上、90日間と約160時間の間には、所要時間において約13.5倍の差があります。これによって具体的な負荷が生じるわけではありませんが、計画上の明確な帰結が導かれます。すなわち、発注、配分、または再読み込みのいずれかの段階で障害が発生した場合、 短期の証券 はるかに早い段階から批判的な見方がありました。これらは、サプライチェーン全体が監視されており、更新が手動による介入に依存しないシステムにのみ有効です。ARIが調整する更新については、Let’s Encryptにおいて、文書化された条件のもとで、レート制限に関する特別な規則が適用されます。.

チャレンジマトリックスと安全なDNS委任

チャレンジの選択は、達成可能なインフラに基づいており、一般的な順位によるものではありません。 HTTP-01ではポート80経由で一般に公開されている応答が、DNS-01では制御可能なTXTレコードが、TLS-ALPN-01ではポート443でのTLS終端の制御が求められます。ワイルドカード名は、DNS-01でのみ検証可能です。.

したがって、単一のWebサーバーで構成されるWebサイトの場合、多くの場合HTTP-01で十分です。しかし、DNSのAレコードやAAAAレコードが複数のシステムを指している場合、実際に到達した各ターゲットが期待されるリソースを返さなければなりません。そうでない場合、結果は検証がどのエンドポイントに到達したかによって左右されます。 ロードバランサーや一元的に同期されたチャレンジストレージは、すべての経路を網羅している場合にのみ、この問題を解消できます。.

DNS-01については、 最小限の権限 ACMEクライアントが必要なチャレンジエントリのみを変更できるようにすることを目指すべきです。実際にどのような制限が可能かは、DNSプロバイダーのAPIおよび権限モデルによって異なります。すべてのサービスが個別のTXT名に対する権限を許可しているわけではありません。 広範なアクセス権しか残されていない場合は、検証処理を別のシステムに移行するか、専用のチャレンジゾーンを委任する必要があります。アクセス情報は、証明書やACMEアカウントの鍵とは別に、保護された保管場所に保管する必要があります。.

ゾーンの範囲が広範囲にわたる場合、別途設定されたチャレンジゾーンによって権限をさらに制限することができます。権限の委譲は _acme-challenge CNAME または NS レコードを使用して、検証データを独自の管理領域に移行します。これにより、クライアントはその領域でのみ変更権限を持つことになります。本番運用を開始する前に、TXT レコードの内容と DNS 解決を確認する必要があります。リゾルバーが委任またはレコードをまだ認識していない場合、API からの応答が正しくても不十分です。.

更新と配布を確実に自動化する

耐久性のある 証明書管理 証明書の取得だけで終わるわけではありません。分散環境では、中央のACMEワーカーが検証をトリガーし、証明書と秘密鍵を安全に保管します。その後になって初めて、これらのアーティファクトがTLSエンドポイントに配布され、そこで検証された上で管理下で有効化されます。 CSRで使用される証明書鍵は、認証用のACMEアカウント鍵とは異なるものでなければなりません。両方の鍵をその後どのように個別に保存し、アクセス権限を設定し、ローテーションを行うかは、運用コンセプトで定義する必要があります。.

以下の表は、サプライチェーンにおける推奨される運用コンセプトを示しています。RFC 8555 では、CSR の公開鍵が既知のアカウント鍵と一致してはならず、特に、ファイナライゼーションリクエストの認証に使用されるアカウント鍵と一致してはならないと規定されています。 保存、アクセス権、およびローテーションの具体的な組織的な分離は、このプロトコル要件に基づいています。Certbotのデプロイフックは、証明書の発行が成功した後の処理を目的としています。通信のセキュリティ確保、宛先の検証、および外部TLS検証は、それぞれのインフラストラクチャに合わせて実施する必要があります。.

パネルやDNSの統合に関する変更を行う場合、本番環境を単一のシステムとして捉えるべきではありません。特に、 ホスティング事業者向けのPleskアップデート 利用可能な機能は、Panelstand、拡張機能、および連携サービスによって異なります。追加のプロトコル拡張など、ACMEクライアントの具体的な機能についても、バージョンによって異なり、実際に使用する組み合わせで確認する必要があります。.

Certbot では、デプロイフックは更新が成功した場合にのみ実行されるため、最後のステップをトリガーすることができます。以下のサンプルでは、ローカルパスに、認証情報を含まない、検証済みの実行可能スクリプトが存在することを前提としています。このスクリプトは、 べきべき 作業を行い、エラーを記録し、更新された証明書を使用するサービスのみを再読み込みする。.

certbot renew --deploy-hook /usr/local/sbin/reload-tls-services

の終了ステータスは certbot renew これは新しい証明書の証拠にはなりません。更新すべきものがなかった場合でも、コマンドはステータス 0 で終了することがあります。したがって、監視システムは、パブリックエンドポイントが実際にどの証明書を発行しているか、その有効期限はいつか、そしてリロードが成功したかどうかを独自に確認する必要があります。.

CAA、IPアドレスのプロファイルおよび証明書

CAAレコードとは、 展示用手すり: これは、どの認証機関がドメインの証明書を発行できるかを規定するものです。さらに、このポリシーでは、許可される検証方法や、パラメータを通じて accounturi 指定されたACMEアカウントを設定します。現在のアカウントキーは、このアカウントへのアクセスを認証しますが、ACMEキー変更プロセスを通じて変更することが可能です。したがって、アカウントの紐付けは、現在のアカウントキーによる保護や包括的な権限管理の代わりとなるものではありません。.

以下のレコード行は、DNS-01 検証の場合にのみ、そのドメインで Let’s Encrypt を許可するものです。これは、DNS-01 が自動的に設定されており、チャレンジゾーンが確実に管理されている場合にのみ適しています。 後で個別のウェブサイトに対してHTTP-01、あるいはリバースプロキシに対してTLS-ALPN-01を利用したい場合は、示された制限により、意図的にこの証明書の発行をブロックすることになります。.

example.org. CAA 0 issue "letsencrypt.org;validationmethods=dns-01"

その1行だけでは、必ずしも完全な内容を表しているとは限りません。 CAAポリシー そのゾーン内。同じタイプのレコードが複数ある場合、その効果は累積的に作用します。つまり、そのうちの1つが発行を許可していれば、それより制限の厳しい他のレコードが存在しても、その許可は有効です。また、ワイルドカード証明書については、以下の点も確認する必要があります。 issuewild-レコードが存在する場合。そのようなレコードがない場合は、 issue ワイルドカードについても同様です。既存の issuewild-一方、エントリはワイルドカードの付与を個別に制御します。したがって、常に、検証対象の名前に対する完全かつ有効なレコードセットが基準となります。.

パブリックIPアドレス用の証明書は、ドメイン証明書とは別のケースです。Let’s Encryptは、プロファイル内のIP識別子をサポートしています。 shortlived; 検証方法としては、HTTP-01およびTLS-ALPN-01が候補となる。DNS-01ではIPアドレスの検証はできない。そのため、有効期間が約160時間と短いことから、継続的な自動更新、配布、および配信管理が不可欠となる。.

したがって、shortlivedプロファイルは、各ステップが手動操作を必要とせずに機能する場合に限り、IP経由で直接アクセス可能なインターフェースなどに適しています。 これは、時折メンテナンスが行われるシステム向けの簡略版ではありません。また、使用するACMEクライアントおよびターゲット環境は、プロファイルの選択および選択されたチャレンジをサポートしている必要があります。ACMEサービスで利用可能であるからといって、すべてのクライアントバージョンがそれをサポートしているとは限りません。.

まずはステージング環境での監視とトラブルシューティング

ACMEのトラブルシューティングは、証明書を再発行することではなく、実際に使用されている検証手順から始める必要があります。クライアント、ルーティング、ファイアウォール、またはDNSの変更については、Let’s Encryptの独立したステージングエンドポイントが適しています。 ステージング環境には独自の、はるかに高い制限が設けられていますが、無制限というわけではありません。また、そこで発行されるテスト証明書は、公的に信頼できるものではありません。新しいプロトコル機能がACMEエンドポイントで利用可能であっても、インストール済みのクライアントがそれらをサポートしているかどうかは別途確認する必要があります。.

HTTP-01 の場合、まず、対象のドメインがポート 80 経由で一般にアクセス可能かどうか、およびリクエストされたファイルが /.well-known/acme-challenge/ 宛先システムに配信します。複数の A レコードや AAAA レコードが存在すると、テストはより困難になります。実際に到達可能な各エンドポイントは、適切なチャレンジファイルを提供する必要があります。典型的な原因としては、仮想ホストのルーティングが異なる場合、上流にプロキシが存在する場合、ファイアウォールのルール、またはコンテナの同期が取れていない場合などが挙げられます。.

一方、TLS-ALPN-01では、ポート443におけるTLSの終端処理を制御することが求められます。エラーが発生した場合は、どのロードバランサーまたはプロキシが接続を受け付けているか、チャレンジに必要な証明書を返しているか、そして通常のTLSサービスがこの処理を上書きしていないかを確認する必要があります。 ローカル証明書ファイルの作成に成功したからといって、公開されているエンドポイントがそれを使用していることを証明するものではありません。.

DNS-01では、TXTレコードの名前と内容は _acme-challenge 個別に確認する必要があります。レコードは、委任ゾーンまたは権限ゾーンに公開されている必要があります。また、別のチャレンジゾーンを使用する場合は、委任チェーンが正しいことも確認する必要があります。入力ミス、まだ反映されていない変更、または不適切な委任による繰り返しの失敗については、まずはステージング環境で分析を行うべきです。.

効果的な モニタリング ACMEワーカーの保存領域にある有効期限だけでなく、配信されたホスト名、そこに提示されている証明書の残存有効期間、および更新後のリロードの成否についても独自に確認します。 また、更新に失敗した場合や、発行は成功したにもかかわらずエンドポイントが依然として古い証明書を配信している場合にも、アラートを発すべきです。ホスティングサーバーに対する予定された変更については、本記事で補足しています。 cPanel および WHM のアップデートを確実に計画する 必要な操業計画。.

保有ポジションのレート制限と更新

証明書のコレクションにおいて、レート制限は SSLの自動化. 毎日強制的に行われる更新や、同時に開始されるジョブは、不要なオーダーを生成し、制限を引き起こす可能性があります。 これは、インフラストラクチャのエラーが多数のドメインに同時に影響を及ぼす場合に特に当てはまります。再実行を行っても、欠落したチャレンジファイルや誤ったDNS設定は修正されませんが、検証失敗の件数は増加します。したがって、次の本番実行の前に、エラーの原因を特定して範囲を絞り込む必要があります。.

ACME 更新情報、略して ARI, 、固定されたローカルしきい値の代わりに、ACMEサーバーが既存の証明書に対して推奨する更新期間を採用します。ARI対応のクライアントは更新情報を取得し、その期間内のランダムなタイミングを選択します。 スケジューラはクライアントを定期的に起動することはできますが、ARI自体を解析することはありません。クライアントは、推奨される期間と Retry-After これらを考慮するとともに、エラーが発生した場合には適切なバックオフおよび再試行間隔を遵守する。したがって、スケジューラの実行頻度が高くなっても、失敗したジョブの無制限な再試行につながってはならない。.

Let’s Encrypt については、ARI が調整する更新は、文書化されたレート制限の要件を満たす場合、その制限の対象外となる場合があります。 新しいリクエストには、とりわけ、置き換える対象となる証明書の識別子が少なくとも1つ含まれていなければならず、その証明書はARIを通じてすでに置き換えられていない必要があります。これは、任意の新規リクエストに対する一般的な許可ではありません。証明書の範囲の変更については、技術的および運用上の観点から個別に扱う必要があります。.

特に、SANリストが短縮または変更された場合でも、それだけで既存の証明書が自動的に更新されるわけではありません。既存の名前のうち一部のみを含むリクエストでは、新しい証明書が発行される一方で、古い証明書は引き続き有効なままとなります。 したがって、インベントリには、証明書ID、完全な識別子リスト、割り当てられたエンドポイント、および更新手順を記録する必要があります。SANの変更を計画する際には、どのサービスを移行するか、また不要になった証明書をいつ削除するかを事前に決定する必要があります。.

複数のワーカーが存在する場合、明確な責任分担により、同一の在庫に対する重複した注文を防ぐことができます。中央スケジューラや協調的なロック、追跡可能なログ、エラー発生後の段階的な再試行などが有効です。 ARIウィンドウ内でのランダムな選択は、この制御の代わりとなるものではなく、主に定期的な更新の同時発生を減らす役割を果たします。.

リスクに応じて適切な事業モデルを選択する

一般に公開されている単一のウェブサイトの場合、HTTP-01が通常最もシンプルな運用モデルとなります。Webサーバーはポート80を確実に処理し、指定されたパスにあるチャレンジファイルを配信する必要があります。このモデルはワイルドカードには対応しておらず、複数の独立したリソースが同じドメインに応答する場合、脆弱になります。 したがって、このモデルは、ウェブルーティング、証明書の保管、TLS配信が、明確に管理された1か所に集約されている場合に特に有効です。.

DNS-01は、ワイルドカード、動的サブドメイン、分散型TLSエンドポイントに適したモデルです。前提条件は、単にDNSへのアクセスが可能であることだけでなく、必要なTXTレコードを確実に自動で変更できることです。 トークンの範囲を可能な限り狭く限定するか、または委任されたチャレンジゾーンを設定することで、システムが侵害された際の影響を軽減できます。どの程度の細分化が可能かは、DNS APIによって異なります。委任は、本番環境の依存関係として文書化・監視され、復旧手順が整備されていなければなりません。.

TLS-ALPN-01は、リバースプロキシやロードバランサーなどで、ポート443におけるTLSターミネーションを意図的に制御したい運用者に適しています。 この方式は、HTTP-01の包括的な代替手段ではなく、ワイルドカードにも対応していません。また、実用性は、クライアントおよびプロキシの各実装状況にも左右されます。そのため、導入前には、ソフトウェアがチャレンジを生成・送信し、完了後に適切に削除できるかどうかを確認する必要があります。.

仝 shortlivedのプロフィール これは、エンドツーエンドの自動化が完全に整備されたシステムにのみ適しています。Let’s Encryptは、これについて約160時間の有効期間およびDNSとIP識別子を規定しています。90日間の標準プロファイルと比較すると、これにより計算上、必要な更新頻度が大幅に増加します。 したがって、注文から配布、リロード、外部検証に至るまでの各プロセスが、確実に機能する必要があります。また、プロファイルを選択するにあたっては、使用するACMEクライアントが実際にそのプロファイルの選択に対応していることが前提となります。.

機種にかかわらず、プロ仕様の 証明書管理 完全なインベントリ、安全に管理された鍵、および最小限の権限に制限されたDNSアクセス。アカウント鍵はACMEアカウントに対するクライアントの認証に使用され、CSRで使用される秘密鍵はTLSアイデンティティに属する。 RFC 8555では、証明書内にアカウントの公開鍵を使用することを禁じています。特に、CSR内の鍵は、最終化依頼を認証するためのアカウント鍵と一致してはなりません。 これらの鍵クラスの分離保管、権限付与、ローテーション、および取り消し可能なアクセス権、さらに以前の証明書への検証済みの復元経路は、権限管理および緊急時対応の概念の一部を構成します。.

ACMEの実行が成功したことだけを成功の基準にしてはなりません。デリバリーチェックでは、ワーカーの外側で、どの証明書が本物のTLSエンドポイントによって提示されているかを判別する必要があります。 配布および再読み込みのステップには、更新が成功した場合にのみトリガーされるアクションが適しています。Certbotでは、このためにデプロイフックが用意されています。そのスクリプトは、冪等性（idempotent）を備え、エラーをログに記録し、更新された素材を実際に使用するサービスのみを再読み込みするようにする必要があります。.