SSL 오류 해결 3단계 — Cloudflare Pages 커스텀 도메인 가이드

Cloudflare Pages는 정적 사이트 배포에 최적화된 플랫폼이다. 커스텀 도메인을 연결하는 과정에서 SSL 인증서 관련 오류를 만나면 꽤 당황스럽다. 분명 DNS 설정도 했고, 도메인도 연결했는데 브라우저에 빨간 자물쇠가 뜨면서 ERR_SSL_VERSION_OR_CIPHER_MISMATCH 에러가 화면을 채울 때의 그 막막함이란… 배포는 성공했는데 사이트에 접속이 안 되는 상황, 생각보다 자주 발생한다.

이 문제는 대부분 Cloudflare의 SSL/TLS 설정과 DNS 레코드 구성이 맞물려 발생한다. 2026년 3월 기준으로 Cloudflare Pages의 커스텀 도메인 연결 과정에서 겪을 수 있는 SSL 오류 유형과 원인, 그리고 해결 방법을 정리했다.

📑 목차

주요 SSL 오류 유형
원인 분석: 왜 SSL 오류가 발생하는가
단계별 해결 방법
DNS 설정 점검
SSL/TLS 모드 올바르게 설정하기
인증서 발급 대기와 상태 확인
와일드카드 인증서와 서브도메인 처리
openssl로 인증서 상태 직접 확인하기
자주 하는 실수 모음

주요 SSL 오류 유형

Cloudflare Pages에 커스텀 도메인을 붙이고 나서 마주치는 SSL 오류는 크게 세 가지다.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH — Chrome에서 가장 흔하게 보이는 에러다. 서버가 제공하는 SSL 인증서의 버전이나 암호화 방식(cipher suite)이 브라우저와 맞지 않을 때 발생한다. 사실상 “인증서가 아직 준비 안 됐다”는 뜻인 경우가 많다.

SSL handshake failed (Error 525) — Cloudflare와 오리진 서버 간의 SSL 핸드셰이크가 실패했다는 의미다. Pages 자체에는 오리진 서버가 따로 없으니, 이 에러가 뜨면 SSL/TLS 모드 설정이 잘못된 경우다.

Invalid SSL certificate (Error 526) — Cloudflare가 오리진의 인증서를 검증하지 못했을 때 나타난다. Full (Strict) 모드에서 인증서가 아직 발급되지 않은 상태일 때 주로 발생한다.

원인 분석: 왜 SSL 오류가 발생하는가

SSL 오류의 원인을 파고 들어가면 결국 세 가지로 수렴한다.

DNS 전파 지연

도메인의 네임서버를 Cloudflare로 변경하거나, DNS 레코드를 수정한 직후에는 전파 시간이 필요하다. 보통 수 분에서 최대 48시간까지 걸릴 수 있는데, 이 기간 동안 Cloudflare가 인증서를 발급하려 해도 DNS 검증이 실패한다. 나도 처음에 DNS 변경 후 5분 만에 “왜 안 되지?”라며 새로고침을 연타한 적이 있다. DNS는 원래 느리다.

SSL/TLS 암호화 모드 불일치

Cloudflare 대시보드의 SSL/TLS 설정에는 네 가지 모드가 있다.

모드	동작	Pages 호환성
Off	암호화 없음	비권장
Flexible	브라우저↔Cloudflare만 암호화	동작하지만 비권장
Full	양쪽 암호화 (자체 서명 허용)	권장
Full (Strict)	양쪽 암호화 (유효한 인증서 필수)	권장 (인증서 발급 후)

문제는 Flexible 모드를 쓰면서 Pages의 기본 HTTPS 리다이렉션과 충돌하는 경우다. Flexible은 Cloudflare에서 오리진까지 HTTP로 연결하는데, Pages는 HTTPS를 강제하므로 무한 리다이렉트 루프(ERR_TOO_MANY_REDIRECTS)가 발생하거나 SSL 핸드셰이크가 깨진다.

CNAME 레코드 vs A 레코드 문제

Cloudflare Pages에 커스텀 도메인을 연결할 때 공식 문서는 CNAME 레코드를 권장한다. your-project.pages.dev를 타겟으로 CNAME을 설정하는 것이 표준 방식이다. 간혹 A 레코드로 특정 IP를 직접 지정하는 경우가 있는데, Cloudflare Pages는 고정 IP를 제공하지 않기 때문에 이 방식은 인증서 발급 자체가 안 된다.

단계별 해결 방법

SSL 오류를 만났을 때 확인해야 할 순서를 정리한다. 무작정 설정을 바꾸기보다 아래 순서대로 점검하면 대부분 해결된다.

DNS 설정 점검

가장 먼저 DNS 레코드가 올바른지 확인한다. Cloudflare 대시보드 > DNS > Records에서 다음을 점검하자.

# 루트 도메인(example.com) 설정
# Type: CNAME
# Name: @
# Target: your-project.pages.dev
# Proxy status: Proxied (주황색 구름)

# www 서브도메인 설정
# Type: CNAME
# Name: www
# Target: your-project.pages.dev
# Proxy status: Proxied (주황색 구름)

# 현재 DNS 상태 확인 (터미널에서)
dig example.com CNAME +short
dig www.example.com CNAME +short

# 네임서버 확인
dig example.com NS +short

여기서 중요한 포인트가 있다. Proxy status가 반드시 Proxied(주황색 구름 아이콘)로 되어 있어야 한다. DNS Only(회색 구름)로 설정하면 Cloudflare의 SSL 인증서가 적용되지 않아 바로 에러가 난다. 이거 하나 때문에 반나절을 날린 경험이 있어서 강조한다.

또한 Cloudflare Pages 대시보드에서도 커스텀 도메인 상태를 확인해야 한다. Pages 프로젝트 > Custom domains 탭에서 도메인 옆에 “Active” 상태가 표시되는지 보자. “Initializing”이나 “Verifying” 상태라면 아직 DNS 검증이 진행 중이다.

SSL/TLS 모드 올바르게 설정하기

Cloudflare 대시보드에서 SSL/TLS 메뉴로 이동한다. Overview 탭에서 암호화 모드를 Full 또는 Full (Strict)로 설정하자.

Cloudflare Dashboard
└─ 도메인 선택
   └─ SSL/TLS
      └─ Overview
         └─ Your SSL/TLS encryption mode
            ✗ Off
            ✗ Flexible        ← 이거 쓰면 안 됨
            ✓ Full             ← 권장
            ✓ Full (Strict)    ← 인증서 발급 완료 후 권장

Flexible에서 Full로 바꾸는 순간 기존에 발생하던 리다이렉트 루프가 해결되는 경우가 상당히 많다. 설정 변경 후 반영까지 수 분이 걸릴 수 있으니 바로 확인하지 말고 잠시 기다리자.

추가로, Edge Certificates 탭에서 “Always Use HTTPS” 옵션이 켜져 있는지도 확인한다. 이 옵션은 HTTP 요청을 자동으로 HTTPS로 리다이렉트한다. Pages를 사용한다면 켜두는 게 맞다.

그리고 한 가지 더—SSL/TLS 설정에서 “Minimum TLS Version”이 TLS 1.2 이상으로 되어 있는지 확인하자. 2026년 현재 TLS 1.0이나 1.1은 대부분의 브라우저에서 지원 중단된 상태다. 혹시 TLS 1.0으로 설정되어 있다면 일부 브라우저에서 연결 자체를 거부할 수 있다.

인증서 발급 대기와 상태 확인

DNS 설정과 SSL 모드를 올바르게 맞췄다면, 남은 건 인증서 발급을 기다리는 것이다. Cloudflare는 커스텀 도메인이 연결되면 자동으로 Universal SSL 인증서를 발급한다. 문제는 이 과정이 즉시 되지 않는다는 점이다.

공식 문서에 따르면 인증서 발급에 최대 24시간이 소요될 수 있지만, 경험상 DNS가 제대로 설정된 경우 15분~1시간 내에 완료된다. 조급함을 참기 어렵겠지만, 설정을 이리저리 건드리면 오히려 발급이 더 늦어진다.

인증서 발급 상태는 Cloudflare 대시보드 > SSL/TLS > Edge Certificates에서 확인할 수 있다. 상태값은 다음과 같다.

Initializing — 인증서 발급 프로세스 시작
Pending Validation — DNS 검증 대기 중
Pending Issuance — 검증 완료, 발급 대기
Pending Deployment — 발급 완료, 엣지 배포 중
Active — 완료. 정상 동작

“Pending Validation”에서 오래 머물러 있다면 DNS 레코드를 다시 점검해야 한다. 특히 CAA 레코드가 설정되어 있는 경우, Cloudflare의 인증서 발급 기관(CA)을 허용하는 항목이 있어야 한다.

# CAA 레코드 확인
dig example.com CAA +short

# Cloudflare가 사용하는 CA를 허용하려면 다음 CAA 레코드 추가
# (CAA 레코드가 아예 없다면 추가할 필요 없음 — 없으면 모든 CA 허용)
#
# example.com.  CAA  0 issue "digicert.com"
# example.com.  CAA  0 issue "letsencrypt.org"
# example.com.  CAA  0 issue "pki.goog"

# 인증서 발급 후 확인
curl -sI https://example.com | grep -i "server\|cf-ray"
# 정상이면 다음과 같이 출력됨:
# server: cloudflare
# cf-ray: 8a1b2c3d4e5f-ICN

와일드카드 인증서와 서브도메인 처리

블로그를 blog.example.com에 올리고 싶거나, docs.example.com 같은 서브도메인을 Pages에 연결하려는 경우가 있다. Cloudflare의 Universal SSL은 기본적으로 루트 도메인과 한 단계 서브도메인(*.example.com)까지 커버한다.

하지만 app.staging.example.com처럼 두 단계 이상의 서브도메인은 Universal SSL로 커버되지 않는다. 이런 경우 Advanced Certificate Manager(유료)를 사용하거나, 구조를 한 단계 서브도메인으로 바꿔야 한다.

각 서브도메인을 Pages에 연결할 때마다 Cloudflare Pages 대시보드의 Custom domains에 개별 등록해야 한다. DNS에 CNAME만 추가하고 Pages 프로젝트에 도메인 등록을 빼먹는 실수가 꽤 흔하다. DNS는 맞는데 Pages가 해당 도메인을 인식하지 못하면 인증서 발급이 트리거되지 않는다.

openssl로 인증서 상태 직접 확인하기

브라우저 에러 메시지만으로는 정확한 원인 파악이 어려울 때가 있다. 이럴 때 openssl 명령어로 서버의 인증서를 직접 확인하면 원인을 훨씬 빠르게 좁힐 수 있다.

# SSL 인증서 정보 확인
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | \
  openssl x509 -noout -dates -subject -issuer

# 출력 예시 (정상인 경우):
# notBefore=Mar 15 00:00:00 2026 GMT
# notAfter=Jun 13 23:59:59 2026 GMT
# subject=CN = example.com
# issuer=C = US, O = Cloudflare, Inc., CN = Cloudflare Inc ECC CA-3

# 인증서 체인 전체 확인
openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null | \
  grep -E "subject=|issuer="

# TLS 버전 확인
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | \
  grep "Protocol  :"
# 정상: Protocol  : TLSv1.3 또는 TLSv1.2

# 인증서가 아예 없는 경우의 출력:
# 140234567890:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
# → DNS가 아직 전파되지 않았거나, 인증서 발급 전 상태

-servername 플래그는 SNI(Server Name Indication)를 지정하는 옵션이다. Cloudflare는 하나의 IP에서 여러 도메인을 서빙하므로, 이 플래그 없이 테스트하면 엉뚱한 인증서 정보가 나올 수 있다. 솔직히 처음에 이걸 몰라서 “인증서 발급은 됐는데 왜 다른 도메인 인증서가 보이지?” 하고 한참 헤맸다.

자주 하는 실수 모음

여러 번 삽질하면서 정리한 실수 패턴이다. 하나라도 해당되면 바로 수정하자.

1. Proxy 상태를 DNS Only로 설정
회색 구름(DNS Only)으로 두면 Cloudflare의 SSL 인증서가 적용되지 않는다. Pages 커스텀 도메인은 반드시 주황색 구름(Proxied)이어야 한다.

2. 다른 DNS 제공자에서 네임서버를 바꾸지 않음
도메인을 다른 레지스트라(가비아, Namecheap 등)에서 구매했다면, 해당 레지스트라의 관리 페이지에서 네임서버를 Cloudflare가 제공하는 값으로 변경해야 한다. Cloudflare에 도메인을 추가하는 것만으로는 DNS 제어권이 넘어오지 않는다.

3. Pages 프로젝트에 도메인 등록 누락
Cloudflare DNS에 CNAME을 추가하는 것과, Pages 프로젝트 설정에서 Custom domain을 등록하는 것은 별개의 작업이다. 둘 다 해야 한다.

4. SSL 모드를 Flexible로 설정
앞서 설명했듯 Flexible 모드는 Pages와 궁합이 맞지 않는다. Full 또는 Full (Strict)를 사용하자.

5. 인증서 발급 전에 설정을 반복 변경
DNS 레코드를 추가했다 삭제했다, SSL 모드를 바꿨다 되돌렸다 하면 인증서 발급 프로세스가 초기화될 수 있다. 설정을 마친 후에는 최소 1시간은 기다리자. 안 되면 그때 점검해도 늦지 않다.

6. 기존 A 레코드와의 충돌
같은 호스트명에 A 레코드와 CNAME 레코드가 동시에 존재할 수 없다(DNS 표준). 루트 도메인에 기존 A 레코드가 있다면 삭제 후 CNAME으로 교체해야 한다. Cloudflare는 루트 도메인의 CNAME을 CNAME Flattening으로 처리하므로 기술적으로 문제없다.

트러블슈팅은 한 번에 끝나면 좋겠지만, 대부분 여러 원인이 겹쳐 있다. DNS 전파를 기다리는 동안 SSL 모드를 확인하고, openssl로 인증서 상태를 체크하는 식으로 병렬적으로 점검하면 시간을 아낄 수 있다. 안 되면 Cloudflare 대시보드에서 도메인을 제거하고 처음부터 다시 추가하는 것도 방법이다. 깔끔하게 리셋하면 의외로 금방 해결되는 경우가 많으니까.