ワイルドカードDNSレコードは、任意のサブドメインを単一のIPアドレスに自動的に解決することで、サービスの発行を容易にします。Nginx Proxy Manager (NPM) は、HTTPSでサービスを安全に公開するために数個のフィールドしか必要としないため、発行をさらに簡素化します。この自動化により、さまざまな認証方法を持つセルフホスト型ソフトウェアを実行する19個のプロキシホストが作成されました。特定された中心的な問題は、発行の容易さがアクセス制御に関する重要なセキュリティ上の決定を迂回してしまうことです。著者の目標は、サービスを完全に隠すことではなく、パブリックインフラストラクチャ上に構築されたプライベートネットワークからのみアクセスできるようにすることでした。ワイルドカードDNSレコードは、セットアップを簡素化しますが、本質的にセキュリティを提供するものではありません。NPMはLet's Encrypt証明書のためにHTTP-01チャレンジを使用するため、ポート80を開いたままにする必要があり、これはセキュリティ上の脆弱性です。DNS-01を介したワイルドカード証明書はポート80を閉じることができますが、DNSゾーンへの書き込みアクセスを許可する必要があります。サービスは、コンテナを共有Dockerネットワークに配置することで発行され、NPMが内部でリクエストをプロキシできるようになります。これにより、サービスはポートをホストに直接公開する必要がなくなり、セキュリティが向上します。同じVPS上のセルフホスト型プロキシゲートウェイは、トラフィックをNPMにルーティングし、VPSのパブリックIPからのインバウンドHTTPSとして表示されます。このゲートウェイの動作は、当初ルーティング障害と誤解されていましたが、セキュリティ設計に不可欠です。NPMは、ゲートウェイの内部Docker IPまたはVPSのパブリックIPからのリクエストのみを許可するNginx設定ブロックと、その後の基本的なHTTP認証を使用してアクセス制御を強制します。これにより、サービスがパブリックに解決可能で有効な証明書を持っていても、アクセスは制限されます。Let's Encryptチャレンジ用の特定の場所は、証明書検証に必要なため、インターネットに公開されたままです。ゲートウェイの管理パネルと設定配布エンドポイントという2つの重要なホストは、完全なゲートウェイ統合の前にアクセス可能である必要があるため、厳格なアクセス制御の例外です。サービスがユーザー接続プロファイルにサーバーアドレスを埋め込み、誤って間違ったアドレスを広告してしまったときに、重大な問題が発生しました。NPMはX-Forwarded-Forヘッダーを介して実際のクライアントIPを転送するため、サービスはこのヘッダーを自身のパブリックアドレスと解釈し、クライアントが間違ったサーバーに接続する原因となりました。著者のゲートウェイを使用した自身のテストでは常に正しい期待されるアドレスが表示されていたため、このバグは隠されていました。TLS終端はNPMで行われ、NPMとバックエンドコンテナ間のトラフィックはDockerネットワーク上で暗号化されていないHTTPとして送信されます。