이 스레드의 핵심은 “ZimaOS의 HTTPS”가 실제로는 하나 이상의 신뢰 문제를 설명한다는 점입니다. ZimaOS 대시보드에서 사용하는 인증서가 다른 호스트 이름이나 포트에서 실행되는 모든 Docker 애플리케이션의 인증서가 되는 것은 아닙니다.
대시보드 HTTPS와 앱 HTTPS를 구분하세요
현재 ZimaOS HTTPS 인증서 가이드에서도 같은 경계를 설명합니다. 로컬 ZimaOS 인증서를 신뢰하도록 설정하면 대시보드 호스트 이름에는 적용될 수 있지만, Obsidian, Jellyfin, Plex와 같은 애플리케이션은 별도의 서비스입니다. ZimaOS의 Obsidian은 브라우저 기반 앱에 자체 HTTPS 및 보안 요구 사항이 있을 수 있다는 점을 보여 주는 유용한 예입니다.
ZimaBoard 2 하드웨어는 현재 ZimaBoard 2의 하드웨어 환경을 제공하지만, 인증서 문제 자체는 보드의 한계가 아니라 호스트 이름, 신뢰 체인, 리버스 프록시와 관련된 문제입니다.
CER 파일을 가져와도 브라우저 문제가 해결되지 않을 수 있는 이유
신뢰할 수 있는 인증서는 브라우저가 접속하는 호스트 이름과 일치해야 하며, 해당 클라이언트가 허용하는 신뢰 앵커로 이어지는 인증서 체인을 갖춰야 합니다. 인증서 하나를 가져온다고 해서 서로 관련 없는 애플리케이션 포트가 그 인증서를 자동으로 상속하는 것은 아닙니다. 브라우저가 IP 주소로 접속하는데 인증서에는 다른 호스트가 지정되어 있다면 신뢰 문제가 계속 발생할 수 있습니다.
공인 인증서가 필요한 경우
Let's Encrypt의 Let's Encrypt 챌린지 설명에 따르면, 공인 인증서를 발급받으려면 ACME 챌린지를 통해 도메인 이름을 제어하고 있음을 입증해야 합니다. 실제 호스트 이름을 통해 공개하려는 서비스의 경우, 리버스 프록시가 TLS를 종료하고 트래픽을 내부 앱 포트로 전달하도록 구성할 수 있습니다.
Cloudflare의 Cloudflare Tunnel 설정 역시 Tunnel을 통해 공개 호스트 이름을 로컬 서비스에 연결합니다. 이는 로컬 인증서 신뢰와는 다른 문제를 해결할 수 있습니다. 즉, 도메인 이름에서 내부 애플리케이션으로 연결되는 관리형 경로를 제공합니다.
자물쇠 아이콘만을 위해 관리자 포트를 공개하지 마세요
브라우저 경고를 없애기 위해 ZimaOS 또는 애플리케이션 관리자 포트를 공용 인터넷에 직접 노출하지 마세요. 요구 사항이 로컬 전용 신뢰인지, 원격 액세스인지, 공용 HTTPS인지 먼저 결정한 다음, 해당 경계에 맞게 인증서와 프록시 경로를 설계해야 합니다.
결론
커뮤니티 스레드는 ZimaOS CER이 손상되었다는 증거가 아닙니다. 더 가능성 높은 원인은 대시보드 인증서와 별도의 애플리케이션 서비스를 하나의 HTTPS 엔드포인트로 취급했다는 점입니다. 대시보드 인증서는 해당 인증서가 적용되는 호스트 이름에 대해서만 신뢰하도록 설정하고, 필요한 경우 다른 앱에는 올바르게 구성된 리버스 프록시 또는 도메인 인증서를 사용하세요.
