自動HTTPS

Caddyは、自動的にかつデフォルトでHTTPSを使用する最初で唯一のウェブサーバーです。

自動HTTPSは、すべてのサイトに対してTLS証明書をプロビジョニングし、更新を維持します。また、HTTPをHTTPSにリダイレクトします。Caddyは安全でモダンなデフォルトを使用します。ダウンタイム、追加の設定、または別のツールは必要ありません。

仕組みを示す28秒のビデオはこちらです

メニュー

• 概要
• 有効化
• 効果
• ホスト名の要件
• ローカルHTTPS
• テスト
• ACMEチャレンジ
• オンデマンドTLS
• エラー
• ストレージ
• ワイルドカード証明書

概要

デフォルトでは、CaddyはすべてのサイトをHTTPS経由で提供します。

• Caddyは、IPアドレスとローカル/内部ホスト名を、ローカルで自動的に信頼される自己署名証明書を使用してHTTPS経由で提供します（許可されている場合）。
  • 例：localhost、127.0.0.1
• Caddyは、Let's Encrypt やZeroSSL などのパブリックACME CAからの証明書を使用して、パブリックDNS名をHTTPS経由で提供します。
  • 例：example.com、sub.example.com、*.example.com

Caddyは、管理されているすべての証明書を更新し、HTTP（デフォルトポート80）をHTTPS（デフォルトポート443）に自動的にリダイレクトします。

ローカルHTTPSの場合

• Caddyは、独自のルート証明書をトラストストアにインストールするためにパスワードを要求する場合があります。これはルートごとに1回だけ発生します。いつでも削除できます。
• CaddyのルートCA証明書を信頼せずにサイトにアクセスするクライアントは、セキュリティエラーを表示します。

パブリックドメイン名の場合

• ドメインのA/AAAAレコードがサーバーを指している場合、
• ポート80と443が外部に開いており、
• Caddyがそれらのポートにバインドできる（またはそれらのポートがCaddyに転送される）場合、
• データディレクトリが書き込み可能で永続的であり、
• 構成に関連する場所でドメイン名が表示される場合、

サイトは自動的にHTTPS経由で提供されます。それ以外に何もする必要はありません。うまくいきます！

HTTPSは共有のパブリックインフラストラクチャを利用するため、サーバー管理者として、このページの残りの情報を理解し、不必要な問題を回避し、問題が発生したときにトラブルシューティングを行い、高度なデプロイを適切に構成できるようにする必要があります。

有効化

Caddyは、サービスを提供しているドメイン名（つまり、ホスト名）またはIPアドレスを認識すると、暗黙的に自動HTTPSをアクティブ化します。Caddyの実行方法または構成方法に応じて、ドメイン/IPをCaddyに伝えるさまざまな方法があります。

• サイトアドレスはCaddyfileにあります
• ホストマッチャーは、JSONルートの最上位にあります
• --domainや--fromなどのコマンドラインフラグ
• 自動化証明書ローダー

次のいずれかは、自動HTTPSの有効化を全体的または部分的に妨げます

• JSON経由またはCaddyfile経由で明示的に無効にする
• 構成にホスト名またはIPアドレスを提供しない
• HTTPポートのみをリッスンする
• Caddyfileのサイトアドレスにhttp://を付ける
• 証明書を手動でロードする（ignore_loaded_certificatesが設定されている場合を除く）

特殊なケース

• .ts.netで終わるドメインは、Caddyによって管理されません。代わりに、Caddyは、ローカルで実行されているTailscale インスタンスからハンドシェイク時にこれらの証明書を取得しようとします。これには、TailscaleアカウントでHTTPSが有効になっていること と、Caddyプロセスがrootとして実行されているか、またはCaddyユーザーに証明書を取得する権限を与えるようにtailscaledを構成する必要があります。

効果

自動HTTPSが有効になっている場合、次のようになります

• すべての適格なドメイン名に対して証明書が取得および更新されます
• HTTPはHTTPSにリダイレクトされます（これはHTTPポート80を使用します）

自動HTTPSは明示的な構成を上書きせず、それを補強するだけです。

HTTPポートでリッスンするサーバーが既にある場合、HTTP->HTTPSリダイレクトルートは、ホストマッチャーを持つルートの後、ユーザー定義のキャッチオールルートの前に挿入されます。

必要に応じて、自動HTTPSをカスタマイズまたは無効にすることができます。たとえば、特定のドメイン名をスキップしたり、リダイレクトを無効にしたりできます（Caddyfileの場合は、グローバルオプションでこれを行います）。

ホスト名の要件

すべてのホスト名（ドメイン名）は、次の場合は完全に管理された証明書の資格があります

• 空ではない
• 英数字、ハイフン、ドット、ワイルドカード（*）のみで構成される
• ドットで始まったり終わったりしない（RFC 1034）

さらに、ホスト名は、次の場合は公開的に信頼された証明書の資格があります

• localhost（.localhost、.local、.home.arpa TLDを含む）ではない
• IPアドレスではない
• 左端のラベルとして単一のワイルドカード*のみを持っている

ローカルHTTPS

Caddyは、内部およびローカルホストを含む、指定されたホスト（ドメイン、IP、またはホスト名）を持つすべてのサイトに対して自動的にHTTPSを使用します。一部のホストは、公開されていない（例：127.0.0.1、localhost）か、一般的に公開的に信頼された証明書の資格がない（例：IPアドレス-それらの証明書を取得できますが、一部のCAからのみ）。これらは、無効にされていない限り、HTTPS経由で提供されます。

非公開サイトをHTTPS経由で提供するために、Caddyは独自の証明機関（CA）を生成し、それを使用して証明書に署名します。信頼チェーンは、ルート証明書と中間証明書で構成されます。リーフ証明書は中間証明書によって署名されます。これらは、Caddyのデータディレクトリのpki/authorities/localに保存されます。

CaddyのローカルCAは、Smallstepライブラリ によって強化されています。

ローカルHTTPSはACMEを使用せず、DNS検証も実行しません。ローカルマシンでのみ機能し、CAのルート証明書がインストールされている場合にのみ信頼されます。

CAルート

ルートの秘密キーは、暗号化によって保護された擬似乱数ソースを使用して一意に生成され、制限された権限でストレージに保持されます。署名タスクを実行するためだけにメモリにロードされ、その後、スコープを離れてガベージコレクションされます。

Caddyは、ルートで直接署名するように構成できます（非準拠クライアントをサポートするため）が、これはデフォルトで無効になっており、ルートキーは中間署名にのみ使用されます。

ルートキーが初めて使用されると、Caddyはシステムローカルトラストストアにインストールしようとします。そうする権限がない場合は、パスワードを要求します。この動作は、必要ない場合は構成で無効にできます。特権のないユーザーとして実行しているために失敗した場合は、caddy trustを実行して、特権ユーザーとしてインストールを再試行できます。

CaddyのルートCAがインストールされると、ローカルトラストストアに「Caddy Local Authority」として表示されます（別の名前を構成していない場合）。必要に応じていつでもアンインストールできます（caddy untrustコマンドを使用すると簡単になります）。

ローカルトラストストアへの証明書の自動インストールは、便宜上のためであり、特にコンテナが使用されている場合や、Caddyが特権のないシステムサービスとして実行されている場合は、機能することが保証されていないことに注意してください。最終的に、内部PKIに依存している場合、CaddyのルートCAが必要なトラストストアに適切に追加されていることを確認するのはシステム管理者の責任です（これはWebサーバーの範囲外です）。

CA中間

中間証明書とキーも生成され、リーフ（個々のサイト）証明書の署名に使用されます。

ルート証明書とは異なり、中間証明書は有効期間が非常に短く、必要に応じて自動的に更新されます。

テスト

Caddyの構成をテストまたは実験するには、ACMEエンドポイントを変更してステージングまたは開発URLにしてください。そうしないと、レート制限に達する可能性があり、どのレート制限に達したかによっては、最大1週間HTTPSへのアクセスがブロックされる可能性があります。

CaddyのデフォルトのCAの1つはLet's Encrypt であり、同じレート制限 の影響を受けないステージングエンドポイント があります

https://acme-staging-v02.api.letsencrypt.org/directory

ACMEチャレンジ

公開的に信頼されたTLS証明書を取得するには、公開的に信頼されたサードパーティの認証機関からの検証が必要です。最近では、この検証プロセスはACMEプロトコル で自動化されており、以下に示す3つの方法（「チャレンジタイプ」）のいずれかで実行できます。

最初の2つのチャレンジタイプはデフォルトで有効になっています。複数のチャレンジが有効になっている場合、Caddyは特定のチャレンジへの偶発的な依存を避けるために、ランダムに1つを選択します。時間の経過とともに、最も成功するチャレンジタイプを学習し、最初に優先するようになりますが、必要に応じて他の利用可能なチャレンジタイプにフォールバックします。

HTTPチャレンジ

HTTPチャレンジは、候補となるホスト名のA/AAAAレコードの権威DNSルックアップを実行し、次にHTTPを使用してポート80経由で一時的な暗号リソースを要求します。CAが期待されるリソースを確認すると、証明書が発行されます。

このチャレンジでは、ポート80が外部からアクセス可能である必要があります。Caddyがポート80でリッスンできない場合は、ポート80からのパケットをCaddyのHTTPポートに転送する必要があります。

このチャレンジはデフォルトで有効になっており、明示的な設定は必要ありません。

TLS-ALPNチャレンジ

TLS-ALPNチャレンジは、候補となるホスト名のA/AAAAレコードの権威DNSルックアップを実行し、次に特別なServerNameおよびALPN値を含むTLSハンドシェイクを使用して、ポート443経由で一時的な暗号リソースを要求します。CAが期待されるリソースを確認すると、証明書が発行されます。

このチャレンジでは、ポート443が外部からアクセス可能である必要があります。Caddyがポート443でリッスンできない場合は、ポート443からのパケットをCaddyのHTTPSポートに転送する必要があります。

このチャレンジはデフォルトで有効になっており、明示的な設定は必要ありません。

DNSチャレンジ

DNSチャレンジは、候補となるホスト名のTXTレコードの権威DNSルックアップを実行し、特定の値を持つ特別なTXTレコードを探します。CAが期待される値を確認すると、証明書が発行されます。

このチャレンジは、ポートを開放する必要はなく、証明書を要求するサーバーが外部からアクセスできる必要もありません。ただし、DNSチャレンジには設定が必要です。Caddyは、ドメインのDNSプロバイダーにアクセスして特別なTXTレコードを設定（およびクリア）するための資格情報を知っている必要があります。DNSチャレンジが有効になっている場合、他のチャレンジはデフォルトで無効になります。

ACME CAはチャレンジ検証のためにTXTレコードをルックアップする際にDNS標準に従うため、CNAMEレコードを使用して、チャレンジへの応答を他のDNSゾーンに委任できます。これにより、_acme-challengeサブドメインを別のゾーンに委任できます。これは、DNSプロバイダーがAPIを提供していない場合や、CaddyのDNSプラグインの1つでサポートされていない場合に特に役立ちます。

DNSプロバイダーのサポートは、コミュニティの取り組みです。プロバイダーのDNSチャレンジを有効にする方法については、wikiをご覧ください。

オンデマンドTLS

Caddyは、設定ロード時ではなく、それを必要とする最初のTLSハンドシェイク中に新しい証明書を動的に取得する、オンデマンドTLSと呼ばれる新しいテクノロジーを開発しました。重要なことに、これは設定でドメイン名を事前にハードコーディングする必要がありません。

多くの企業は、数万のサイトを提供する場合、より低コストで、運用上の頭痛の種なしにTLS展開を拡張するために、この独自の機能に依存しています。

オンデマンドTLSは、以下の場合に役立ちます。

• サーバーを起動またはリロードするときにすべてのドメイン名がわからない場合、
• ドメイン名がすぐに適切に設定されない可能性がある場合（DNSレコードがまだ設定されていない場合）、
• ドメイン名を制御できない場合（例：顧客のドメイン）。

オンデマンドTLSが有効になっている場合、証明書を取得するために設定でドメイン名を指定する必要はありません。代わりに、Caddyがまだ証明書を持っていないサーバー名（SNI）のTLSハンドシェイクを受信すると、ハンドシェイクは保留され、Caddyがハンドシェイクを完了するために使用する証明書を取得します。遅延は通常数秒しかなく、最初のハンドシェイクのみが遅くなります。証明書はキャッシュされて再利用され、更新はバックグラウンドで実行されるため、今後のすべてのハンドシェイクは高速です。今後のハンドシェイクでは、証明書を更新するためにメンテナンスがトリガーされる場合がありますが、このメンテナンスは証明書がまだ期限切れになっていない場合はバックグラウンドで実行されます。

オンデマンドTLSの使用

オンデマンドTLSは、不正使用を防ぐために有効化し、制限する必要があります。

オンデマンドTLSの有効化は、JSON設定を使用している場合はTLS自動化ポリシーで、またはCaddyfileを使用している場合はtlsディレクティブを使用したサイトブロックで行われます。

この機能の不正使用を防ぐには、制限を設定する必要があります。これは、JSON設定のautomationオブジェクト、またはCaddyfileのon_demand_tlsグローバルオプションで行います。制限は「グローバル」であり、サイトごとまたはドメインごとに設定することはできません。主な制限は、「許可を求める」エンドポイントであり、Caddyはそれに対してHTTPリクエストを送信して、ハンドシェイク内のドメインの証明書を取得および管理する許可があるかどうかを確認します。これは、たとえば、データベースのアカウントテーブルをクエリして、顧客がそのドメイン名でサインアップしたかどうかを確認できる内部バックエンドが必要になることを意味します。

CAが証明書を発行できる速度に注意してください。数秒以上かかる場合、ユーザーエクスペリエンスに悪影響を与えます（最初のクライアントのみ）。

遅延性とその不正使用を防ぐために必要な追加設定のため、実際のユースケースが上記で説明されている場合にのみ、オンデマンドTLSを有効にすることをお勧めします。

オンデマンドTLSの効果的な使用に関する詳細については、wikiの記事を参照してください。

エラー

Caddyは、証明書管理でエラーが発生した場合でも、続行するように最善を尽くします。

デフォルトでは、証明書管理はバックグラウンドで実行されます。これは、起動をブロックしたり、サイトを遅くしたりしないことを意味します。ただし、すべての証明書が利用可能になる前にサーバーが実行されることも意味します。バックグラウンドで実行することで、Caddyは長期間にわたって指数バックオフで再試行できます。

証明書の取得または更新でエラーが発生した場合の処理は次のとおりです。

1. Caddyは、偶然のエラーに備えて、短時間の停止後に一度再試行します。
2. Caddyは一時停止し、次に有効になっているチャレンジタイプに切り替えます。
3. 有効になっているすべてのチャレンジタイプが試行された後、次に設定されている発行者を試行します。
   • Let's Encrypt
   • ZeroSSL
4. すべての発行者が試行された後、指数バックオフします。
   • 試行間隔は最大1日。
   • 最大30日間。

Let's Encryptで再試行している間、Caddyはレート制限の問題を回避するために、ステージング環境 に切り替えます。これは完璧な戦略ではありませんが、一般的には役立ちます。

ACMEチャレンジには少なくとも数秒かかり、内部レート制限は誤った不正使用を軽減するのに役立ちます。Caddyは、ユーザーまたはCAが構成した設定に加えて、内部レート制限を使用します。これにより、Caddyに数百万のドメイン名が記載されたプレートを渡すことができ、それらすべてに対して徐々に（ただし、可能な限り高速に）証明書を取得します。Caddyの内部レート制限は現在、ACMEアカウントごとに10秒あたり10試行です。

リソースのリークを回避するために、設定が変更されると、Caddyは処理中のタスク（ACMEトランザクションを含む）を中止します。Caddyは頻繁な設定リロードを処理できますが、これのような運用上の考慮事項に留意し、設定変更をバッチ処理してリロードを減らし、Caddyがバックグラウンドで証明書の取得を実際に完了する機会を与えることを検討してください。

発行者のフォールバック

Caddyは、証明書を正常に取得できない場合に、他のCAへの完全な冗長自動フェイルオーバーをサポートする最初の（そして今のところ唯一の）サーバーです。

デフォルトでは、Caddyは2つのACME互換CAを有効にします。Let's Encrypt とZeroSSL です。CaddyがLet's Encryptから証明書を取得できない場合は、ZeroSSLを試行します。両方が失敗した場合は、バックオフして後で再試行します。設定では、Caddyが証明書を取得するために使用する発行者を、ユニバーサルに、または特定の名前に対してカスタマイズできます。

ストレージ

Caddyは、公開証明書、秘密鍵、およびその他のアセットを、構成されたストレージ機能（または構成されていない場合はデフォルトのストレージ機能）に保存します（詳細についてはリンクを参照）。

デフォルト設定を使用して知っておくべき主なことは、$HOMEフォルダーが書き込み可能で永続的である必要があるということです。トラブルシューティングに役立つように、--environフラグが指定されている場合、Caddyは起動時に環境変数を印刷します。

同じストレージを使用するように構成されているCaddyインスタンスは、それらのリソースを自動的に共有し、クラスターとして証明書管理を調整します。

ACMEトランザクションを試行する前に、Caddyは構成されたストレージをテストして、書き込み可能で十分な容量があることを確認します。これにより、不要なロック競合を減らすのに役立ちます。

ワイルドカード証明書

Caddyは、ワイルドカード名を持つサイトを提供するように構成されている場合、ワイルドカード証明書を取得および管理できます。サイト名は、左端のドメインラベルのみがワイルドカードである場合に、ワイルドカードの対象となります。たとえば、*.example.comは対象となりますが、sub.*.example.com、foo*.example.com、*bar.example.com、および*.*.example.comは対象となりません。

Caddyfileを使用している場合、Caddyは証明書のサブジェクト名に関してサイト名を文字通りに解釈します。言い換えれば、sub.example.comとして定義されたサイトは、Caddyにsub.example.comの証明書を管理させ、*.example.comとして定義されたサイトは、Caddyに*.example.comのワイルドカード証明書を管理させます。これは、共通のCaddyfileパターンページで実証されています。異なる動作が必要な場合、JSON設定では、証明書のサブジェクトとサイト名（「ホストマッチャー」）をより正確に制御できます。

ワイルドカード証明書は広範囲の権限を表すため、多数のサブドメインがあり、それらの個々の証明書を管理すると、PKIに負荷がかかるか、CAによって強制されるレート制限に達する場合にのみ使用する必要があります。

注：Let's Encryptでは、ワイルドカード証明書を取得するためにDNSチャレンジが必要です。