Zimbra 서버에 상용 SSL 인증서를 설치하는 방법

Zimbra에서 사용하는 상용 SSL 인증서는 인증 기관에서 인증서가 올바르게 발급되었다고 하더라도 여러 가지 까다로운 문제로 인해 오류가 발생할 수 있습니다. 가장 흔한 문제는 인증서 자체의 문제가 아니라, 개인 키가 반환된 인증서와 일치하지 않거나, 중간 CA가 누락되었거나, 인증서의 주체 대체 이름(SAN)에 호스트 이름이 없거나, 관리자가 인증서 체인을 검증하기 전에 파일을 배포한 경우입니다.

이 작업을 처리하는 가장 안전한 방법은 단일 "인증서 설치" 명령이 아닌 일련의 검사 단계로 진행하는 것입니다. Zimbra에서 제공하는 인증서 도구를 사용하면 인증서 서명 요청(CSR)을 생성하고, 개인 키와 CA 체인을 검증하고, Zimbra 서비스에 인증서를 배포하고, 현재 활성화된 인증서를 표시할 수 있습니다. Zimbra 기술 센터의 관리 콘솔 및 CLI 인증서 도구 가이드zmcertmgr 에서 이러한 명령에 대한 자세한 내용을 확인할 수 있습니다 .

성공적인 Zimbra SSL 설치의 모습은 다음과 같습니다.

변경하기 전에 원하는 결과를 먼저 정의하십시오. 올바른 배포는 다음 조건을 모두 충족해야 합니다.

  • 인증서의 SAN 목록에는 클라이언트가 실제로 사용하는 모든 공개 호스트 이름(예: )이 포함됩니다 mail.example.com.
  • 발급된 인증서는 상용 인증서에 저장된 개인 키와 일치합니다.
  • Zimbra는 서버 인증서부터 중간 CA 인증서를 거쳐 루트 CA에 이르는 전체 인증서 체인을 검증할 수 있습니다.
  • zmcertmgr deploycrt comm키 불일치 또는 체인 유효성 검사 오류 없이 완료됩니다.
  • Zimbra 서비스가 정상적으로 재시작되었습니다.
  • zmcertmgr viewdeployedcrt예상되는 인증서를 보여줍니다.
  • 공용 호스트 이름에 연결하는 브라우저 또는 TLS 클라이언트는 새 인증서를 확인하고 신뢰 경고를 표시하지 않습니다.

이러한 검사 중 하나라도 실패하면 계속 진행하기 전에 해당 계층을 수정하십시오. 동일한 파일을 반복적으로 재배포하는 것은 키, SAN 또는 체인 문제를 해결하는 데 거의 도움이 되지 않습니다.

시작하기 전에: 올바른 인증 워크플로를 선택하세요

상황권장 접근 방식주요 절충점
Zimbra에서 생성된 CSR을 사용한 새 인증서CSR을 생성하고 zmcertmgr생성된 CSR을 보관하십시오.commercial.key가장 간단한 키 매칭 방식이지만, 개인 키는 이 Zimbra 설치에 계속 연결되어 있습니다.
기존 개인 키로부터 발급된 인증서배포 전에 해당 키가 Zimbra에서 사용할 키인지 확인하십시오.마이그레이션에 유용하지만 키 불일치 오류가 발생하기 쉽습니다.
단일 노드 짐브라로컬 환경에서 검증 및 배포한 후 재시작하십시오.간단하며, 유지보수 기간은 한 번입니다.
멀티노드 짐브라노드별로 인증서 배치 및 배포를 계획하거나 Zimbra에서 지원하는 다중 서버 옵션을 사용하십시오.더 많은 협력이 필요합니다. 단일 노드 절차가 모든 역할을 포괄한다고 가정하지 마십시오.

Zimbra의 최신 기술 센터 페이지에 따르면 Zimbra 8.7 이상 버전 에서는 해당 사용자가 zmcertmgrZimbra를 실행할 수 있습니다 zimbra. 또한 상용 개인 키는 반드시 `/etc/zimbra/command/` 파일 commercial.key에 이름을 지정해야 하며 /opt/zimbra/ssl/zimbra/commercial, 서버 인증서와 CA 체인 파일은 배포 전에 임시 디렉터리에 저장해야 한다고 명시되어 있습니다.

1단계: 현재 인증서 자료를 백업합니다.

기존 SSL 디렉터리를 삭제하는 것으로 시작하지 마십시오. 먼저 새 배포가 실패할 경우 복원할 수 있는 백업을 생성하십시오. 루트 권한으로 실행할 수 있는 안전한 예시는 다음과 같습니다.

cp -a /opt/zimbra/ssl/zimbra /opt/zimbra/ssl/zimbra.backup-$(date +%Y%m%d-%H%M%S)

인증서를 변경하기 전에 현재 배포된 인증서를 기록해 두십시오.

su - zimbra
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

이렇게 하면 변경 후 비교를 위한 기준선을 확보할 수 있습니다. 환경에 여러 Zimbra 노드가 있는 경우, 모든 서버의 인증서 상태가 동일하다고 가정하지 말고 각 관련 서버에서 현재 인증서 상태를 캡처해야 합니다.

2단계: 실제로 필요한 호스트 이름으로 CSR을 생성합니다.

새로운 상용 인증서를 생성하려면 프로덕션 호스트 이름과 추가 SAN을 사용하여 CSR을 생성하십시오. Zimbra는 다음 구문을 문서화합니다.

/opt/zimbra/bin/zmcertmgr createcsr comm -new \
-subject "/C=US/ST=CA/L=Sunnyvale/O=Example/OU=IT/CN=mail.example.com" \
-subjectAltNames "mail.example.com"

사용자가 와 같은 다른 이름으로도 연결하는 경우, webmail.example.com인증서를 요청할 때 해당 이름을 SAN 목록에 포함하십시오. 최신 TLS 클라이언트는 호스트 이름을 SAN과 비교하여 유효성을 검사하므로, 일반 이름만으로는 올바르게 보이는 인증서라도 호스트 이름이 누락되면 브라우저 경고가 표시될 수 있습니다.

인증기관에 보내기 전에 CSR(고객 서비스 요청)을 검토하십시오.

/opt/zimbra/bin/zmcertmgr viewcsr comm /opt/zimbra/ssl/zimbra/commercial/commercial.csr
Zimbra 상용 인증서 서명 요청 생성 및 그 결과로 생성되는 commercial.csr 및 commercial.key 파일을 보여주는 터미널 예제입니다.
CSR 단계의 최종 워크플로로, 상업용 요청과 개인 키가 생성된 후 요청이 인증 기관으로 전송됩니다.

체크포인트: 요청된 DNS 이름이 잘못된 경우 여기서 중지하십시오. 인증서를 먼저 발급받은 후 나중에 SAN이 누락된 것을 발견하면 일반적으로 CA에서 인증서를 재발급해야 합니다.

3단계: 서버 인증서와 전체 CA 체인을 수집합니다.

검증 후, 일반적으로 상용 CA는 서버 인증서와 하나 이상의 중간 인증서를 반환합니다. Zimbra의 공식 단일 노드 상용 인증서 절차는 서버 인증서를 PEM 형식으로 요구하며, 관리자에게 중간 CA 인증서와 루트 CA 인증서를 하나의 체인 파일로 결합하도록 안내합니다.

일반적인 무대 배치도는 다음과 같습니다.

/tmp/commercial.crt
/tmp/ca_intermediary.crt
/tmp/ca.crt

그런 다음 Zimbra에서 문서화한 순서대로 체인을 구축하십시오.

cat /tmp/ca_intermediary.crt /tmp/ca.crt > /tmp/ca_chain.crt

인증 기관에서 제공하는 정확한 인증서 제품에 맞는 파일을 사용하십시오. CA 브랜드 이름이 비슷하다는 이유만으로 관련 없는 튜토리얼에서 중간 인증서를 복사하지 마십시오. CA 계층 구조는 시간이 지남에 따라 변경되므로 잘못된 중간 인증서를 사용하면 문제가 발생하는 경우가 많습니다 unable to get local issuer certificate.

Zimbra에서 중간 인증서와 루트 인증서가 ca_chain.crt 파일로 결합되는 과정을 보여주는 터미널 예시입니다.
CA 체인 단계에서는 발급 중간 인증서와 루트 인증서를 결합하여 Zimbra가 서버 인증서와 함께 검증하는 체인 파일을 생성합니다.

4단계: 배포 전에 개인 키, 서버 인증서 및 인증서 체인을 확인합니다.

이것이 가장 중요한 안전 장치입니다. 최신 Zimbra 릴리스에서 Zimbra 사용자 계정으로 문서화된 검증 명령을 실행하십시오.

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

검증이 성공적으로 완료되면 인증서와 개인 키가 일치하고 인증서가 유효하다는 보고가 표시됩니다. Zimbra의 인증서 도구 관련 문서에서는 이 검증 과정이 verifycrt키 검사와 인증서 체인 검사를 결합한다고 설명합니다.

터미널 예시로 zmcertmgr verifycrt 명령어를 실행하여 Zimbra 상용 개인 키, 서버 인증서 및 CA 체인을 확인하는 과정을 보여줍니다.
인증서를 배포하기 전에 검증 단계에서 키와 인증서의 일치 여부 및 CA 체인을 모두 확인해야 합니다.

검증에 실패하면 오류에 따라 해결 방법을 선택하십시오.

  • 인증서와 개인 키가 일치하지 않습니다. 현재 CA 인증서가 연결된 CSR에서 발급되지 않았습니다 commercial.key. 올바른 키를 복원하거나 새 CSR에서 인증서를 다시 발급하십시오.
  • 인증서 체인을 확인할 수 없습니다. 중간/루트 번들이 불완전하거나, 순서가 잘못되었거나, 만료되었거나, 이 서버 인증서에 대한 체인이 아닙니다. 발급 CA에서 올바른 체인을 받으십시오.
  • 인증서가 만료되었습니다. 배포하지 마십시오. 최신 인증서를 요청하고, 인증서 체인의 중간 인증서 또는 루트 인증서가 만료되었는지 확인하십시오. Zimbra는 만료된 루트 CA 문제 해결 지침 에서 이 오류 유형에 대해 설명합니다 .
  • 호스트 이름이 누락되었습니다. 검증 결과가 브라우저에서 수행하는 호스트 이름 확인 결과와 다를 수 있습니다. 발급된 SAN을 검사하고 공용 이름이 없는 경우 재발급하십시오.

5단계: 상용 인증서를 배포합니다.

검증이 완료된 후에만 배포해야 합니다.

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

Zimbra의 문서화된 배포 프로세스는 상용 인증서를 SSL 영역에 복사하고, CA 체인을 추가하고, 인증서 구성을 업데이트하고, 서버에 적용 가능한 MTA, LDAP, 프록시 및 사서함 구성 요소와 같은 서비스에 대한 인증서 자료를 설치합니다.

특정 Zimbra 릴리스의 설명서에 명시적으로 요구되지 않는 한, 임의의 Java 키 저장소 또는 서비스 인증서 파일을 수동으로 덮어쓰지 마십시오. 이 기능의 목적은 zmcertmgr서비스별 인증서 자료의 일관성을 유지하는 것입니다.

6단계: Zimbra 서비스를 재시작합니다.

배포 후 Zimbra를 재시작하십시오.

su - zimbra
zmcontrol restart

그다음 서비스 상태를 확인하세요.

zmcontrol status

서비스가 정상적으로 작동하지 않으면 Running인증서 변경이 완료되었다고 판단하기 전에 조사를 진행하십시오. 인증서 문제는 특히 다중 노드 설치 환경에서 LDAP, 프록시, 사서함 또는 기타 TLS 기반 통신에 영향을 미칠 수 있습니다.

Zimbra 상용 인증서 배포, Zimbra 재시작 및 viewdeployedcrt 출력 결과를 보여주는 터미널 예시
서버 측 최종 단계에서는 검증된 인증서를 배포하고, Zimbra를 재시작한 다음, 에서 보고된 인증서를 확인합니다 viewdeployedcrt.

7단계: Zimbra와 클라이언트 양쪽에서 결과를 확인합니다.

먼저 Zimbra 자체의 인증서 보기 기능을 사용해 보세요.

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

배포된 서비스 인증서의 만료일이 임박했는지 여부도 확인할 수 있습니다.

/opt/zimbra/bin/zmcertmgr checkcrtexpiration all -days 30

마지막으로 사용자가 실제로 접속하는 공용 호스트 이름을 테스트하십시오. 다른 컴퓨터에서 OpenSSL을 확인하는 유용한 방법은 다음과 같습니다.

openssl s_client -connect mail.example.com:443 -servername mail.example.com -showcerts

예상되는 리프 인증서, 올바른 호스트 이름, 완전한 인증서 체인 및 성공적인 검증 결과를 확인하십시오. 그런 다음 현재 브라우저에서 동일한 HTTPS URL을 엽니다. 브라우저 테스트는 디스크에 저장된 인증서 파일뿐만 아니라 사용자가 실제로 접속하는 호스트 이름을 확인하기 때문에 중요합니다.

표준 절차가 충분하지 않을 때

다음 조건 중 하나라도 해당하는 경우, 단일 노드 단계를 고집하기보다는 접근 방식을 변경하십시오.

  • 다중 노드 Zimbra 환경에서는 프록시, 사서함, LDAP 및 MTA 역할을 서로 다른 호스트에 배포해야 할 수 있습니다. Zimbra의 인증서 도구는 다중 서버 옵션을 지원하지만, 사용하기 전에 토폴로지에 맞는 절차를 확인하십시오.
  • 리버스 프록시 또는 외부 로드 밸런서가 TLS 연결을 종료하는 경우, 해당 장치에도 공개 인증서를 설치해야 할 수 있습니다. TLS 연결이 상위 장치에서 종료되는 경우, 올바른 Zimbra 인증서만으로는 클라이언트가 보는 화면이 변경되지 않습니다.
  • 기존 키를 가져오는 중입니다. 키 를 Zimbra에서 상용 개인 키를 예상하는 위치에 배치했는지, 그리고 권한이 버전 요구 사항과 일치하는지 확인한 후 검증하십시오.
  • CA(인증 기관)는 중간 인증서 묶음만 제공합니다. 루트 인증서를 직접 만들지 말고 CA에서 제공하는 최신 인증서 체인 지침을 따르세요. Zimbra는 유효성을 검사할 수 있는 인증서 체인이 필요하며, 필요한 파일은 발급 기관에 따라 다릅니다.
  • 호스트 이름은 같지만 키가 다른 인증서가 갱신되었습니다. 확인 전에 일치하는 개인 키를 업데이트하십시오. 이전 인증서로는 commercial.key새 키 쌍에 대해 발급된 인증서를 검증할 수 없습니다.

최종 자가 점검

설치는 다음 모든 조건이 충족될 때만 완료됩니다. verifycrt테스트 통과, deploycrtZimbra 서비스 상태 '실행 중'으로 복귀, viewdeployedcrt새 인증서 표시, 그리고 실제 호스트 이름으로의 외부 TLS 연결에서 신뢰 또는 호스트 이름 경고 없이 동일한 유효한 인증서를 수신하는 경우입니다.

명령 구문 및 버전별 동작에 대한 자세한 내용은 Zimbra의 공식 certificate-tools 설명서를 참조하십시오. 여기에 제시된 예제는 mail.example.com자리 표시자이며, 이름, 인증서 파일 및 조직 세부 정보는 사용 환경에 맞게 발급된 값으로 대체해야 합니다.

댓글 남기기

iPhone에서 Zimbra ActiveSync 연결 오류 해결하기

iPhone에서 Zimbra ActiveSync 연결 오류 해결하기

iPhone에서 Zimbra ActiveSync 오류를 해결하려면 계정 정보, 자격 증명, 인증서, 네트워크 경로 및 서버 정책을 확인하고 안전한 대안을 비교해 보세요.

ownCloud Infinite Scale과 Nextcloud 28 비교: 성능 및 RAM 사용량 설명

ownCloud Infinite Scale과 Nextcloud 28 비교: 성능 및 RAM 사용량 설명

ownCloud Infinite Scale과 Nextcloud 28의 아키텍처, 성능 동작, RAM 요구 사항, 캐싱, 확장성 및 실제 배포 시 고려 사항을 비교합니다.

Nextcloud "트랜잭션 파일 잠금이 구성되지 않았습니다" 오류 해결 방법

Nextcloud "트랜잭션 파일 잠금이 구성되지 않았습니다" 오류 해결 방법

Nextcloud의 트랜잭션 파일 잠금 경고를 해결하려면 배포 환경을 확인하고, Redis 또는 KeyValueCache를 구성하고, 관련 서비스를 재시작하고, 파일 작업을 검증하십시오.

Zimbra에서 외부 LDAP 인증을 구성하는 방법

Zimbra에서 외부 LDAP 인증을 구성하는 방법

실용적인 CLI 예제, TLS 안내, 바인드 DN 및 검색 필터 패턴, 검증 단계, 롤백 확인 등을 통해 Zimbra용 외부 LDAP 인증을 구성하세요.

BigBlueButton에서 자동 녹음 정리 기능을 설정하는 방법

BigBlueButton에서 자동 녹음 정리 기능을 설정하는 방법

cron, 보존 규칙, 로그 및 검증 기능을 사용하여 BigBlueButton 녹화 파일 정리 작업을 안전하게 자동화하세요. 원시 데이터 정리와 전체 녹화 파일 삭제를 비교해 보세요.

Jitsi Meet 라이브 스트리밍을 RTMP를 통해 YouTube로 설정하는 방법

Jitsi Meet 라이브 스트리밍을 RTMP를 통해 YouTube로 설정하는 방법

Jitsi Meet을 YouTube로 스트리밍하는 데 Jibri와 OBS를 비교하고, 올바른 경로를 설정하고, 스트림 키를 안전하게 사용하고, 라이브 미리보기를 확인하세요.

BigBlueButton과 Jitsi 비교: 리소스 사용량 및 기능 매트릭스

BigBlueButton과 Jitsi 비교: 리소스 사용량 및 기능 매트릭스

BigBlueButton과 Jitsi Meet을 서버 크기 산정, 녹화 비용, 교육 도구, 확장성, 그리고 자체 호스팅 배포를 선택하거나 크기를 조정해야 할 때 참고할 수 있는 실질적인 지표를 기준으로 비교합니다.

OCC를 사용하여 Nextcloud 유지 관리 모드가 계속 켜져 있는 문제 해결

OCC를 사용하여 Nextcloud 유지 관리 모드가 계속 켜져 있는 문제 해결

OCC를 사용하여 멈춘 Nextcloud 유지 관리 페이지를 안전하게 닫고, 업그레이드가 완료되지 않았는지 확인하고, 인스턴스가 사용자를 위해 준비되었는지 확인합니다.

Zimbra 발신 메일 지연 오류 해결: "포트 25 연결 시간 초과"

Zimbra 발신 메일 지연 오류 해결: "포트 25 연결 시간 초과"

Zimbra 발신 메일 지연 오류(포트 25)를 진단합니다. 큐, MX DNS, 방화벽, 공급자 차단을 확인하고 승인된 SMTP 릴레이를 구성하십시오.

Conduit을 사용하여 Raspberry Pi 4에 Matrix 서버를 설정하는 방법

Conduit을 사용하여 Raspberry Pi 4에 Matrix 서버를 설정하는 방법

Conduit, Docker, NGINX, HTTPS, 회원 관리, 연동 및 검사 기능을 갖춘 경량 Matrix 홈서버를 Raspberry Pi 4에 설치합니다.