TLS 인증서오류 해결

1. 로그에서 인증서 오류와 연결 실패 구분하기

‘TLS 핸드셰이크 실패’는 결과일 뿐, 구체적인 원인은 아닙니다. v2rayN 메인 창 아래쪽 로그 영역에서 방금 연결했을 때의 전체 오류를 확인하세요. 로그 영역이 접혀 있다면 해당 패널을 먼저 펼치면 됩니다. 버전에 따라 화면 위치는 다를 수 있지만, 브라우저에 표시되는 ‘연결이 재설정되었습니다’만 보지 말고 x509, tls 또는 certificate가 포함된 코어 로그 원문을 기준으로 판단하세요.

노드를 하나 선택하고 연결 시간을 기록한 뒤 요청을 한 번만 보내세요. 아래 영문 문구는 흔히 나타나는 오류 형식이며, 실제 로그에는 코어 모듈 이름, 연결 주소, 중첩된 원인이 추가될 수 있습니다. 로그를 공유하기 전에 구독 주소, 사용자 식별 정보, 접속 대상의 민감한 정보를 삭제하세요.

2. 시스템 시간을 동기화한 뒤 인증서 만료 여부 확인하기

TLS는 현재 시간과 인증서의 notBefore, notAfter 값을 비교해 검증합니다. 컴퓨터 전원이 꺼진 뒤 시계가 초기화되거나, 가상 머신을 이전 스냅샷으로 복원하거나, 날짜를 수동으로 바꾸면 유효한 인증서도 ‘아직 유효하지 않음’ 또는 ‘만료됨’으로 판정될 수 있습니다. 작업 표시줄의 시각만 보지 말고 연월일과 분까지 확인하세요.

1. 날짜 및 시간 확인

   Windows 11에서 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’을 열어 날짜, 시간, 현재 시간대를 확인하세요. 시간이 정상적으로 동기화된 다른 기기와도 비교해 보세요.

2. 지금 동기화

   ‘자동으로 시간 설정’을 켠 다음 ‘추가 설정’에서 ‘지금 동기화’를 선택하세요. 동기화에 실패하면 일반 네트워크 연결을 복구한 뒤 Windows 시간 서비스를 다시 시도하세요.

3. 다시 연결

   클라이언트로 돌아가 현재 노드를 다시 활성화하고 새 요청을 보내세요. 동기화 전의 오래된 오류가 아니라 새 로그를 기준으로 판단해야 합니다.

4. 인증서 유효 기간 확인

   시간이 정확한데도 만료 오류가 표시되면 서버가 실제로 반환하는 인증서의 유효 기간을 확인하세요. 현재 시간이 notAfter 이후라면 노드 관리자 측에서 인증서를 갱신하고 TLS 서비스에 새 인증서를 다시 적용해야 합니다.

Android에서는 시스템 ‘설정’에서 ‘날짜 및 시간’을 검색한 다음 자동 시간 설정을 켜세요. 메뉴 구성은 기기와 시스템 버전에 따라 다를 수 있습니다. 시간대는 표시 방식에 영향을 주지만 절대 시간이 정확하다면 시간대만 바꿔도 보통 인증서 오류가 발생하지 않습니다. 반대로 시계를 과거로 돌려 일시적으로 연결되게 해도 다른 서비스에 문제가 생길 수 있으므로 해결 방법으로 사용하지 마세요.

시간 동기화와 노드 연결은 서로 다른 경로를 사용합니다. 노드가 443 포트를 쓴다고 해서 시간 동기화도 같은 포트를 사용하는 것은 아닙니다. 동기화 서비스의 네트워크 정책을 점검할 때는 실제 시간 서버와 프로토콜을 확인하세요. 이 때문에 컴퓨터의 인바운드 포트를 함부로 열 필요는 없습니다.

3. SNI, 서버 주소, Host 확인하기

노드의 ‘주소’, TLS의 ‘서버 이름’, WebSocket의 ‘Host’는 서로 같은 값이 아닙니다. 서버 주소는 연결할 대상을 정하고, SNI는 TLS 핸드셰이크에서 서버가 사이트와 인증서를 선택하도록 전달됩니다. HTTP Host 또는 HTTP/2의 authority는 애플리케이션 계층 요청에 속합니다. Host를 바꿔도 인증서 검증에 사용되는 이름이 자동으로 바뀌지는 않습니다.

v2rayN 메인 창에서 노드를 더블 클릭해 서버 편집 창을 연 뒤, 전송 보안이 TLS인지 확인하고 ‘SNI’ 또는 해당 서버 이름 항목을 점검하세요. 버전에 따라 항목 이름이 다를 수 있으므로 serverName의 의미와 비교하면 됩니다. v2rayNG에서는 노드 카드의 편집 메뉴로 들어가 TLS 설정의 SNI를 확인하세요. 호스트 이름 항목에 https://, :443, URL 경로를 함께 입력하면 안 됩니다.

• 연결 주소에 IP를 사용하더라도 도메인 SNI를 직접 입력해야 할 수 있습니다. SNI가 없으면 클라이언트가 IP를 기준으로 검증할 수 있지만 인증서에는 도메인만 포함되어 있을 수 있습니다.
• *.example.com은 일반적으로 a.example.com과 일치하지만, 이를 근거로 example.com이나 a.b.example.com에도 적용된다고 볼 수는 없습니다.
• ‘위장 도메인’은 화면에서 혼용되기 쉬운 표현입니다. 먼저 실제로 SNI를 뜻하는지 Host를 뜻하는지 확인하고, 관리자가 제공한 설정값과 하나씩 비교하세요.
• 구독을 업데이트한 뒤 문제가 다시 발생했다면 구독에 포함된 SNI가 이전 값인지 확인하세요. 로컬 복사본만 수정하면 다음 업데이트 때 변경 사항이 덮어써질 수 있습니다.

4. 인증서 체인과 서버가 실제로 반환하는 내용 확인하기

‘unknown authority’는 ‘인증서 만료’와 같은 뜻이 아닙니다. 도메인 인증서가 유효해도 중간 인증서가 누락되면 클라이언트가 신뢰 체인을 완성하지 못할 수 있습니다. 브라우저에서 접속된다고 해서 이 문제가 없다고 단정할 수는 없습니다. 브라우저와 프록시 코어가 사용하는 신뢰 저장소, 캐시, 중간 인증서 가져오기 방식이 다를 수 있습니다.

시스템에 OpenSSL이 설치되어 있다면 다음 명령으로 서버를 확인할 수 있습니다. 여기서 example.com은 문서용 예시 도메인이며 실제 노드 주소가 아닙니다. 실행 전에 명령의 도메인과 포트를 실제 값으로 바꾸세요. 연결 주소와 SNI가 다르면 -connect에는 실제 연결 대상을, -servername과 -verify_hostname에는 예상 TLS 호스트 이름을 입력합니다.

openssl s_client -connect example.com:443 -servername example.com -showcerts -verify_hostname example.com -verify_return_error

• 반환된 리프 인증서가 예상한 사이트의 것인지 확인하세요. 다른 사이트의 인증서가 반환되면 SNI와 서버 가상 호스트 설정을 점검해야 합니다.
• Certificate chain에 필요한 중간 인증서가 포함됐는지 확인하세요. 일반적으로 서버는 리프 인증서와 중간 인증서를 전송해야 하지만 루트 인증서까지 보낼 필요는 없습니다.
• 최종 검증 결과를 확인하세요. Verify return code: 0 (ok)는 현재 도구의 신뢰 환경에서 이번 테스트가 통과했다는 뜻일 뿐, 모든 기기에서도 반드시 통과한다는 의미는 아닙니다.
• OpenSSL에 CA 신뢰 경로가 올바르게 설정되지 않은 경우에도 발급자 오류가 나타날 수 있습니다. 서버 문제로 잘못 판단하지 않도록 먼저 테스트 도구의 신뢰 환경을 확인하세요.

관리자는 실제로 TLS를 종료하는 서비스에 전체 인증서 체인을 설정해야 합니다. 앞단에 리버스 프록시가 있다면 백엔드 코어 디렉터리의 파일만 바꿀 것이 아니라 리버스 프록시가 불러오는 인증서를 갱신해야 합니다. 갱신 후에는 관련 서비스를 다시 로드하고 외부에서 핸드셰이크를 재확인해 새 인증서가 반환되는지 확인하세요.

5. 수정 후 같은 조건으로 재검사하기

점검하면서 노드를 바꾸고 SNI를 수정하고 DNS를 전환하거나 Tun을 켜면 결과를 비교하기 어렵습니다. 같은 노드와 테스트 대상을 유지하고 한 번에 변수 하나만 조정하세요. 다음 순서대로 진행하면 설정을 수정해 해결된 것인지, 우연히 다른 정상 경로로 바뀐 것인지 구분할 수 있습니다.

1. 기준 상태 기록: 현재 노드 주소, 포트, TLS 유형, SNI와 오류 발생 시간을 기록하세요. 노드 인증 정보는 공개하지 마세요.
2. 시간 동기화 후 재검사: 노드 매개변수는 그대로 두고 시스템 시간만 동기화하세요. 유효 기간 오류가 사라지면 이름 또는 신뢰 체인 오류가 남아 있는지 확인하세요.
3. SNI 수정 후 재검사: 관리자가 제공한 값으로 SNI를 수정하고 다시 연결하세요. 새 로그에 표시된 검증 이름이 예상한 값인지 확인하세요.
4. 다른 네트워크와 비교: 같은 기기와 노드를 다른 네트워크에서 테스트하세요. 특정 네트워크에서만 다른 인증서가 반환되면 네트워크 차단, DNS 조회, 중간 장비를 점검하세요.
5. 수정 상태 유지 확인: 구독을 업데이트하고 클라이언트를 다시 연 뒤 한 번 더 테스트하세요. 수정한 값이 구독으로 덮어써졌는지, 서버가 여전히 이전 인증서를 반환하는지 확인하세요.

시간과 SNI가 올바른데도 인증서 만료 또는 체인 오류가 계속되면 클라이언트에서 해결할 수 있는 범위가 제한적입니다. 관리자에게 오류 원문, 테스트 시간, 클라이언트 및 코어 버전, 연결 포트, 예상 SNI를 전달하면 ‘노드가 작동하지 않는다’는 스크린샷만 보내는 것보다 원인 파악에 도움이 됩니다. 그 밖의 네트워크 및 코어 문제는 문제 해결 가이드를 참고하세요.

6. 자주 묻는 질문: 검증 건너뛰기와 핸드셰이크 중단