도메인 연결 후 SSL 인증서 설치·검증 체크리스트
DNS부터 인증서, HTTPS 리디렉션, HSTS와 혼합 콘텐츠까지 실제 websalim.com 검증 결과로 확인하는 SSL 운영 체크리스트입니다.
도메인에 HTTPS를 적용할 때는 인증서 발급만 확인해서는 부족합니다. DNS가 올바른 서버를 가리키는지, HTTP 요청이 HTTPS로 이동하는지, 브라우저가 받은 인증서의 이름과 유효기간이 맞는지, 페이지 안에 HTTP 리소스가 남아 있지 않은지까지 확인해야 작업이 끝납니다. 이 글은 특정 호스팅 업체의 메뉴를 추정하지 않고, 어떤 관리형 호스팅이나 가상서버에서도 다시 확인할 수 있는 명령과 판정 기준을 제공합니다.
검증 범위와 2026년 8월 31일 결과
아래 결과는 2026년 8월 31일에 macOS의 curl 8.7.1, LibreSSL 3.3.6, 실제 운영 도메인 websalim.com을 대상으로 확인했습니다. 호스팅 업체의 로그인 후 관리자 화면은 이번 검증 범위에 포함하지 않았습니다. 메뉴 이름과 버튼 위치는 계정 상품·관리자 개편에 따라 달라질 수 있으므로, 확인하지 못한 업체별 절차를 이 글에서 단정하지 않습니다.
| 확인 항목 | 실제 확인 결과 | 통과 기준 |
|---|---|---|
| 인증서 주체 | CN=websalim.com | 접속한 호스트명이 인증서 SAN 또는 주체와 일치 |
| 발급자 | Let’s Encrypt YR1 | 브라우저가 신뢰하는 인증기관 체인 |
| 유효기간 | 2026-07-27 02:51:32 UTC부터 2026-10-25 02:51:31 UTC까지 | 현재 시각이 유효기간 안에 있고 자동 갱신 여유가 있음 |
| HTTP 이동 | http://websalim.com/ 요청이 308로 HTTPS 이동 | 모든 공개 HTTP 경로가 대응하는 HTTPS 경로로 이동 |
| HTTPS 응답 | HTTP/2 200 | 인증서 경고 없이 정상 응답 |
| HSTS | max-age=63072000 | HTTPS에서만 헤더가 전달되고 운영 정책과 일치 |
| 혼합 콘텐츠 1차 검사 | 홈과 이 글의 HTML 속성에서 불안전한 http:// 리소스 0건 | 이미지·스크립트·스타일·폰트가 HTTPS 또는 안전한 상대 경로 사용 |
이 표는 “인증서가 있다”는 사실과 “사이트가 HTTPS로 안전하게 제공된다”는 결과를 구분합니다. 인증서가 정상이어도 리디렉션 반복, 잘못된 도메인, 혼합 콘텐츠가 남아 있으면 방문자는 오류를 겪을 수 있습니다.
설치 전에 확인할 네 가지
첫째, DNS가 실제 웹 서버 또는 관리형 호스팅이 안내한 대상으로 연결되어야 합니다. 인증기관은 도메인 소유 또는 서버 도달 가능성을 확인하므로, 이전 서버를 가리키는 A·AAAA·CNAME 레코드가 남아 있으면 발급이 실패하거나 엉뚱한 서버의 인증서가 보일 수 있습니다.
둘째, example.com과 www.example.com을 모두 운영한다면 인증서에 두 이름이 모두 포함되는지 결정합니다. 한 이름만 쓸 계획이면 사용하지 않는 호스트를 대표 주소로 리디렉션할지 먼저 정합니다. 인증서 이름과 실제 접속 주소의 불일치가 가장 흔한 경고 원인 중 하나입니다.
셋째, 80번과 443번 포트의 외부 접근 경로를 확인합니다. 방화벽, 보안 그룹, 프록시, CDN 중 한 곳이라도 요청을 막으면 발급 검증 또는 실제 HTTPS 접속이 실패할 수 있습니다.
넷째, 변경 전 현재 DNS 값과 웹 서버 설정을 기록합니다. 관리형 호스팅이라면 도메인 연결 상태와 인증서 상태 화면을 본인 계정에서 캡처하고, 가상서버라면 웹 서버 설정 파일과 적용 전 헤더를 저장해 두면 되돌릴 기준이 생깁니다.
dig +short example.com A
dig +short www.example.com CNAME
curl -I http://example.com/
curl -I https://example.com/관리형 호스팅과 가상서버의 작업 경계
관리형 호스팅은 보통 도메인 연결이 완료되면 서비스가 인증서 발급과 갱신을 맡습니다. 이 경우 중요한 일은 임의의 메뉴 이름을 따라 하는 것이 아니라, 서비스가 요구하는 DNS 값과 연결 상태를 공식 도움말에서 확인하고 발급 완료 뒤 외부에서 다시 검증하는 것입니다. 관리자 화면의 “완료” 표시만으로 HTTP 리디렉션과 혼합 콘텐츠까지 확인했다고 볼 수는 없습니다.
가상서버에서는 웹 서버와 인증서 갱신 작업을 운영자가 관리합니다. Certbot을 사용한다면 운영체제와 Nginx·Apache 등 웹 서버를 선택해 공식 설치 안내가 생성한 명령을 사용합니다. 블로그에 복사된 오래된 저장소 추가 명령을 그대로 실행하지 말고, 현재 서버 환경에 맞는 Certbot 공식 안내를 기준으로 해야 합니다.
설치 전에는 설정 문법을 검사하고, 적용 뒤에는 새 프로세스가 실제 인증서 파일을 읽었는지 확인합니다. 예를 들어 Nginx에서는 다음과 같이 문법 검사 후 재적용할 수 있습니다. 서버 배포판과 권한 정책이 다르면 서비스 운영 문서에 맞게 명령을 조정합니다.
sudo nginx -t
sudo systemctl reload nginx자동 갱신을 사용하는 경우 “예약 작업이 등록됐다”는 사실과 “갱신 후 웹 서버가 새 인증서를 제공한다”는 결과를 나누어 확인합니다. 테스트 갱신이 성공해도 웹 서버 재적용 훅이 빠지면 만료 직전까지 이전 인증서를 계속 제공할 수 있습니다.
1단계: 브라우저가 받는 인증서 확인
서버 내부 파일이 아니라 외부 클라이언트가 실제로 받는 인증서를 확인해야 합니다. CDN이나 리버스 프록시를 사용하면 원본 서버의 인증서와 방문자가 받는 인증서가 다를 수 있기 때문입니다.
openssl s_client \
-connect example.com:443 \
-servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltNamesubjectAltName에 접속 호스트가 포함되는지, notBefore와 notAfter 사이에 현재 시각이 있는지, 발급자 체인이 예상한 인증기관인지 확인합니다. 같은 서버에 여러 도메인이 있을 때 -servername을 빼면 기본 가상호스트의 인증서가 반환될 수 있으므로 SNI 값을 반드시 넣습니다.
2단계: HTTP에서 HTTPS로 한 번만 이동하는지 확인
대표 주소 정책을 먼저 정한 뒤 각 변형을 검사합니다. http://example.com, http://www.example.com, https://www.example.com이 모두 최종 대표 주소로 수렴해야 하며, 두 설정이 서로 반대 방향으로 보내는 리디렉션 반복이 없어야 합니다.
curl -sS -o /dev/null -D - http://example.com/
curl -sS -o /dev/null -D - https://example.com/
curl -sS -o /dev/null -L -w '%{url_effective} %{http_code}\n' http://example.com/첫 응답에서는 Location이 의도한 HTTPS 주소인지 확인합니다. 마지막 명령은 전체 이동을 따라간 뒤 최종 주소와 상태 코드를 보여 줍니다. 경로를 버리고 항상 홈으로 보내면 방문자가 저장한 상세 링크와 검색엔진 신호가 손실될 수 있으므로 동일 경로를 유지하는 편이 좋습니다.
3단계: 혼합 콘텐츠와 보안 헤더 확인
HTTPS 문서가 HTTP 이미지·스크립트·스타일을 요청하면 브라우저는 일부 리소스를 차단하거나 페이지를 안전하지 않다고 표시할 수 있습니다. HTML 문자열만 검사하면 자바스크립트가 나중에 만든 요청을 놓치므로, 브라우저 개발자 도구의 Console과 Network 탭에서 페이지를 새로고침해 Mixed Content 경고와 http:// 요청을 함께 확인합니다.
curl -fsS https://example.com/ \
| grep -Eo '(src|href)=["'"'][^"'"']*http://[^"'"']+' || trueHSTS는 브라우저가 이후 HTTP 접속을 HTTPS로 바꾸도록 지시합니다. 충분히 검증하기 전에 긴 기간과 하위 도메인 포함 정책을 먼저 켜면, HTTPS가 준비되지 않은 하위 도메인까지 접속이 막힐 수 있습니다. 먼저 모든 대상 호스트의 HTTPS를 확인하고, HTTPS 응답에서만 Strict-Transport-Security가 전달되는지 검사합니다.
curl -sSI https://example.com/ \
| grep -i '^strict-transport-security:'오류별 판정과 해결 순서
| 증상 | 먼저 볼 값 | 다음 조치 |
|---|---|---|
| 인증서 이름 불일치 | SAN과 최종 접속 호스트 | 필요한 호스트를 인증서에 포함하거나 대표 주소로 일관되게 이동 |
| 발급 검증 실패 | A·AAAA·CNAME, 80번 포트, CDN 프록시 | DNS 전파와 외부 도달 경로를 확인한 뒤 재시도 |
| 인증서 만료 또는 갱신 실패 | notAfter, 갱신 로그, 웹 서버 재적용 시각 | 자동 갱신 테스트와 재적용 훅을 각각 확인 |
| 리디렉션 반복 | 각 단계의 Location | CDN·호스팅·애플리케이션 중 한 계층만 대표 정책을 담당하도록 정리 |
| 일부 자원만 차단 | 브라우저 Network의 요청 URL | 템플릿·데이터베이스·외부 위젯의 절대 HTTP 주소를 HTTPS 또는 상대 경로로 변경 |
| 서버에서는 정상, 외부는 오류 | DNS 대상, CDN 인증서, 캐시 | 원본과 엣지에서 제공하는 인증서를 나누어 확인하고 캐시를 갱신 |
공개 전 최종 체크리스트
- 대표 도메인과
www사용 여부를 정했다. - DNS가 현재 서비스가 안내한 대상으로 연결된다.
- 외부에서 받은 인증서의 SAN·발급자·유효기간을 확인했다.
- 모든 HTTP 변형이 동일 경로의 대표 HTTPS 주소로 수렴한다.
- 홈과 주요 상세 페이지를 브라우저 개발자 도구로 검사했다.
- 혼합 콘텐츠 요청과 인증서 경고가 없다.
- 자동 갱신 테스트와 웹 서버 재적용 경로를 확인했다.
- 검증 날짜, 도구 버전, 대상 도메인과 결과를 운영 기록에 남겼다.
인증서 설치는 한 번의 버튼 작업이 아니라 DNS, TLS, 리디렉션, 페이지 리소스를 연결해 확인하는 운영 절차입니다. 업체별 화면을 실제 계정에서 확인하지 못했다면 업체명을 붙인 메뉴 안내를 공개하지 말고, 공식 도움말과 위 외부 검증 결과를 함께 기록하는 것이 안전합니다.
참고 자료
- MDN TLS 구성 실무 가이드 — 확인일 2026-08-31
- MDN 혼합 콘텐츠 방어 — 확인일 2026-08-31
- MDN Strict-Transport-Security — 확인일 2026-08-31
- Certbot 공식 설치 안내 — 확인일 2026-08-31
- 웹살림 SEO 점검 순서 — 내부 연결