SSL 갱신 후 Zimbra 관리 콘솔에서 발생하는 404 오류(찾을 수 없음) 해결 방법

이는 실제 사건이 아닌 예시입니다. 조던은 가상의 Zimbra 서버(주소는 명시되지 않음)를 관리합니다 mail.example.com. SSL/TLS 인증서를 갱신한 후, 조던은 저장된 관리 콘솔 북마크를 열었는데 "404 찾을 수 없음" 페이지가 나타났습니다. 인증서 갱신이 원인일 수도 있지만, 404 오류 자체만으로는 인증서가 유효하지 않다고 단정할 수 없습니다. 주소가 잘못된 포트, 프록시, 호스트 이름 또는 URL 경로로 연결되었을 가능성이 있습니다.

이 예시에서 Jordan이 제시하는 가장 안전한 순서는 의도한 관리 콘솔 URL을 확인하고, 직접 및 프록시 엔드포인트를 각각 테스트하고, Zimbra 서비스 상태와 배포된 인증서를 확인한 다음, 문제가 있는 경우에만 구성 요소를 재배포하거나 재시작하는 것입니다. 설치 버전에 따른 지침을 따르십시오. Zimbra 포트 및 인증서 절차는 릴리스 버전과 서버가 Zimbra 프록시, 별도의 로드 밸런서 또는 외부 역방향 프록시를 사용하는지 여부에 따라 다를 수 있습니다.

SSL 갱신 후 404 오류가 발생하는 이유는 무엇일까요?

브라우저의 명시적인 HTTP 404 응답은 일반적으로 HTTP 서버가 요청에 응답했지만 일치하는 리소스나 경로를 찾지 못했음을 의미합니다. 따라서 호스트 이름, 포트, URL 경로, 가상 호스트 및 프록시 경로를 확인하는 것이 중요합니다. 이는 브라우저 인증서 경고나 TLS 핸드셰이크 실패와는 다릅니다. 하지만 리버스 프록시나 웹 애플리케이션 방화벽 자체도 호스트 또는 경로가 일치하지 않을 때 404를 반환할 수 있으므로, 상태 코드만으로는 어느 계층이 원인인지 정확히 파악할 수 없습니다.

Zimbra는 기본적으로 TCP 포트를 통해 직접 관리 콘솔에 접속할 수 있도록 문서화되어 있습니다 7071. Zimbra 프록시를 구성하여 관리 콘솔에 프록시 연결을 설정한 경우, 문서화된 기본 프록시 포트는 입니다 9071. 이 포트는 선택 사항이며 사용자 지정이 가능합니다. 표준 웹메일 주소(포트)는 443직접 관리 콘솔의 엔드포인트와 자동으로 동일하지 않습니다. Zimbra 관리 콘솔 URL 안내 및 Zimbra의 포트 참조 정보를 사용자의 구성과 비교하여 확인하십시오.

이 오류를 어떻게 해결해야 할까요?

1. 관리자 콘솔의 정확한 주소를 확인하십시오.

웹메일 URL이 관리 콘솔 URL과 동일하다고 가정하지 말고, 배포 환경에 맞게 구성된 호스트 이름과 포트를 사용하십시오. 일반적인 직접 연결의 경우, Zimbra는 다음과 같은 형식의 URL을 제공합니다 https://server.example.com:7071. 콘솔에 Zimbra 프록시를 활성화한 관리자는 대신 프록시 호스트 이름과 포트(일반적으로 )를 사용할 수 있습니다 https://proxy.example.com:9071. 임의로 경로를 추가하지 말고 /admin, 설치 또는 관리자 설명서에 명시된 주소를 사용하십시오.

조던의 가상 사례에서 기존 북마크는 443번 포트의 공용 웹메일 호스트 이름을 가리킵니다. 조던은 이를 문서화되거나 구성된 관리자 엔드포인트와 비교할 것입니다. 웹메일 호스트에서 404 오류가 발생한다고 해서 짐브라 관리 콘솔 자체가 다운된 것은 아닙니다. 7071번 포트가 공용 인터넷에서 의도적으로 차단된 경우, 승인된 네트워크 또는 로컬 환경에서만 테스트해야 하며, 단순히 테스트를 위해 공개적으로 열지 마십시오. 짐브라의 프록시 지침에서는 관리자가 프록시 엔드포인트를 사용하는 경우 7071번 포트에 대한 직접 액세스를 제한할 것을 권장합니다.

2. 직접 경로와 프록시 경로를 비교하십시오.

올바른 호스트 이름, 스키마 및 포트를 사용하여 한 번에 하나의 경로만 테스트하십시오. 허용된 네트워크에서 7071번 포트로 직접 액세스가 작동하지만 9071번 포트의 프록시 경로에서 404 오류가 발생하는 경우 프록시의 관리 콘솔 구성 및 호스트 이름 라우팅에 집중하십시오. 직접 경로도 실패하는 경우 사서함 서버와 해당 관리 콘솔 서비스에 배포된 인증서를 확인하십시오. Zimbra 경로가 모두 작동하지만 공용 URL에서 여전히 404 오류가 발생하는 경우 Zimbra 앞에 있는 외부 로드 밸런서, 역방향 프록시, CDN 또는 웹 애플리케이션 방화벽을 조사하십시오.

이 비교는 진단 목적으로 사용해야 하며, 새로운 네트워크 액세스를 활성화하는 명령으로 사용해서는 안 됩니다. 직접 포트 차단은 의도적인 보안 제어일 수 있습니다. Zimbra 관리 콘솔 프록시 설정 가이드 에서는 선택 사항인 9071 수신자에 대해 설명하고 있으며, 사서함 서버의 관리 콘솔은 일반적으로 7071 포트를 사용한다고 명시하고 있습니다.

3. Zimbra 서비스 및 프록시 로그를 확인하세요.

설치에 적합한 관리자 계정으로 Zimbra 호스트에 로그인한 다음 서비스 상태를 확인하십시오. 다음 상태 명령은 읽기 전용입니다.

su - zimbra
zmcontrol status
zmproxyctl status

zmcontrol status이 명령은 Zimbra 구성 요소 상태를 보고합니다. zmproxyctl statusZimbra Proxy가 설치된 경우 유용하지만, 명령을 사용할 수 없거나 토폴로지에 Zimbra Proxy가 없는 경우 이 단계를 건너뛰고 해당 URL을 제공하는 실제 구성 요소를 확인하십시오. 메일함 또는 프록시 구성 요소가 중지되면 경로 오류가 발생할 수 있지만, 특정 URL에서 404 오류가 발생한다고 해서 전체 서버를 재시작할 필요는 없습니다.

프록시를 통해 전송된 요청의 경우, Zimbra는 유용한 프록시 로그를 식별합니다 . 요청 시간 /opt/zimbra/log/nginx.access.log과 /opt/zimbra/log/nginx.log요청된 호스트/경로를 기록된 응답과 비교해 보세요. 요청이 Zimbra의 프록시 로그에 전혀 나타나지 않으면 404 오류가 상위 로드 밸런서 또는 다른 프런트엔드 서비스에서 발생했을 수 있습니다. Zimbra 프록시 가이드 및 문제 해결 섹션을 참조하십시오 .

4. 각 엔드포인트가 제시하는 인증서를 확인합니다.

디스크에 갱신된 인증서가 모든 Zimbra 서비스에서 현재 로드된 인증서와 반드시 동일한 것은 아닙니다. Zimbra 호스트에서 설치된 릴리스에서 지원하는 구문을 사용하여 인증서 관리자의 배포된 인증서 검사를 실행하십시오.

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

오류가 발생한 경로를 처리하는 서비스의 인증서 세부 정보(유효 기간, 호스트 이름 또는 주체 대체 이름 포함)를 검토하십시오. 브라우저가 외부 TLS 종료자를 통해 443번 포트에 도달하는 경우 해당 포트의 인증서 및 라우팅 구성도 확인하십시오. Zimbra가 해당 공개 인증서를 제공하는 구성 요소가 아닐 수 있습니다. 다중 서버 배포 환경에서는 관련 프록시 및 메일함 노드를 확인하십시오. Zimbra는 viewdeployedcrt로컬 서버를 보고하므로 한 노드만 확인한다고 해서 모든 노드에 갱신된 인증서가 있다고 단정할 수는 없습니다.

올바른 인증서가 배포되었는데도 HTTP 404 오류만 발생하는 경우, 인증서를 반복적으로 갱신하기보다는 경로 및 프록시 라우팅 문제를 조사하십시오. 배포된 인증서가 만료되었거나, 유효하지 않거나, 개인 키 또는 인증서 체인과 일치하지 않는 경우, 사용 중인 Zimbra 버전에 맞는 인증서 배포 경로를 따르십시오.

5. 점검 결과 필요하다고 판단될 때만 인증서를 재배포하십시오.

인증서를 변경하기 전에 일치하는 개인 키, 갱신된 서버 인증서, 그리고 공급업체에서 제공한 전체 CA 체인을 모두 확보했는지 확인하십시오. 개인 키는 안전하게 보관하십시오. 조던의 가상 예시에서 파일 이름은 commercial.key, commercial.crt, ca_chain.crt입니다. 실제 서버 경로로 바꿔야 합니다. 아래 파일 이름은 예시일 뿐이며, Zimbra에서 자동으로 생성하는 파일이 아닙니다.

상용 인증서의 경우, Zimbra는 배포 전에 인증서가 키 및 체인과 일치하는지 확인하는 절차를 문서화하고 있습니다. 사용 중인 릴리스에 필요한 경로 및 사용자 권한에 맞게 명령어를 수정하십시오.

/opt/zimbra/bin/zmcertmgr verifycrt comm \
  /opt/zimbra/ssl/zimbra/commercial/commercial.key \
  /tmp/commercial.crt \
  /tmp/ca_chain.crt

검증 결과에서 키가 일치하고 인증서 체인이 유효한 것으로 확인되면 다음 단계로 진행하십시오. 검증에 실패하면 작업을 중단하고 키, 인증서 또는 중간 체인을 수정하십시오. 404 오류가 해결되는지 확인하기 위해 일치하지 않는 인증서를 배포하지 마십시오.

검증이 성공하면, 문서화된 상용 인증서 배포 패턴은 다음과 같습니다.

/opt/zimbra/bin/zmcertmgr deploycrt comm \
  /tmp/commercial.crt \
  /tmp/ca_chain.crt

이러한 명령은 모든 환경에 적용되는 인증서 갱신 지침이 아닙니다. Zimbra의 인증서 관련 문서에는 릴리스별 권한 참고 사항이 있으며, 다중 노드 배포 환경에서는 관련 트래픽을 처리하는 노드에 인증서를 설치하고 검증해야 합니다. 관리 콘솔 및 CLI 인증서 도구를 검토하고 , Let's Encrypt 기반 설정의 경우 최신 Zimbra Let's Encrypt 인증서 관련 지침을 참조하십시오. 이전 릴리스의 명령을 복사하여 사용할 때는 설치된 빌드와 일치하는지 반드시 확인하십시오.

6. 해당 서비스를 재시작한 후 두 엔드포인트를 모두 테스트하십시오.

Zimbra의 인증서 배포 안내에 따르면 새 인증서를 로드하려면 서비스를 재시작해야 합니다. 사용 중인 토폴로지와 릴리스 버전에 맞는 가장 간단한 재시작 옵션을 선택하십시오. Zimbra 프록시 인증서 또는 생성된 프록시 구성만 다시 로드해야 하는 경우 프록시 서비스 명령은 다음과 같습니다.

zmproxyctl restart

전체 zmcontrol restart서비스 재시작은 해당 호스트의 Zimbra 서비스에 영향을 미치며 메일 접속을 중단시킬 수 있습니다. 사용 중인 버전의 인증서 배포 절차에서 요구하는 경우 유지 관리 기간 동안 사용하고, 영향을 받는 모든 노드에 대해 계획하십시오. Zimbra의 인증서 가이드에는 단일 서버 상용 인증서 절차에서 전체 서비스 재시작에 대한 내용이 설명되어 있으며, 프록시 가이드에는 프록시 재시작 시 프록시 구성이 다시 생성된 후 프록시가 다시 시작된다고 설명되어 있습니다. 두 재시작 경로를 모두 자동으로 실행하지 마십시오.

선택한 서비스가 복구되면 동일한 URL을 다시 테스트합니다. 먼저 인증된 네트워크에서 의도한 직접 또는 프록시 관리 콘솔 주소를 테스트하고, 그 다음 공용 또는 로드 밸런싱된 URL을 테스트합니다. 예상되는 로그인 페이지가 로드되고, 브라우저에 호스트 이름에 대한 갱신된 인증서가 표시되며, 관련 로그에 해당 요청에 대한 경로 오류 또는 상위 오류가 더 이상 나타나지 않는지 확인합니다. 조던의 가상 예시에서 확인하는 것은 저장된 북마크가 이제 구성된 엔드포인트를 가리키는지 여부이며, 임의로 만든 테스트 결과가 나왔는지 여부를 확인하는 것이 아닙니다.

짐브라 외부를 언제 조사해야 할까요?

Zimbra의 직접 엔드포인트와 구성된 프록시 엔드포인트 모두에서 올바른 응답이 나오는데도 공용 URL에서 여전히 404 오류가 발생하는 경우, 외부 프런트엔드 또는 해당 가상 호스트 규칙에 문제가 있을 가능성이 높습니다. 리버스 프록시의 업스트림 호스트 이름 및 포트, TLS 종료 설정, 전달된 호스트 헤더, URL 재작성 규칙을 확인하십시오. 공용 인증서가 Zimbra 외부에서 종료되는 경우, Zimbra의 내부 인증서만 갱신해서는 해당 외부 수신기가 업데이트되지 않습니다.

Zimbra Proxy에서 제공하는 응답의 경우, 타임스탬프와 상태를 nginx.access.log로그의 세부 정보와 비교하십시오 nginx.log. 해당 로그에 응답이 없는 경우 외부 프록시 또는 로드 밸런서를 점검하십시오. 생성된 Zimbra NGINX 파일을 직접 편집하지 마십시오. Zimbra 프록시 서비스는 재시작 시 구성을 다시 생성하므로, 영구적인 변경 사항은 설치된 버전에 대해 지원되는 프록시 구성 방법을 따라야 합니다.

수리가 완료되었는지 어떻게 알 수 있나요?

• 이 북마크는 구성된 호스트 이름, 스키마, 포트 및 경로를 사용합니다.
• 의도된 관리 콘솔 엔드포인트가 승인된 네트워크에서 응답합니다. 의도적으로 차단된 직접 포트는 계속 차단된 상태로 유지됩니다.
• Zimbra의 관련 서비스가 실행 중이며 배포된 인증서가 호스트 이름 및 현재 유효 기간과 일치한다고 보고됩니다.
• 프록시 또는 외부 프런트엔드가 404 오류 대신 예상했던 관리 콘솔 페이지를 반환합니다.
• 로그를 보면 요청이 예상 구성 요소에 도달했으며, 다른 어떤 노드도 이전 인증서를 더 이상 제시하지 않는 것으로 나타납니다.

이 가이드 작성을 위해 참고한 Zimbra 공식 문서에 따르면 7071은 기본 직접 관리 콘솔 포트이고 9071은 선택적 프록시 관리 콘솔 포트입니다. 404 오류는 여러 계층에서 발생할 수 있으므로 이러한 기본값을 진단 단서로 활용하고 사용 중인 Zimbra 버전 및 토폴로지에서 실제 값을 확인하십시오.

공식 참고 자료

• Zimbra 관리 콘솔
• 짐브라 항구
• 관리 콘솔 프록시 활성화
• Zimbra 프록시 가이드
• 관리 콘솔 및 CLI 인증서 도구
• Let's Encrypt SSL 인증서 설치