SSL 인증서기술 정보 확인 2026-10-24수정 2026-10-24

SSL 인증서 오류 해결, 날짜·도메인·체인 점검

브라우저에 “연결이 비공개로 설정되어 있지 않습니다” 같은 경고가 뜨면 방문자 대부분은 사이트를 떠납니다. 이 경고의 뒤에는 인증서 문제가 있고, 오류 코드를 읽으면 원인이 어느 쪽인지 대략 알 수 있습니다.

MDN은 서버 인증서가 사이트의 키를 도메인 이름에 묶어 주는 역할을 한다고 설명합니다. 브라우저는 일반적으로 인증서가 요청한 주소를 포함하는지, 현재 날짜가 유효 기간 안인지, 신뢰하는 발급 기관까지 이어지는지를 확인하며, 하나라도 어긋나면 경고를 띄웁니다. 이 글은 이 세 가지를 기준으로 원인을 나누어 점검하는 순서를 안내합니다. 오류 코드의 정확한 표기는 브라우저 버전에 따라 다를 수 있습니다.

오류 코드로 원인 좁히기

코드 이름이 다르더라도 대부분 위 세 가지 범주 안에 들어갑니다.

날짜 오류, 만료와 시계 문제

가장 흔한 경우입니다. 먼저 서버의 인증서 만료일을 확인합니다.

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

notAfter 날짜가 지났다면 SSL 인증서 갱신 방법에 따라 갱신하고 웹 서버를 reload합니다. 날짜가 충분히 남아 있는데도 오류가 난다면 방문자 기기의 시계를 의심할 수 있습니다. 컴퓨터나 휴대폰의 날짜가 과거나 미래로 틀어져 있으면 정상 인증서도 아직 유효하지 않거나 이미 만료된 것으로 판단됩니다. 서로 다른 기기와 네트워크에서 테스트해 보면 서버 문제인지 구분됩니다.

도메인 불일치 오류

인증서는 발급받을 때 적은 이름에만 유효합니다. 흔한 원인은 다음과 같습니다.

• 인증서가 example.com만 포함하고 www.example.com은 빠졌다.
• 서브도메인에 와일드카드가 아닌 일반 인증서를 그대로 썼다.
• 한 서버에 여러 사이트가 있는데 가상 호스트 설정이 달라 다른 사이트 인증서가 응답한다.
• 도메인을 옮겼는데 서버에 예전 인증서가 남아 있다.

인증서에 들어 있는 이름은 다음 명령으로 확인합니다.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

출력된 이름 목록에 접속한 주소가 있어야 합니다. 와일드카드(*.example.com)는 한 단계 하위 이름만 덮으며 최상위 example.com 자체는 따로 포함해야 하는 경우가 많습니다. Let’s Encrypt 문서에 따르면 와일드카드 인증서는 DNS-01 검증으로만 발급됩니다.

발급자 신뢰 오류와 체인 누락

서버 인증서는 보통 중간 인증서를 거쳐 루트 인증서로 이어집니다. 브라우저가 이 연결을 끝까지 따라가지 못하면 AUTHORITY_INVALID 계열의 오류가 납니다. 대표적인 원인은 두 가지입니다.

1. 서버가 서버 인증서만 보내고 중간 인증서를 빠뜨렸다.
2. 인증서가 자체 서명이거나 신뢰 목록에 없는 발급 기관의 것이다.

체인 누락은 데스크톱 브라우저에서는 괜찮고 일부 모바일이나 API 클라이언트에서만 실패하는 식으로 나타나서 찾기 어렵습니다. Let’s Encrypt 문서도 현대 플랫폼에서 흔한 실패 원인으로 올바른 체인을 보내지 않는 서버를 꼽습니다. Apache는 SSLCertificateFile 파일에 서버 인증서에 이어 중간 인증서를 서버 인증서부터 루트 방향 순서로 이어 넣을 수 있고(2.4.8 이상), nginx는 같은 파일 안에 서버 인증서를 먼저, 중간 인증서를 그다음에 두라고 설명합니다. certbot을 쓴다면 설정에 fullchain.pem을 지정합니다.

echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null | grep -E "s:|i:"

위 명령은 서버가 보내는 인증서 목록의 주체(s)와 발급자(i)를 보여 줍니다. 서버 인증서 외에 중간 인증서가 한 줄 이상 있어야 정상입니다.

기기와 환경 때문에 생기는 오류

서버 쪽을 모두 확인했는데도 일부 방문자에게만 오류가 난다면 환경 문제일 수 있습니다.

• 오래된 운영체제나 기기는 최신 루트 인증서를 신뢰 목록에 갖고 있지 않습니다. Let’s Encrypt는 호환성 문서에서 플랫폼별 신뢰 시작 버전을 정리해 두었습니다.
• 회사나 학교 네트워크, 보안 프로그램이 HTTPS 연결을 가로채 자체 인증서를 끼워 넣는 경우가 있습니다.
• 브라우저 캐시나 확장 프로그램이 원인인 경우는 시크릿 창으로 접속해 보면 알 수 있습니다.

점검 순서 요약

1. 다른 기기와 네트워크에서도 같은 오류가 나는지 확인한다.
2. openssl로 만료일과 도메인 이름을 확인한다.
3. 서버가 중간 인증서까지 보내는지 확인한다.
4. 웹 서버 설정이 올바른 파일(fullchain)을 가리키는지 확인하고 설정 검사 후 reload한다.
5. 그래도 안 되면 HTTPS 전반의 연결 문제를 다루는 HTTPS 연결 오류 해결 글로 넘어간다.

외부 공개 검사는 서버가 보내는 인증서만 볼 수 있으므로, 서버 내부의 파일 위치나 설정 오류는 서버에서 직접 확인해야 합니다.