セルフホスト型証明書はローカルでは更新できるのに、インターネット経由では失敗するのはなぜですか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Why Does a Self-Hosted Certificate Renew Locally but Fail From the Internet?

証明書はローカルでは更新できても、ACME認証局がインターネットに公開された経路を通じてチャレンジに到達または検証できない場合、外部からは更新に失敗することがあります。

セルフホスト型のNASやホームサーバーでは、ローカルでのドライランによってCertbot、acme.sh、またはリバースプロキシがチャレンジファイルを作成し、自身の設定にアクセスできることを確認できる場合があります。しかし、公開環境での発行には別の要件があります。権威DNSが正しいアドレスを指していること、選択したIPv4またはIPv6経路に到達できること、ルーターとファイアウォールが検証リクエストを転送すること、そしてリバースプロキシがリダイレクトやアプリケーションのルートに妨げられる前に、正確なチャレンジトークンを配信することが必要です。

ローカルクライアントの成功と公開ドメイン検証を切り分ける

更新ログを読み、実際に何が成功したのかを特定してください。ローカル設定のチェック、証明書の解析テスト、webrootへの書き込み、またはステージング環境へのリクエストが成功しても、外部の認証局がホームサーバーに到達したことの証明にはなりません。

Nginx Proxy Managerでよくあるケースでは、ローカルのプロキシインターフェースが正常に動作していてもHTTPチャレンジに失敗する場合、最初に確認すべき要件としてパブリックポート80への到達性が挙げられます。

チャレンジの種類、ホスト名、検証URL、解決されたアドレス、認証局から返された正確なエラーを記録してください。新しい証拠がないまま更新を何度も強制するのではなく、最初に発生した外部障害、つまりDNSルックアップ、TCP接続、HTTPステータス、トークンの不一致、または二次検証のどこで失敗したのかを起点に調査を続けます。

権威DNSのAおよびAAAAレコードと実際のサーバー経路を比較する

証明書に含まれるすべてのホスト名を権威DNS経由で問い合わせ、AおよびAAAAの応答を記録してください。それらをルーターの現在のパブリックIPv4、サーバーから到達可能なIPv6アドレス、そして実際にチャレンジを配信するプロキシと比較します。

Virtualminの更新事例では、公開されていたAAAAレコードが検証を壊れたIPv6経路へ送っていたため、そのレコードを削除した後にのみ成功しました。これは、壊れたAAAA検証経路が、IPv4構成が正常であってもそちらを優先させる可能性を示しています。

いずれかのアドレスファミリーに完全な到達性がない場合は、そのレコードを一時的に削除するか、ファイアウォール、ルーティング、リスナー、プロキシ経路を修復してください。発行を再試行する前に、すべての権威ネームサーバーが同じ最新レコードを返すことも確認します。

自宅外から正確なHTTPチャレンジURLをテストする

HTTP-01の場合は、設定済みの/.well-known/acme-challenge/パスに無害なテストファイルを配置し、モバイルデータ通信または別の外部ネットワークから、証明書のホスト名を使ってHTTP経由でリクエストしてください。

Home Assistantのセルフホスティングに関する報告では、サービス自体がローカルで動作していても、ISPによってブロックされたHTTPチャレンジがHTTP検証を妨げる仕組みが示されています。

外部からのリクエストは、認証、キャプティブページ、ルーターのログイン画面、アプリケーションの404、または到達不能な宛先へのリダイレクトを経由せず、正しいトークンに到達しなければなりません。TCPポート80が開かない場合は、ACMEクライアントを変更する前に、ISP、CGNAT、ルーターのポート転送、ホストのファイアウォール、プロキシのリスナーを確認してください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

リバースプロキシとwebrootが同じトークンを配信していることを確認する

ACMEクライアントが書き込むトークンのパスと、公開仮想ホストが使用するファイルシステムまたは一時レスポンダーを比較してください。コンテナ、バインドマウント、分離されたプロキシネットワークによって、クライアントが一方のディレクトリに書き込み、NGINXやCaddyが別のディレクトリを配信している場合があります。

外部からのチャレンジリクエストを1回実行している間、プロキシのアクセスログを確認してください。リクエストが到達しているのに404を返す場合は、ルートまたはwebrootの不一致が原因です。401または403の場合は認証またはフィルタリング、502の場合はチャレンジパスに不要なアップストリーム依存があることを示します。

チャレンジのロケーションを通常のアプリケーションルーティングより優先させ、ホスト名を保持してください。リダイレクトは単純にし、外部から検証します。更新時に停止している可能性のあるバックエンドアプリケーションへトークンを転送しないでください。

CGNAT、ファイアウォール、複数地点からの到達性を確認する

ルーターのWANアドレスとパブリックIPv4アドレスを比較し、複数の外部ネットワークから検証用ポートに到達できることを確認してください。ローカルのNATループバックテストが成功しても、インターネットからの未承諾トラフィックがルーターに到達するとは限りません。

認証局は、ルーティング攻撃のリスクを減らすため、複数のネットワーク拠点から検証することが増えています。複数の検証拠点に関する研究では、ある国、ISP、またはテストサービスから到達できる経路でも、より広範な検証では失敗する可能性が説明されています。

検証中は、チャレンジ用の限定された経路からジオブロッキング、国別フィルター、一時的な拒否ルール、レート制限を解除してください。ホーム接続がCGNATの背後にある場合、またはISPが必要なポートをブロックしている場合は、関係のないファイアウォールルールを弱めるのではなく、DNS-01またはアウトバウンド型の検証方式を使用してください。