○웹살림
← 모든 기록
SSL 인증서 오류 해결: 초보 웹 운영자를 위한 5단계 가이드 대표 이미지
문제 해결

SSL 인증서 오류 해결: 초보 웹 운영자를 위한 5단계 가이드

SSL 인증서 오류의 일반적인 원인을 이해하고, 단계별 진단 및 해결 방법을 제시합니다. 실제 웹 운영자가 겪는 구체적인 오류 메시지와 해결 단계를 담았습니다.

글 수정

SSL 인증서 오류가 발생하면 가장 먼저 브라우저에 표시되는 구체적인 오류 메시지를 확인해야 합니다. 이후 서버에 설치된 인증서의 유효 기간, 도메인 일치 여부, 신뢰 체인을 점검합니다. 마지막으로 네트워크 포트 충돌이나 TLS 프로토콜 불일치 같은 하부 구조 문제를 진단합니다.

1단계: 오류 메시지 분석으로 원인 범위 좁히기

오류 메시지는 문제의 원인을 가리키는 가장 중요한 단서입니다. 브라우저마다 메시지 표현은 조금씩 다르지만, 근본적인 의미는 동일합니다. 아래 표에 자주 마주치는 오류 메시지와 그 의미를 정리했습니다.

오류 메시지 (예시)의미주로 점검할 부분
Failed to connect to domain port 443: Connection refused443 포트에서 서버 연결이 거부됨방화벽, 서버 상태, 포트 충돌
certificate subject name (domain) does not match target host name인증서의 대상 도메인이 실제 호스트 이름과 불일치인증서 발급 도메인 확인
SSL certificate problem: self signed certificate신뢰할 수 없는 자체 서명 인증서 사용인증서 교체 또는 예외 추가
SSL ExceptionHTTPS 통신 시 인증서 검증 오류서버 인증서 구성 및 클라이언트 환경

위 표의 첫 번째 오류인 Failed to connect to domain port 443: Connection refused 오류는 서버의 443 포트에서 연결이 거부되었음을 의미합니다. 이 오류가 발생하면 웹 서버 자체가 정상적으로 실행 중인지, 방화벽에서 443 포트를 막고 있지는 않은지 확인하는 것이 우선입니다. 두 번째 오류인 certificate subject name (domain) does not match target host name 오류는 인증서에 명시된 주체 이름이 실제 접속한 도메인과 일치하지 않을 때 나타납니다. 예를 들어 www.example.com용으로 발급받은 인증서를 example.com에 설정하거나, IP 주소로 접속할 때 흔히 발생합니다. 세 번째인 SSL certificate problem: self signed certificate 오류는 사설 인증 기관(CA)에서 서명되지 않은 자체 서명 인증서를 사용할 때 발생합니다. 특히 개발 환경이나 인트라넷에서 자주 보게 되며, 이때는 해당 인증서를 명시적으로 신뢰하거나 공인 인증서로 교체해야 합니다. SSL 예외는 이와는 조금 다르게, HTTP 대신 HTTPS를 사용하는 모든 상황에서 발생할 수 있으며, 서버 측의 인증서가 유효하지 않을 때 자바 기반 애플리케이션 등에서 자주 보고됩니다. 이러한 오류 메시지의 유형과 자세한 대처 사례는 실무 블로그 문서(https://hiseon.me/server/how-to-fix-ssl-error/)에서도 폭넓게 다루고 있습니다.

2단계: 서버 SSL 인증서 구성 검증하기

먼저 서버의 SSL 인증서가 올바르게 설정되어 있는지 확인해야 합니다. 구체적으로는 인증서의 유효 기간이 만료되지 않았고, 인증서 체인이 완전하며, 개인 키가 올바르게 연결되어 있는지를 점검합니다. 윈도우 서버에서는 certlm.msc나 IIS 관리자를 통해 바인딩 정보를 확인할 수 있습니다. 리눅스 환경에서는 OpenSSL을 사용하여 원격 서버의 인증서 정보를 조회합니다. 예를 들어 아래 명령은 인증서의 발급일, 만료일, 발급자, 주체를 보여줍니다.

openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject -issuer

출력에서 notAfter 값이 현재 시점보다 과거라면 인증서가 만료된 것입니다. 또한 중간 인증서(Intermediate CA)가 누락되면 브라우저가 완전한 신뢰 체인을 구성하지 못해 오류가 발생하므로, 인증서 파일을 결합하는 작업이 필요할 수 있습니다.

문제 진단을 더욱 빠르게 진행하려면 테스트 인증서를 활용한 격리 방법이 효과적입니다. 웹 사이트가 테스트 인증서와 함께 작동하는지 확인합니다. 이를 위해 먼저 자체 서명된 임시 인증서를 생성하고 서버에 설치합니다. 그런 다음 해당 인증서를 사용해 접속해 봅니다. 만약 테스트 인증서로는 문제없이 접속된다면, 기존 인증서에 손상이나 구성 오류가 있다고 판단할 수 있습니다. Microsoft의 SSL 문제 해결 공식 가이드(https://learn.microsoft.com/ko-kr/troubleshoot/developer/webapps/iis/www-authentication-authorization/troubleshooting-ssl-related-issues-server-certificate)에서도 이 접근법을 권장하고 있습니다.

3단계: SSL 포트 충돌 및 네트워크 연결 점검하기

SSL 통신이 실패할 때 단순히 서버나 인증서 문제가 아닌, 네트워크 계층에서의 충돌이 원인일 수 있습니다. 특히 443 포트를 다른 프로세스가 이미 점유하고 있다면 웹 서버가 해당 포트와 바인딩되지 못하거나 충돌이 발생합니다. 명령 프롬프트에서 netstat -ano | findstr :443을 실행하여 웹 사이트에서 사용하는 SSL 포트에서 수신 대기 중인 다른 프로세스가 없는지 확인합니다. 출력에서 0.0.0.0:443 또는 [::]:443 상태가 LISTENING인 행을 찾고, 해당 PID를 메모합니다. 예를 들어 PID가 1234라면 tasklist /fi "pid eq 1234"로 어떤 프로그램인지 식별할 수 있습니다. 만약 세계에서 널리 쓰이는 웹 서버가 아닌 엉뚱한 프로세스(예: 오래된 톰캣 인스턴스, 프록시 툴)가 등록되어 있다면, taskkill /PID 1234 /F 명령으로 해당 프로세스를 강제 종료한 후 웹 서버를 다시 시작합니다.

방화벽 및 보안 그룹 설정도 반드시 함께 점검해야 합니다. 클라우드 환경이라면 인스턴스 수준의 방화벽(예: iptables) 외에도 클라우드 제공업체의 보안 그룹에서 0.0.0.0/0 (또는 특정 소스 IP)으로부터의 443 인바운드 트래픽을 허용하는 규칙이 적용되어 있는지 확인합니다. 네트워크 ACL이나 라우팅 테이블이 잘못 구성되어 트래픽을 차단하는 사례도 흔하므로, 모든 단계를 차례대로 검증합니다.

4단계: TLS 프로토콜 버전 호환성 맞추기

TLS 프로토콜은 클라이언트와 서버 간의 암호화 통신 방식을 결정합니다. 구버전인 TLS 1.0이나 1.1은 이미 많은 보안 취약점이 발견되어 주요 브라우저와 운영체제에서 지원을 중단하는 추세입니다. 그 결과, 서버가 구버전 프로토콜만 지원하는데 클라이언트는 최신 버전만 요구하면 핸드셰이크가 실패할 수 있습니다. 대표적인 예로, 클라이언트가 TLS 1.1 및 TLS 1.2만 사용하도록 구성되었지만 IIS 웹 서버가 TLS 1.0까지 지원하도록 구성된 경우 핸드셰이크가 실패합니다.

이 문제를 해결하려면 서버에서 지원하는 프로토콜을 활성화하고, 구버전은 비활성화해야 합니다. 윈도우 서버의 경우 레지스트리 편집기에서 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols 경로 아래에 TLS 1.0, 1.1, 1.2 각각의 키가 존재합니다. 각 키의 Server 및 Client 하위 키에 Enabled DWORD 값이 1이면 해당 프로토콜이 활성화된 것입니다. 안전한 구성을 위해 TLS 1.0과 1.1의 Enabled를 0으로 변경하고, TLS 1.2는 1로 설정합니다. 변경 후에는 반드시 서버를 재부팅해야 적용됩니다.

리눅스 기반의 Nginx 서버에서는 /etc/nginx/nginx.conf 혹은 사이트 설정 파일에서 ssl_protocols 지시어를 추가합니다. ssl_protocols TLSv1.2 TLSv1.3; 와 같이 설정합니다. Apache의 경우 /etc/httpd/conf.d/ssl.conf 등에서 SSLProtocol 지시어를 사용합니다. SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 및 SSLProtocol +TLSv1.2 +TLSv1.3 와 같이 설정합니다. 변경 후 서비스를 재시작하고, curl -I -v --tls-max 1.2 https://example.com 명령으로 특정 프로토콜로 접속이 되는지 테스트합니다. 프로토콜 관련 설정이 완료된 후에도 오류가 지속된다면 암호화 스위트(Cipher Suite)의 불일치 가능성도 고려해야 합니다. SSL Labs의 SSL Server Test(https://www.ssllabs.com/ssltest/)를 사용하면 서버가 지원하는 프로토콜과 암호화 스위트를 종합적으로 진단할 수 있습니다.

5단계: 클라이언트 환경 최종 점검

많은 웹 운영자가 간과하는 사실 중 하나는 SSL 오류가 사용자의 디바이스 자체에서 비롯될 수 있다는 점입니다. 첫 번째 점검 항목은 시스템 시간입니다. 인증서는 유효 기간이 엄격하게 정해져 있어, 클라이언트의 시계가 몇 분만 빨라도 ‘인증서가 아직 유효하지 않음’ 오류가 발생합니다. Windows에서는 설정 > 시간 및 언어 > 날짜 및 시간에서 ‘자동으로 시간 설정’을 켜거나, 수동으로 시간 서버(예: time.windows.com)와 동기화합니다. macOS와 Linux에서도 ntpd나 timedatectl을 이용해 시간을 동기화할 수 있습니다.

두 번째로, 브라우저에 저장된 오래된 인증서 캐시나 SSL 세션 정보가 문제를 일으키기도 합니다. 크롬을 예로 들면, 주소창에 chrome://net-internals/#hsts를 입력한 후 Delete domain security policies에서 해당 도메인을 입력해 HSTS/SSL 상태를 초기화할 수 있습니다. 또는 설정 > 개인정보 및 보안 > 인터넷 사용 기록 삭제에서 쿠키, 캐시, 사이트 데이터를 지우는 것만으로도 상당수의 오류가 해결됩니다.

사내 인트라넷이나 폐쇄망에서는 자체 서명 인증서나 사설 CA에서 발급한 인증서를 사용하는 경우가 많습니다. 이때 오류가 발생하면 해당 사설 CA 인증서를 클라이언트의 ‘신뢰할 수 있는 루트 인증 기관’ 저장소에 수동으로 설치해야 합니다. Windows에서는 mmc를 실행하고, 파일 > 스냅인 추가/제거에서 ‘인증서’를 선택한 후 ‘컴퓨터 계정’ 또는 ‘내 사용자 계정’으로 추가합니다. 나타난 콘솔 트리에서 ‘신뢰할 수 있는 루트 인증 기관’ → ‘인증서’를 오른쪽 클릭하고, 모든 태스크 → 가져오기로 해당 사설 CA 인증서를 가져오면 신뢰할 수 있게 됩니다. 하지만 자체 서명 인증서를 장기간 운영 환경에 사용하는 것은 권장하지 않습니다. 가능한 Let’s Encrypt와 같은 무료 공인 인증서로 전환하는 것이 보안과 유지보수 측면에서 유리합니다.

SSL 예외는 HTTP 대신 HTTPS를 사용하여 통신할 때 발생하는 오류입니다. 이러한 내용을 포함한 실무적인 문제 해결 사례는 개발자 커뮤니티 블로그(https://developerxdasomu.tistory.com/31)에서 보다 자세히 확인할 수 있습니다.

지금까지 살펴본 다섯 단계의 진단 프로세스를 순서대로 적용하면 대부분의 SSL 오류를 체계적으로 해결할 수 있습니다. 특히 메시지 분석 → 서버 인증서 점검 → 포트 충돌 확인 → TLS 호환성 → 클라이언트 환경이라는 흐름은 초보 웹 운영자에게도 강력한 문제 해결 프레임워크가 되어 줄 것입니다. 웹 운영 전반에 걸친 더 다양한 문제 해결 가이드는 웹살림(https://websalim.com/)에서 도움을 받으실 수 있습니다.

함께 보기

참고 자료