홈페이지 SSL 인증서 갱신, 1년에 한 번으로는 부족해졌어요

인증서 갱신은 오랫동안 1년에 한 번 하는 일이었어요. 갱신 안내가 오면 새 인증서를 받아 서버에 올리면 끝이었죠. 2026년 3월 15일부터는 이 주기가 맞지 않아요. 새로 발급되는 웹사이트용 인증서는 한 장에 최대 200일까지만 쓸 수 있고, 무료 인증서를 발급하는 Let's Encrypt는 2025년 6월부터 만료 안내 메일을 보내지 않거든요.

이 글은 홈페이지 담당자와 개발 담당자가 직접 확인할 수 있는 것 위주로 정리했어요. 확인 명령은 삼삼삼 홈페이지에 2026년 10월 21일 실제로 돌려 본 결과와 함께 실었어요.

2026년 3월부터 달라진 것

웹사이트용 공개 인증서의 규칙은 인증기관과 브라우저 회사가 함께 만드는 CA/Browser Forum이 정해요. 2025년 4월 통과된 개정(SC-081v3)에 따라 인증서 한 장의 최대 유효기간이 세 단계에 걸쳐 줄어요.

오른쪽 칸은 ‘이 도메인의 관리자가 맞다’는 확인 결과를 다음 발급 때 그대로 쓸 수 있는 기간이에요. 2029년에는 10일이 되니, 인증서를 새로 받을 때마다 도메인 확인을 다시 거친다고 생각하는 편이 맞아요.

헷갈리기 쉬운 건 인증서 상품의 기간과 인증서 한 장의 기간이 따로 간다는 점이에요. 1년짜리 상품을 샀어도 지금 규칙에서는 1년을 쓰려면 인증서가 적어도 두 장, 2027년 3월 15일부터는 적어도 네 장 필요해요. 그때마다 새 인증서를 받아 서버에 바꿔 넣어야 하고요.

무료 인증서는 일정이 조금 달라요. Let's Encrypt는 지금 기본으로 90일짜리를 발급하는데, 2027년 2월 10일부터 64일, 2028년 2월 16일부터 45일로 줄일 예정이에요. 이미 200일보다 짧아서 위 규칙의 영향은 없지만, 2025년 6월 4일부터 만료 안내 메일을 보내지 않는다는 점은 알아 둬야 해요. 자동 갱신이 멈춰도 Let's Encrypt 쪽에서는 알려 주지 않아요.

브라우저 쪽에서도 바뀐 게 있어요. Chrome은 컴퓨터용 154 버전(2026년 9월 22일 배포)과 Android용 155 버전(2026년 10월 6일 배포)부터, http로 열리는 사이트에 들어갈 때 계속 들어갈지 먼저 묻는 화면을 기본으로 띄워요. 인증서 오류 경고와는 다른 화면이지만, 아직 http로만 열리는 홈페이지라면 인증서를 붙일 때가 된 거예요.

지금 우리 인증서를 확인하는 법

Chrome에서는 주소창의 주소 왼쪽 기호를 누르면 연결이 안전한지 나와요. 다만 브라우저 화면은 서버 설정의 빈틈을 가려 줄 때가 있어요. 뒤에서 다룰 중간 인증서 누락이 대표적이에요. 개발 담당자가 있다면 서버가 실제로 내보내는 인증서를 터미널에서 직접 보는 편이 확실해요. 맥·리눅스 터미널에서 example.com 자리에 우리 주소를 넣어 돌리면 되고, Windows는 WSL이나 Git Bash에서 돌려요.

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

인증서의 대표 이름(subject), 발급 기관(issuer), 시작일(notBefore), 만료일(notAfter)이 나와요. 시간은 GMT라 한국 시간으로는 9시간을 더해요.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

인증서에 든 도메인 목록이에요. www가 붙은 주소와 안 붙은 주소를 둘 다 쓴다면 둘 다 들어 있어야 해요.

echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null \
  | grep -E "^ *[0-9] s:|^ *i:|Verify return code"

서버가 보내는 인증서 묶음이에요. 0번이 우리 인증서, 1번이 중간 인증서예요. 1번이 없으면 중간 인증서가 빠진 거예요. 0번의 i:(발급자)와 1번의 s:(이름)가 같은지도 보고, 마지막 줄이 Verify return code: 0 (ok)면 검증을 통과한 거예요.

삼삼삼 홈페이지에 직접 돌려 본 결과

2026년 10월 21일 오후 5시 26분(한국 시간)에 첫 번째와 세 번째 명령을 돌린 결과예요.

subject=CN=333.tego-x.com
issuer=C=US, O=Let's Encrypt, CN=YR2
notBefore=Sep 16 18:29:26 2026 GMT
notAfter=Dec 15 18:29:25 2026 GMT

 0 s:CN=333.tego-x.com
   i:C=US, O=Let's Encrypt, CN=YR2
 1 s:C=US, O=Let's Encrypt, CN=YR2
   i:C=US, O=ISRG, CN=Root YR
 2 s:C=US, O=ISRG, CN=Root YR
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
Verify return code: 0 (ok)

• Let's Encrypt가 발급한 90일짜리 인증서예요. 한국 시간으로 9월 17일 새벽 3시 29분에 시작해 12월 16일 새벽 3시 29분에 만료돼요.
• 두 번째 명령으로 본 도메인 목록에는 333.tego-x.com 하나만 있어요. www 주소를 쓰지 않으니 이걸로 맞아요.
• 중간 인증서(1번)와, 그 위 루트를 다른 루트가 보증하는 교차 서명 인증서(2번)까지 함께 보내고, 검증 결과도 0 (ok)예요.
• http로 들어오면 https 주소로 옮겨 줘요(308 응답).

이 인증서는 홈페이지를 올려 둔 호스팅 서비스가 발급하고 갱신해요. 이 호스팅 서비스는 만료 14~30일 전에 자동 갱신을 시도해요. 그러니 11월 16일 무렵부터 12월 2일 무렵 사이에 새 인증서로 바뀌는 게 정상이고, 12월 2일이 지나도 만료일이 그대로라면 갱신이 막혔는지 봐야 해요. 이렇게 날짜를 정해 두면 언제 다시 확인할지가 분명해져요.

응답에서 하나 더 볼 것이 있어요. 삼삼삼 홈페이지는 strict-transport-security: max-age=63072000, 곧 HSTS를 2년으로 걸어 두었어요. 브라우저가 ‘이 사이트는 https로만 연다’고 기억하게 하는 설정이에요. HSTS가 걸린 사이트에서 인증서 오류가 나면 브라우저는 경고를 넘어 들어가는 길을 주지 않아요. 한 번이라도 https로 들어와 본 손님일수록 만료된 날 들어올 방법이 없다는 뜻이라, HSTS를 쓰는 홈페이지는 갱신 실패를 더더욱 놓치면 안 돼요.

경고 화면별로 먼저 볼 곳

맨 위 그림처럼 경고 화면 제목 아래에 작게 보이는 오류 코드로 원인을 꽤 좁힐 수 있어요. Chrome 기준이에요.

가장 먼저 가릴 것은 모든 방문자에게 뜨는지, 한 사람에게만 뜨는지예요. 한 사람에게만 뜬다면 홈페이지보다 방문자 쪽을 의심해요. Chrome 고객센터가 드는 원인은 기기의 날짜·시간, 카페·공항 Wi-Fi에 로그인하기 전 상태, 백신의 HTTPS 검사 기능, 확장 프로그램, 회사 네트워크의 보안 프록시예요.

브라우저는 괜찮은데 앱·연동에서만 오류가 날 때

인증서는 루트 인증서 → 중간 인증서 → 우리 인증서로 이어져야 믿을 수 있어요. 루트는 기기에 미리 들어 있고, 서버는 우리 인증서와 중간 인증서를 함께 보내야 해요. 서버가 중간 인증서를 빠뜨려도 브라우저는 예전에 받아 둔 인증서로 메워서 오류를 내지 않는 경우가 많아요. 반면 안드로이드 앱, 결제·알림 같은 서버끼리의 연동, curl 같은 도구는 그대로 오류를 내요. 브라우저로만 확인하면 놓치기 쉬워서 위의 세 번째 명령이 필요해요.

갱신했는데 경고가 그대로일 때

새 인증서를 받는 것과 서버가 그 인증서를 쓰는 것은 별개예요. 서버를 직접 운영한다면 새 파일로 바꾼 뒤 웹 서버가 다시 읽게(reload 또는 재시작) 해야 하고, 인증서를 올려 둔 곳이 여러 군데라면(서버 여러 대, CDN, 로드밸런서) 전부 바꿔야 해요. 옛 인증서가 남은 한 곳 때문에 일부 방문자에게만 경고가 뜨기도 해요.

경고 없이 지도·문의 폼만 비어 보일 때

https 페이지 안에 http 주소로 불러오는 자원이 섞인 경우(혼합 콘텐츠)예요. 브라우저는 이미지·음성·영상은 https로 바꿔 불러오고, 스크립트·스타일·글꼴·iframe 같은 나머지는 막아요. srcset이나 picture로 넣은 이미지도 막혀요. 그래서 경고 화면 없이 지도나 문의 폼처럼 iframe으로 넣은 부분이 비거나, 글꼴이 바뀌거나, https를 지원하지 않는 주소의 이미지가 빠져 보여요. 개발자 도구 콘솔의 Mixed Content 경고에 원인이 된 주소가 나와요.

관리 방식별로 챙길 것

호스팅·제작 도구가 인증서를 맡을 때

삼삼삼 홈페이지처럼 호스팅 쪽에서 발급과 갱신을 맡는 경우예요. 손댈 일은 적지만 남는 일이 있어요.

• 도메인 연결을 함부로 바꾸지 않아요. 갱신할 때도 도메인 확인을 다시 거치는데, 네임서버를 옮기거나 DNS 레코드를 바꾸면 이 확인이 실패할 수 있어요.
• 도메인에 CAA 레코드(이 도메인에 인증서를 발급해도 되는 인증기관 목록)를 걸었다면, 호스팅이 쓰는 인증기관이 그 목록에 있어야 해요.
• 갱신 실패 알림이 누구에게 가는지 확인해요. 갱신이 실패하면 계정 관리자에게 알림을 보내는 호스팅이 있는데, 그 알림이 퇴사한 사람의 메일로 가고 있다면 알림이 없는 것과 같아요.
• 인증서 갱신과 도메인 이용 기간 연장은 다른 일이에요. 도메인이 만료되면 인증서와 상관없이 홈페이지가 열리지 않아요.

인증서를 사서 직접 설치할 때

• 상품 기간과 별개로 발급일부터 200일(2027년 3월 15일 발급분부터 100일)을 세어 재발급 날짜를 적어 둬요. 재발급 방법은 구매처마다 달라서 구매처 안내를 따라요.
• 인증기관이 주는 중간 인증서 파일까지 함께 설치하고, 세 번째 명령으로 1번이 오는지 봐요.
• 서버가 요구하는 형식(PFX 등)으로 바꾼 뒤, 웹 서버가 새 파일을 다시 읽게 해요.
• 인증서를 올려 둔 곳을 모두 적어 둬요. 서버 여러 대, CDN, 로드밸런서 가운데 한 곳만 빠져도 경고가 남아요.
• 도메인 확인 결과를 다시 쓸 수 있는 기간도 줄고 있어서, 재발급할 때 도메인 확인(메일, DNS 레코드, 파일)을 다시 해야 할 수 있어요.

무료 인증서를 자동 갱신 프로그램으로 받을 때

• Let's Encrypt는 ARI(ACME Renewal Information)를 쓰라고 권해요. 갱신 프로그램이 ARI를 지원하면 언제 갱신할지를 인증기관의 안내에 맞춰 정해요. 지원하지 않는다면 인증서 수명의 3분의 2쯤 지난 시점에 갱신하도록 맞춰 둬요. ‘60일마다’처럼 고정한 주기는 45일짜리 인증서에는 맞지 않아요.
• 가장 흔한 확인 방식(HTTP-01)은 80번 포트로만 해요. http 접속을 막겠다고 방화벽에서 80번을 닫으면 갱신이 실패해요.
• 와일드카드 인증서(*.example.com)는 DNS 레코드로 확인하는 DNS-01로만 받을 수 있어요. 이때는 서버에 DNS 관리 API 키를 두게 되니, 그 키로 할 수 있는 일을 좁혀 둬요.
• Let's Encrypt는 손으로 갱신하는 방식을 권하지 않아요. 갱신이 예정대로 안 됐을 때 알려 주는 모니터링도 따로 걸어 두라고 해요.

갱신한 뒤 확인 순서

1. 첫 번째 명령으로 만료일이 새 날짜로 바뀌었는지 봐요.
2. 두 번째 명령으로 쓰는 주소(www 포함)가 모두 도메인 목록에 있는지 봐요.
3. 세 번째 명령으로 중간 인증서(1번)가 오는지, 검증 결과가 0 (ok)인지 봐요. 서버가 여러 대면 한 대씩 확인해요.
4. http로 들어와도 https로 옮겨 가는지, PC와 휴대폰, 휴대폰 데이터 같은 다른 네트워크에서도 경고가 없는지 봐요.
5. 다음 만료일과 갱신 담당자를 적고, 만료 알림을 걸어 둬요.

HTTPS가 지켜 주는 범위

HTTPS는 브라우저와 서버 사이를 오가는 내용에 세 가지를 해 줘요. 접속한 곳이 주소에 적힌 그 서버인지 확인하고 (인증), 중간에서 읽지 못하게 하고(암호화), 오가는 동안 바뀌지 않았는지 확인해요(무결성). 인증서는 이 가운데 인증을 맡아요.

지켜 주는 곳은 전송 구간까지예요. 서버에 저장된 문의 내용, 관리자 계정, 홈페이지 프로그램의 보안 업데이트는 따로 관리해야 해요. 자물쇠 표시가 있다고 홈페이지 전체가 안전하다는 뜻은 아니에요.

삼삼삼에서 할 수 있는 것

삼삼삼 홈페이지 유지보수 플랜에는 SSL과 도메인 상태를 기본으로 점검하는 일이 들어 있어요. 사이트가 열리지 않거나 깨질 때 확인하고 조치하는 접속·오류 점검도 같은 플랜에 있어요. 인증서를 새로 사거나 서버를 옮기는 것처럼 별도 작업이 필요하면 범위와 비용을 먼저 확인해요(결제·환불 정책).

경고가 떴다면 삼삼삼에 로그인해 상담에 홈페이지 주소와 경고 화면을 오류 코드가 보이게 올려 주세요. 확인해서 필요한 조치와 진행 가능한 범위를 알려 드려요. 홈페이지 유지보수 플랜을 쓰고 있다면 ‘유지보수 요청’ 메뉴의 ‘요청 등록’에서 오류 수정으로 올려도 돼요. 처음 본 시각과, 다른 기기에서도 뜨는지를 함께 적어 주시면 원인을 빨리 좁힐 수 있어요.

인증서 만료일과 중간 인증서는 위의 명령으로 확인하고, 홈페이지 전체 상태가 궁금하다면 무료 진단으로 접속 상태를 포함해 다섯 가지를 한 번에 살펴볼 수 있어요.

참고 자료

• CA/Browser Forum, Baseline Requirements
• Let's Encrypt, 인증서 유효기간 45일 전환 일정
• Chrome 154 릴리스 노트
• Let's Encrypt, 만료 안내 메일 종료
• MDN, Strict-Transport-Security