사용자 지정 포트에서 Kopano SSL 핸드셰이크 오류를 해결하는 방법

성공적인 해결책이 어떤 모습인지 정의하세요

Kopano SSL 핸드셰이크 오류는 클라이언트와 서버가 TLS 연결에 대해 합의하지 못했거나 연결을 완료하지 못했음을 의미합니다. 사용자 지정 포트가 설정의 일부에는 맞지만 다른 부분에는 맞지 않을 수 있습니다. 인증서 또는 프로토콜 설정을 변경하기 전에 해당 포트를 소유한 서비스와 해당 포트에서 TLS 연결이 필요한지 확인하십시오.

정상적인 구성에서는 지정된 포트가 TLS 연결을 수락하고, 클라이언트가 사용하는 호스트 이름에 유효한 인증서를 제시하며, 다음 프로토콜 단계를 완료할 수 있도록 합니다. 브라우저는 인증서 경고 없이 웹 애플리케이션 로그인 페이지에 도달해야 합니다. Kopano Core 클라이언트는 일치하는 TLS 포트와 구성된 경우 신뢰할 수 있는 클라이언트 인증서를 사용하여 연결해야 합니다. TLS 프로브가 성공했다고 해서 웹 애플리케이션 로그인, Kopano 인증 또는 메일 전송이 정상적으로 작동한다는 것을 보장하는 것은 아닙니다.

먼저 두 가지 일반적인 포트 설정을 분리합니다.

Kopano Core에서 확인됨: Kopano Core 관리자 설명서 8.0에서는 로 제어되는 네이티브 TLS 리스너에 대해 설명합니다 server_listen_tls. 예제에서는 포트 237을 사용하며, 포트를 변경할 수 있다고 명시하고, 인증서 및 CA 파일을 에 구성합니다 /etc/kopano/server.cfg. 또한 설명서에는 클라이언트가 https://일치하는 포트와 클라이언트 인증서를 사용하는 서버 소켓을 사용하는 방법도 나와 있습니다. Kopano Core: SSL 연결 및 인증서 와 Kopano Core 특수 구성을 참조하십시오 .

별도로 웹 애플리케이션 접속의 경우, 사용자는 일반적으로 Apache, Nginx 또는 Kopano Web에서 제공하는 브라우저 URL을 엽니다. TLS는 프런트엔드 서버에서 종료되고, 해당 서버는 Kopano 서비스로 요청을 전달합니다. Kopano 매뉴얼에는 포트 236의 Core 리스너로의 HTTP 프록싱에 대한 내용이 설명되어 있으며, Kopano Web 가이드에는 TLS 인증서 설정에 대한 내용이 나와 있습니다 /etc/kopano/kwebd.cfg. 프런트엔드 HTTPS 포트는 Core TLS 포트와 자동으로 동일하지 않습니다. Core 역방향 프록시 예제 와 Kopano Web 설치 가이드를 참조하십시오 .

조치: 클라이언트 URL, 사용자 지정 포트, 해당 포트에서 수신 대기할 것으로 예상되는 프로세스, 그리고 TLS 연결이 프록시에서 종료되는지 아니면 Kopano Core에서 종료되는지를 기록해 두십시오. 두 리스너를 동시에 변경하지 마십시오.

1. 사용자 지정 포트에서 수신 대기 중인 프로세스를 확인합니다.

Kopano 호스트에서 8443아래 값을 오류가 발생하는 포트 번호로 바꾸십시오.

sudo ss -ltnp | grep ':8443'

일치하는 행에는 수신 대기 소켓이 표시되어야 합니다. 행이 없으면 서비스가 해당 포트에 바인딩되지 않았거나 다른 주소에 바인딩된 것입니다. 포트가 로컬 리버스 프록시에 속하는 경우 프록시의 가상 호스트를 검사하십시오. Kopano Core의 네이티브 TLS 포트여야 하는 경우 해당 포트를 검사하십시오 server_listen_tls. 특정 포트 /etc/kopano/server.cfg에서만 수신 대기하는 프로세스는 127.0.0.1원격 연결을 직접 수락할 수 없습니다. 이는 프록시가 앞에 있는 경우 의도적인 것일 수 있습니다.

호스트 방화벽, 클라우드 방화벽, 로드 밸런서 또는 NAT 규칙도 확인하십시오. 공용 포트가 의도한 내부 수신기에 도달해야 합니다. 시간 초과 또는 연결 거부는 연결 가능성 또는 수신기 구성 문제를 나타내며, 그 자체로 인증서 오류를 의미하는 것은 아닙니다.

2. 정확한 호스트 이름과 포트로 TLS를 확인합니다.

클라이언트 컴퓨터에서 OpenSSL을 사용하여 공용 엔드포인트를 테스트합니다. 인증서에 표시된 DNS 이름을 사용하고, 관련 없는 IP 주소를 사용하지 마십시오.

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

제시된 인증서, 협상된 프로토콜 및 암호화 방식, 그리고 검증 오류를 확인하십시오. 이 -servername옵션은 TLS SNI 호스트 이름을 전송합니다. 이는 서버가 여러 TLS 사이트를 호스팅하는 경우에 중요합니다. OpenSSL은 s_client 설명서 에서 이러한 옵션에 대해 자세히 설명합니다 . Ctrl+C를 눌러 대화형 프로브를 종료하십시오.

인증서가 없는 경우 엔드포인트가 일반 HTTP를 사용하거나, 잘못된 서비스가 포트를 소유하고 있거나, 프록시가 잘못된 업스트림으로 포워딩하고 있을 수 있습니다. 인증서가 표시되지만 이름, 발급자 또는 만료일이 잘못된 경우 TLS 엔드포인트에서 인증서 선택 또는 인증서 체인을 수정하십시오. 호스트 이름 불일치는 Kopano Core 리스너 포트를 변경해도 해결되지 않습니다.

브라우저에서 접근 가능한 엔드포인트의 경우, 다음 단계를 따르세요.

curl -v https://mail.example.com:8443/webapp/

자세한 출력은 TLS 검증을 리디렉션, 404 또는 502와 같은 HTTP 응답과 구분하는 데 도움이 됩니다. 핸드셰이크가 완료된 후 404 오류가 발생하는 것은 경로 또는 라우팅 문제이며 TLS 협상 실패가 아닙니다. 일회성 진단 용도로만 사용 가능하며, curl -vk인증서 검증을 건너뛰었을 때 결과가 변경되는지 확인할 수 있습니다. 브라우저, 클라이언트 또는 프록시에서 인증서 검사를 비활성화한 상태로 두지 마십시오.

중요 제한 사항: Kopano Core의 네이티브 TLS는 클라이언트 인증서를 사용할 수 있습니다. 클라이언트 인증서 없이 기본 s_client테스트를 수행하면 TLS 리스너가 정상적으로 작동하더라도 테스트가 거부될 수 있습니다. 서버에서 클라이언트 인증을 요청하는 경우, 승인된 클라이언트 인증서와 키를 사용하여 테스트를 다시 수행하거나, 구성된 Kopano 서비스 클라이언트를 사용하여 테스트하십시오. 명령 로그나 지원 티켓에 개인 키를 절대 노출하지 마십시오.

3. 프로토콜을 리스너에 맞추세요

흔히 발생하는 사용자 지정 포트 오류는 HTTPS 클라이언트가 일반 HTTP 리스너에 연결하도록 구성하거나, HTTPS 트래픽을 HTTP를 기대하는 상위 서버로 전달하는 것입니다. 스키마와 포트는 동일한 엔드포인트를 나타내야 합니다.

  • https://mail.example.com:8443/webapp/이는 브라우저가 8443번 포트에서 TLS 연결을 기대한다는 의미입니다.
  • Kopano Core의 공식 예제는 프록시를 통해 HTTP를 전송합니다 . 배포 환경에서 이 패턴을 사용하는 경우, 공용 브라우저 연결은 HTTPS를 사용하더라도 127.0.0.1:236상위 프록시는 반드시 를 사용해야 합니다 .http://
  • Kopano Core TLS의 기본 설정에서 매뉴얼의 예제는 237번 포트 server_listen_tls = *:237와 .로 시작하는 클라이언트 URL을 사용합니다 https://. 237을 사용자 지정 포트로 변경하는 경우, 종속된 모든 클라이언트 또는 프록시도 동일한 값으로 업데이트해야 합니다.

포트 또는 스키마에 대한 복사된 구성 라인이 서로 다른지 확인하십시오. 다중 서버 설정의 경우 게시된 서버 또는 프록시 URL도 검토하십시오. 클라이언트가 초기 연결을 완료한 후 Kopano가 이전 호스트 이름이나 포트로 리디렉션한 후 연결에 실패할 수 있습니다.

4. 리스너 및 인증서 구성을 복구합니다.

Kopano Core의 기본 TLS 리스너인 경우, 중복된 지시문을 추가하는 대신 기존 구성을 편집하십시오. 다음은 사용자 지정 포트에 대한 간소화된 예입니다. 설치 환경에 맞게 인증서 경로와 CA를 유지하십시오.

server_listen_tls = *:1237
server_ssl_ca_file = /etc/kopano/ssl/ca.pem
server_ssl_key_file = /etc/kopano/ssl/server.pem
server_ssl_key_pass = your-key-passphrase

Kopano 설명서에는 리스너, CA, 서버 키 및 키 암호 설정이 명시되어 있으며, kopano-server네이티브 리스너를 변경한 후에는 재시작해야 합니다. 설치된 버전이 표시된 옵션을 지원하는지 확인하십시오. 패키지 레이아웃과 지침은 다를 수 있습니다. 키 디렉터리를 보호하고 Kopano 서비스 계정이 필요한 파일을 읽을 수 있는지 확인하십시오.

인증서가 클라이언트가 실제로 사용하는 호스트 이름에 대한 것인지, 유효 기간 내에 있는지, 그리고 필요한 중간 인증서가 모두 포함되어 있는지 확인하십시오. Kopano 설명서에 따르면 구성 요소는 인증서의 일반 이름(CNN)과 주체 대체 이름(SAN)을 확인합니다. 다중 서버 TLS 설정에서 서버는 클라이언트 인증서에 서명한 CA를 신뢰해야 하며, 승인된 클라이언트 인증서가 구성되어 있어야 합니다. 공용 브라우저 서비스를 바로 사용할 수 있도록 자체 서명된 인증서로 교체하지 마십시오.

TLS 연결이 Apache, Nginx 또는 Kopano Web에서 종료되는 경우, 해당 프런트엔드에서 인증서와 사용자 지정 listen포트를 구성하십시오. 그런 다음 백엔드의 실제 리스너에 따라 업스트림 스키마와 포트를 설정하십시오. 공용 측에서 HTTPS를 사용한다고 해서 업스트림 TLS를 활성화하지 마십시오. 먼저 백엔드 포트에서도 TLS를 지원하는지 확인해야 합니다.

5. 올바른 서비스를 검증하고 다시 로드합니다.

웹 서버를 재시작하기 전에 sudo nginx -tNginx 또는 sudo apachectl configtestApache와 같은 서버의 구성 검사를 실행하십시오. 검사에서 오류가 보고되면 재시작하기 전에 수정하십시오. 배포판에 설치된 서비스 이름을 사용하십시오. 예를 들면 다음과 같습니다.

sudo systemctl restart kopano-server
sudo systemctl status kopano-server --no-pager

Kopano Core는 설정을 변경한 경우에만 재시작하십시오. 프런트엔드 전용 포트 또는 인증서 변경의 경우, 프런트엔드 서비스를 검증하고 다시 로드하십시오. 변경 직후 저널 또는 오류 로그를 확인하고 클라이언트 네트워크에서 동일한 OpenSSL 프로브를 다시 실행하십시오. 핸드셰이크를 통해 예상되는 인증서가 제시될 것입니다. 그런 다음 실제 웹 애플리케이션 URL 또는 Kopano 클라이언트 연결을 테스트하십시오. TLS 연결 성공만으로는 애플리케이션 경로 또는 인증이 유효한 것으로 간주되지 않습니다.

더 변경하기 전에 결과를 확인하세요

  • 수신 소켓이 없습니다. 구성된 리스너, 서비스 상태 및 바인딩 주소를 확인하십시오.
  • 연결이 거부되었거나 시간 초과가 발생했습니다. 방화벽, NAT, 로드 밸런싱을 확인하고 대상 포트에 연결할 수 있는지 확인하십시오.
  • 잘못된 인증서: 해당 포트에 응답하는 엔드포인트에 구성된 인증서를 검사하십시오. 여기에는 SNI 선택 및 인증서 체인이 포함됩니다.
  • TLS는 로컬에서는 작동하지만 원격에서는 작동하지 않습니다. 공용 프록시 또는 로드 밸런서 경로와 로컬 리스너 경로를 비교하고 전달된 호스트 및 포트 값을 검토하십시오.
  • 핸드셰이크는 성공했지만 웹 애플리케이션에 오류가 발생했습니다. HTTP 상태, 프록시 경로, PHP/웹 애플리케이션 로그 및 Kopano Core 연결 상태를 확인하십시오. 애플리케이션 계층에서 계속 진행하십시오.
  • Core 클라이언트만 오류가 발생합니다. 해당 클라이언트의 사용자 지정 포트, 신뢰할 수 있는 CA 및 클라이언트 인증서 설정을 확인하십시오 server_socket. Core TLS 경로는 상호 인증서 인증이 필요할 수 있습니다.

안정적인 해결 방법은 핸드셰이크 실패를 담당하는 엔드포인트만 변경하는 것입니다. 이 절차에 사용할 수 있는 Kopano Core 관리자 설명서는 버전 8.0.0이며, 해당 설명서의 예제는 설치된 패키지 및 로컬 설명서 페이지와 비교하여 확인해야 합니다. 배포 환경에서 다른 Kopano 릴리스, 컨테이너 또는 관리형 리버스 프록시를 사용하는 경우, 샘플 지시문을 적용하기 전에 해당 구성 요소의 현재 구성을 확인하십시오.

댓글 남기기

네트워크에서 장치를 찾는 데 유용한 최고의 핑 스윕 도구 10가지

네트워크에서 장치를 찾는 데 유용한 최고의 핑 스윕 도구 10가지

빠른 LAN 검색, 플랫폼 간 스캔 및 IP 주소 관리를 위한 10가지 핑 스윕 도구를 비교해 보세요. 스윕을 통해 무엇을 알 수 있고 무엇을 알 수 없는지 알아보세요.

성능 추적을 위한 최고의 네트워크 관리 도구 6가지

성능 추적을 위한 최고의 네트워크 관리 도구 6가지

SNMP 적용 범위, 매핑, 알림, 배포 모델 및 비용 대비 효과를 포함하여 성능 모니터링을 위한 6가지 네트워크 관리 도구를 비교합니다.

Windows, iOS 및 Android용 최고의 Wi-Fi 분석기

Windows, iOS 및 Android용 최고의 Wi-Fi 분석기

Windows, iPhone, Android용 Wi-Fi 분석 앱들을 비교해 보세요. 채널 혼잡도, 신호 범위, 히트맵, 네트워크 문제 해결 도구 등을 포함합니다.

핑 모니터: 네트워크 가용성을 위한 7가지 무료 오픈소스 도구

핑 모니터: 네트워크 가용성을 위한 7가지 무료 오픈소스 도구

종합적인 네트워크 관리 도구부터 특정 지연 시간 측정에 특화된 도구까지, 7가지 무료 오픈 소스 핑 모니터링 도구를 비교하고 가용성, 패킷 손실률, 기록 관리에 적합한 도구를 선택하세요.

네트워킹에서의 QoS: 서비스 품질(QoS)이란 무엇이며 어떻게 작동하는가

네트워킹에서의 QoS: 서비스 품질(QoS)이란 무엇이며 어떻게 작동하는가

네트워킹에서 QoS가 무엇을 의미하는지, DSCP 마킹과 트래픽 큐가 음성, 비디오 및 비즈니스 애플리케이션의 우선순위를 어떻게 지정하는지, 그리고 QoS로 해결할 수 없는 문제는 무엇인지 알아보세요.

Nmap을 사용하여 트레이서루트를 실행하고 네트워크 경로를 읽는 방법

Nmap을 사용하여 트레이서루트를 실행하고 네트워크 경로를 읽는 방법

Nmap의 --traceroute 옵션을 사용하여 홉을 인증된 호스트로 매핑하고, 홉 및 RTT 출력을 이해하고, 과도한 스캔 없이 누락된 응답 문제를 해결할 수 있습니다.

안전한 파일 전송을 위한 최고의 SFTP 서버 소프트웨어

안전한 파일 전송을 위한 최고의 SFTP 서버 소프트웨어

Windows 및 Linux용 안정적인 SFTP 서버 소프트웨어(OpenSSH, Bitvise, SolarWinds, SFTPGo 등)를 비교해 보세요. 보안 및 파일 전송 요구 사항에 맞는 최적의 솔루션을 찾아보세요.

네트워크 팀을 위한 최고의 IP 주소 관리 도구 7가지

네트워크 팀을 위한 최고의 IP 주소 관리 도구 7가지

서브넷 검색, DNS 및 DHCP 조정, 네트워크 인벤토리, 오픈 소스 IPAM을 위한 7가지 IP 주소 관리 도구를 비교합니다.

네트워크 모니터링 모범 사례: 추적 대상 및 사용 도구

네트워크 모니터링 모범 사례: 추적 대상 및 사용 도구

SolarWinds NPM, PRTG 및 OpManager를 비교하여 명확한 장치 범위, 유용한 성능 지표, 실행 가능한 알림을 통해 실용적인 네트워크 모니터링 시스템을 구축하십시오.

기기 및 IP 주소 검색을 위한 최고의 네트워크 스캐너 도구 10가지

기기 및 IP 주소 검색을 위한 최고의 네트워크 스캐너 도구 10가지

빠른 장치 검색, 플랫폼 간 IP 스캔 및 엔터프라이즈 IPAM을 위한 네트워크 스캐너 도구를 비교하고, 각 옵션을 네트워크에 맞게 선택하는 방법에 대한 지침을 제공합니다.