도메인을 연결하고 관리 화면을 열었더니 보안 접속 인증서가 '발급 대기 중'에서 꿈쩍도 하지 않았습니다. 처음 세 시간은 원래 그런가 보다 했는데, 새벽 1시에 새로고침을 열 번째 누르자 손에 땀이 났습니다. 주소창에는 '안전하지 않음'이 그대로였고, 같은 시기에 만든 구글 블로그는 HTTPS 가용성이 '대기중'에서 이틀 가까이 멈춰 있었습니다. 두 곳은 원인이 서로 달랐고 해결 시간도 달랐습니다. 아래는 그 과정을 점검 순서대로 정리한 기록입니다.
.webp)
1. 정상 대기인지 오류인지 먼저 구분하기
DNS를 막 수정했다면 기다려야 하는 구간이 있습니다. 문제는 그 구간을 넘기고도 그대로인 경우입니다.
| 구분 | 정상 대기 범위 | 이 시간을 넘기면 |
| 티스토리 | 수분~수시간, 화면 안내상 최대 약 7일 | 2번 점검표로 이동 |
| 구글 블로그 | 도메인 반영은 공식 도움말 기준 최대 24시간, HTTPS도 대체로 비슷한 범위 | 24시간 뒤 2번 점검표로 이동 |
꿀팁: 대기 중에 도메인을 지웠다 다시 등록하면 처음부터 줄을 서는 경우가 많습니다. 저는 이 실수로 다섯 시간을 날렸습니다. DNS가 맞다는 확신이 들 때까지는 건드리지 마세요.
.webp)
2. 원인별 점검표 (실제로 많이 걸리는 7가지)
| 번호 | 원인 | 대표 증상 | 해결 |
| 1 | 티스토리 CNAME 값 오류 | DNS 확인 실패, 대기 지속 | 대상에 내 tistory 주소가 아니라 host.tistory.io 입력 |
| 2 | 같은 호스트에 A와 CNAME 중복 | 주차 페이지가 열림 | 한 호스트에는 하나만 남김 |
| 3 | 구글 블로그 보안 CNAME 누락·오타 | 도메인 인증 실패 | 블로그마다 다른 두 번째 CNAME을 그대로 복사 |
| 4 | 호스트칸에 전체 주소 입력 | 호스트칸에는 www 또는 안내된 이름만 입력 | |
| 5 | 예전 A·AAAA 레코드 잔존 | 엉뚱한 서버가 응답 | 기존 A 레코드 삭제(구글 도움말 안내), AAAA도 점검 |
| 6 | CAA 레코드 제한 | 며칠째 대기 | 구글 블로그는 letsencrypt.org 허용 필수 |
| 7 | Cloudflare 프록시·DNSSEC | 인증 검증 방해 | 프록시를 DNS 전용으로 변경, DNSSEC 상태 확인 |
⚠️ 주의: 5번에서 지우는 것은 웹 연결용 레코드뿐입니다. MX와 TXT는 메일과 소유권 인증에 쓰이므로 용도를 모르면 지우지 말고 먼저 화면을 캡처해 두세요.
3. 초보자용 단계별 해결 매뉴얼
STEP 1. 실제 DNS 관리처부터 확인합니다.
도메인을 산 곳과 DNS를 관리하는 곳이 다를 수 있습니다. 도메인 관리 화면의 네임서버를 보고, 그 네임서버를 운영하는 곳에서 레코드를 고쳐야 합니다. 저는 구입처 화면만 열 번 고치고 반영이 없어 한 시간을 허비했는데, 네임서버가 다른 곳이었습니다.
STEP 2. 현재 레코드를 직접 조회합니다.
윈도우 명령 프롬프트에서 아래를 실행합니다. 맥과 리눅스는 dig를 씁니다.
```
nslookup -type=CNAME www.내도메인.com
dig CAA 내도메인.com +short
```
티스토리는 결과에 host.tistory.io, 구글 블로그는 ghs.google.com이 나와야 합니다. 안 나오면 아직 전파 전이거나 값이 틀린 것입니다.
STEP 3. 플랫폼별 정답 값과 대조합니다.
| 항목 | 티스토리 | 구글 블로그 |
| 대표 방식 | CNAME 하나 | CNAME 두 개 |
| 연결 대상 | host.tistory.io | ghs.google.com + 블로그 고유 보안 CNAME |
| 루트 도메인 | CNAME 불가 시에만 공식 A 레코드 (27.0.236.139) 예외 | A 레코드 4개: 216.239.32.21, 34.21, 36.21, 38.21 |
| 등록 위치 | 관리 > 블로그 > 개인 도메인 설정 | 설정 > 게시 > 커스텀 도메인 |
티스토리 A 레코드는 서버 사정으로 바뀔 수 있으니 쓰기 전에 최신 공식 공지를 확인하세요. 티스토리에 등록하는 도메인은 DNS와 똑같이 www 포함 여부까지 맞춰야 합니다.
STEP 4. CAA를 점검합니다.
구글 도움말은 CAA 레코드를 쓰는 경우 letsencrypt.org 레코드를 추가해야 블로그의 인증서가 생성·갱신된다고 안내합니다. 제 구글 블로그의 원인이 바로 이것이었습니다. 예전에 보안 설정으로 넣어 둔 CAA를 까맣게 잊고 있었습니다. 티스토리는 CAA 때문에 막힌다는 공식 안내를 확인하지 못했지만, 조회 결과에 CAA가 있다면 임시로 지우고 지켜보는 방법이 있습니다.
STEP 5. 프록시와 DNSSEC를 끕니다.
Cloudflare를 쓴다면 해당 레코드의 주황색 구름을 눌러 회색(DNS 전용)으로 바꿉니다.
STEP 6. 건드리지 말고 기다립니다.
수정 후에는 최소 1~2시간 동안 아무것도 바꾸지 마세요. 저는 티스토리가 약 9시간, 구글 블로그는 CAA 수정 후 약 4시간 뒤 '완료'로 바뀌었습니다.
💡 꿀팁: 확인은 시크릿 창과 스마트폰 모바일 데이터로 하세요. 내 PC의 DNS 캐시 때문에 옛 화면이 보일 수 있고, 필요하면 ipconfig /flushdns로 비웁니다.
4. 그래도 해결되지 않을 때 다음 순서
1. 구글 블로그는 HTTPS 가용성을 끄고 다시 켠 뒤 2~3시간 기다립니다.
2. 그래도 안 되면 커스텀 도메인을 삭제하고 24시간 뒤 새 보안 CNAME으로 재설정합니다.
3. 티스토리는 7일이 지나도 대기라면 도메인, 조회 결과 캡처, 등록 시각을 정리해 고객센터에 문의합니다.
4. 루트 도메인이 막힌다면 www 주소를 대표주소로 쓰고 루트는 리디렉션으로 모읍니다.
5. 최후에는 개인 도메인을 해제하고 기본 주소로 운영하다가 DNS를 정리한 뒤 다시 연결합니다.
📌 알고 나면 시선이 달라지는 [스팀 디스크 쓰기 오류 해결, 백신 예외 설정 1분 점검과 설치 실패 복구법 ] 이야기도 놓치지 마세요.
5. 해결 전후 차이와 부작용
| 항목 | 해결 전 | 해결 후 |
| 주소창 | 안전하지 않음 경고 | 자물쇠 표시 |
| 접속 | HTTP 또는 인증서 오류 | HTTPS 정상, 자동 이동 |
| 검색 등록 | 소유권 확인 보류 | 서치콘솔·서치어드바이저 등록 가능 |
주의할 부작용도 있습니다. 첫째, 개인 도메인은 기존 기본 주소와 별개의 URL로 인식되어 색인이 다시 잡히는 동안 유입이 잠시 줄 수 있습니다. 둘째, 스킨이나 본문에 http 이미지가 남아 있으면 '보안 연결이 완벽하지 않음' 경고가 뜹니다. 셋째, 구글 블로그에서 CAA를 지웠다면 인증기관 제한이 풀리는 만큼 필요한 CA만 남기는 쪽이 안전합니다. 넷째, 애드센스에 새 도메인이 등록되어 있는지와 ads.txt 상태를 인증서 완료 후 확인하세요.
🔗네이버 인증서 오류 해결부터 공동인증서 갱신까지 1분 컷 완벽 가이드 (초보자 필독 해결책)
6. 자주 묻는 질문
Q. 발급 대기가 며칠이면 비정상인가요?
티스토리는 7일, 구글 블로그는 24시간을 넘기면 점검 대상입니다.
Q. 인증서를 따로 사서 설치해야 하나요?
아닙니다. 두 서비스 모두 연결하면 자동으로 발급됩니다.
Q. www와 루트 중 어느 쪽이 유리한가요?
검색 유불리보다 하나로 통일하는 것이 중요합니다.
정리하면 이 오류의 대부분은 레코드 값 오타, 중복 레코드, CAA 세 가지에서 나왔습니다. 값을 하나씩 대조하고, 고친 뒤에는 기다리는 것이 가장 빠른 길이었습니다.
댓글 쓰기