このスレッドの要点は、「ZimaOS上のHTTPS」という表現が、実際には複数の信頼に関する問題を指しているということです。ZimaOSダッシュボードで使用される証明書が、別のホスト名やポートで動作するすべてのDockerアプリケーションの証明書になるわけではありません。
ダッシュボードのHTTPSとアプリのHTTPSを分けて考える
現在のZimaOS HTTPS証明書ガイドでも、同じ境界について説明しています。ローカルのZimaOS証明書を信頼することでダッシュボードのホスト名には対応できますが、Obsidian、Jellyfin、Plexなどのアプリケーションは別のサービスです。ZimaOS上のObsidianは、ブラウザベースのアプリが独自のHTTPSやセキュリティ要件を持つ場合があることを示すよい例です。
ZimaBoard 2のハードウェアは、現在のZimaBoard 2のハードウェア状況を示すものですが、証明書の問題自体はボードの制限ではなく、ホスト名、信頼チェーン、リバースプロキシに関する問題です。
CERファイルをインポートしてもブラウザの問題が解決しない場合がある理由
信頼される証明書は、ブラウザが開いているホスト名と一致し、そのクライアントが受け入れるトラストアンカーまで信頼チェーンがつながっていなければなりません。1つの証明書をインポートしても、関係のない別のアプリケーションポートがその証明書を自動的に引き継ぐわけではありません。証明書が別のホスト名を対象としているのに、ブラウザがIPアドレスを開いている場合も、信頼に失敗する可能性があります。
パブリック証明書が必要な場合
Let's Encryptのチャレンジでは、パブリック証明書の発行には、ACMEチャレンジを通じてドメイン名の管理権限を証明する必要があると説明されています。実際のホスト名を使って公開したいサービスでは、リバースプロキシでTLSを終端し、内部のアプリケーションポートへトラフィックを転送できます。
CloudflareのCloudflare Tunnelの設定も同様に、Tunnelを介してパブリックホスト名をローカルサービスに割り当てます。これはローカルの証明書信頼とは別の問題を解決するものです。つまり、ドメイン名から内部アプリケーションまでをつなぐ、管理された経路を提供します。
南京錠アイコンのためだけに管理ポートを公開しない
ブラウザの警告を消すためだけに、ZimaOSやアプリケーションの管理ポートをパブリックインターネットへ直接公開しないでください。必要なのがローカル限定の信頼、リモートアクセス、パブリックHTTPSのいずれなのかを判断し、その境界に合った証明書とプロキシ経路を設計してください。
結論
コミュニティのスレッドは、ZimaOSのCERが壊れていることの証拠ではありません。より可能性が高いのは、ダッシュボードの証明書と別のアプリケーションサービスが、1つのHTTPSエンドポイントとして扱われていたことです。ダッシュボードの証明書は、その証明書が対象とするホスト名に対してのみ信頼し、必要に応じて、他のアプリには適切に設定したリバースプロキシまたはドメイン証明書を使用してください。
