01DEFINITION
한 줄로 말하면
인증서에 적힌 이름이 지금 주소와 다르면, 인증서가 설치되어 있어도 없는 것과 같습니다. www 를 붙인 주소와 안 붙인 주소 중 한쪽만 넣은 경우가 가장 흔하고, 공유 호스팅에서는 우리 도메인용 설정이 빠져 아예 남의 인증서가 나가기도 합니다. 사람은 경고를 한 번 누르고 들어올 수 있지만 기계는 그렇지 않습니다 — 검색엔진 크롤러와 AI 답변엔진은 이름이 맞지 않으면 연결 자체를 끊습니다. 그 사이트는 색인에도, 답변에도 등장하지 않습니다. 만료와는 고치는 방법도 다릅니다. 만료는 갱신이지만 이것은 재발급이고, 재발급할 때 도메인 목록에 www 를 붙인 주소와 안 붙인 주소를 둘 다 넣어야 합니다.
02RISK
없으면 무슨 일이 생기나
가장 중요한 차이는 사람과 기계가 다르게 반응한다는 점입니다. 방문자는 경고 화면에서 "계속 진행"을 눌러 들어올 수 있습니다. 검색엔진 크롤러와 AI 답변엔진은 그 버튼을 누르지 않습니다. 엄격 검증을 하는 클라이언트에게 이 사이트는 접속 불가이고, 접속하지 못한 사이트는 색인되지도 인용되지도 않습니다.
그래서 증상이 "사이트가 안 열린다"가 아니라 "검색에서 사라졌다"로 나타납니다. 운영자는 늘 쓰던 브라우저로 잘 들어가지므로 사이트에 문제가 있다고 생각하지 않고, 순위 하락이나 유입 감소의 원인을 콘텐츠에서 찾습니다. 원인이 인증서라는 것을 알기까지 몇 달이 걸리기도 합니다.
가장 흔한 형태는 www 를 붙인 주소와 안 붙인 주소 중 한쪽만 인증서에 들어 있는 경우입니다. 둘 다 실제로 쓰이는데 한쪽만 정상이면, 그 주소로 들어온 방문자와 그 주소를 저장해 둔 크롤러가 통째로 막힙니다.
공유 호스팅에서는 다른 모양으로 나타납니다. 우리 도메인용 설정이 서버에 없으면 요청이 서버의 기본 설정으로 떨어지고, 그 자리에 있는 다른 계정의 인증서가 응답합니다. 이 경우 인증서는 멀쩡히 살아 있지만 이름이 남의 것이고, 만료된 지 몇 년 지난 것이 그대로 나가고 있기도 합니다.
서버끼리 주고받는 연결도 조용히 끊깁니다. 결제 승인 통보나 외부 서비스의 웹훅은 경고 화면을 보여 줄 사람이 없어 그냥 실패합니다. 주문은 들어왔는데 후속 처리가 안 되는 형태로 나타나서 원인을 찾기까지 시간이 걸립니다.
03CHECK IT YOURSELF
직접 확인하는 방법
아래는 저희를 거치지 않고 지금 해 보실 수 있는 방법입니다. 결과를 저희에게 보내실 필요도 없습니다.
-
01
인증서에 어떤 이름이 들어 있는지 본다
SAN 목록에 실제로 쓰는 주소가 전부 있어야 합니다. 여기 없는 주소는 전부 경고 대상입니다. 아래처럼 발급 대상(subject)까지 같이 보면, 이름이 빠진 것인지 아예 남의 인증서인지 한 번에 구분됩니다.
$ openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \ | openssl x509 -noout -subject -ext subjectAltName subject=CN=example.com DNS:example.com, DNS:www.example.com -
02
www 를 붙인 주소로도 따로 확인한다
두 주소는 별개의 검사입니다. 한쪽만 확인하고 넘어가면 절반이 막혀 있는 상태를 그대로 지나칩니다. -servername 값을 바꿔 두 번 돌리십시오.
$ openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null \ | openssl x509 -noout -subject
-
03
검증을 켠 채로 접속해 본다
사람이 아니라 기계가 보는 결과를 그대로 보는 방법입니다. curl 은 기본으로 검증을 하므로, 여기서 실패하면 크롤러도 같은 자리에서 실패합니다. -k 를 붙여 성공한다면 그것이 곧 이름 불일치의 증거입니다.
$ curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/ curl: (60) SSL: no alternative certificate subject name matches target host name $ curl -sSk -o /dev/null -w '%{http_code}\n' https://example.com/ 200 -
04
남의 인증서가 나오는지 본다
발급 대상이 우리 도메인과 전혀 상관없는 이름이라면 인증서가 잘못된 것이 아니라 우리 도메인용 설정이 서버에 없는 것입니다. 고치는 곳이 인증서가 아니라 호스팅 설정이므로 구분이 중요합니다.
04HOW TO FIX
고치는 방법
서버 환경에 따라 적을 자리가 다릅니다. 아래는 가장 흔한 구성 기준이고, 적용 전에 현재 설정을 백업하십시오.
만료와 달리 갱신으로는 해결되지 않습니다. 같은 이름으로 다시 받으면 같은 상태가 됩니다. 발급 시점에 도메인 목록을 다시 지정해야 하고, 발급 후 두 주소 모두로 열어 확인하십시오.
$ sudo certbot certonly -d example.com -d www.example.com
남의 인증서가 나오는 상태는 계정 안에서 고칠 수 없습니다. 서버에 우리 도메인용 설정이 만들어져야 하므로 호스팅 관리 화면에서 SSL 을 신청하거나 지원팀에 요청하십시오. 신청할 때 www 를 붙인 주소와 안 붙인 주소를 둘 다 적어야 합니다.
파일 방식으로 소유를 확인하는 경우, 그 경로가 리다이렉트되거나 재작성 규칙에 삼켜지면 발급이 실패합니다. 실제 파일을 하나 올려 두고 받아지는지 먼저 보면 발급 전에 알 수 있습니다.
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L] 두 주소를 다 인증서에 넣은 뒤, 실제 서비스는 한쪽으로 리다이렉트해 모으는 것이 관리하기 쉽습니다. 다만 리다이렉트는 인증서가 유효해진 다음에 할 일입니다. 순서가 바뀌면 리다이렉트 전에 경고 화면부터 뜹니다.
05FAQ
자주 묻는 질문
브라우저에서는 잘 열리는데 왜 문제인가요
- 브라우저가 사람에게 선택권을 주기 때문입니다. 경고를 한 번 누르면 들어와지고, 한 번 누른 뒤에는 그 브라우저가 기억해서 다음부터 경고도 안 뜹니다. 그래서 운영자에게는 아무 문제가 없어 보입니다. 검색엔진 크롤러와 AI 답변엔진에는 누를 사람이 없어 연결이 그대로 끊깁니다.
www 를 안 쓰는데도 넣어야 하나요
- 넣어 두시는 편이 좋습니다. 방문자가 습관적으로 붙여 치고, 오래된 명함과 옛 링크에 www 주소가 남아 있습니다. 그리고 www 를 안 쓰는 사이트로 만들려면 www 주소를 리다이렉트해야 하는데, 그 리다이렉트가 동작하려면 인증서에 www 가 들어 있어야 합니다.
인증서가 남의 이름으로 나옵니다. 우리가 잘못 설치한 건가요
- 대개 설치 문제가 아니라 서버에 우리 도메인용 설정이 없는 것입니다. 공유 호스팅에서 요청이 갈 곳을 못 찾으면 서버의 기본 설정으로 떨어지고 거기 있는 인증서가 응답합니다. 계정 안에서는 고칠 수 없으므로 호스팅사에 SSL 적용을 요청하십시오.
이 항목이 실패로 뜨면 얼마나 급한가요
- 검색과 AI 답변에서 노출을 만들고 계신다면 가장 급한 축입니다. 순위가 떨어지는 것이 아니라 대상에서 빠지는 종류이고, 콘텐츠를 아무리 늘려도 읽히지 않기 때문에 다른 개선이 전부 헛돕니다. 반대로 사이트가 내부용이고 사람만 들어오는 곳이라면 급하지는 않습니다.
RELATED
같이 보시면 좋은 항목
GET STARTED
내 사이트는
이 항목을 통과할까요
주소만 넣으시면 이 항목을 포함해 25가지를 판정해 점수와 실패 개수를 보여 드립니다. 로그인도, 소유 확인도 필요 없습니다 — 전부 밖에서 관찰만 하는 항목이기 때문입니다.