브라우저에 “이 사이트는 안전하지 않습니다” 경고가 뜨면 방문자는 대부분 그 자리에서 나갑니다. 결제나 로그인이 있는 사이트라면 매출로 직결되는 문제죠. 그런데 이 경고의 원인은 의외로 몇 가지로 좁혀집니다.
첫째, 만료됐습니다
가장 흔한 원인입니다. 인증서에는 유효 기간이 있고, 이 기간은 계속 짧아지는 추세예요. 예전에는 몇 년씩 발급받을 수 있었지만 지금은 훨씬 자주 갱신해야 합니다. 무료 인증서는 보통 90일이라 자동 갱신이 사실상 필수고요.
문제는 자동 갱신을 걸어뒀다고 안심하는 경우입니다. 갱신 스크립트가 조용히 실패해도 아무도 모르다가 만료 당일에 사고가 터져요. 그래서 갱신 자체보다 갱신 실패 알림이 더 중요합니다. 만료 2주 전에 알림이 오도록 걸어두면 여유를 갖고 대응할 수 있습니다.
둘째, 중간 인증서가 빠졌습니다
이건 진단이 까다로운 유형이에요. PC 브라우저에서는 멀쩡한데 휴대폰이나 특정 앱에서만 오류가 나는 증상이 대표적입니다. 원인은 인증서 체인입니다.
인증서는 최상위 기관에서 중간 기관을 거쳐 내 도메인 인증서로 이어지는 사슬 구조예요. 서버에 내 인증서만 올리고 중간 인증서를 빠뜨리면, 이미 그 중간 인증서를 갖고 있는 브라우저는 문제없이 넘어가지만 그렇지 않은 환경에서는 신뢰 사슬이 끊겨 오류가 납니다. 발급받을 때 함께 오는 체인 파일을 반드시 같이 설치해야 합니다.
셋째, 도메인이 안 맞습니다
인증서는 발급받은 도메인에서만 유효합니다. example.com으로 받았는데 www.example.com으로 접속하면 이름이 다르다는 오류가 떠요. 두 주소를 모두 쓴다면 발급 시 둘 다 포함시키거나, 하위 도메인 전체를 덮는 와일드카드 인증서를 쓰면 됩니다.
서브도메인을 새로 만들 때도 자주 걸립니다. 기존 인증서에 그 이름이 포함돼 있지 않으니 새로 발급받거나 기존 것에 추가해야 해요.
유효 기간 단축에는 정해진 일정이 있어요
인증서를 자주 바꾸는 흐름은 무료 서비스만의 이야기가 아니에요. 인증기관과 브라우저 업체가 참여하는 CA/Browser Forum은 2025년 4월, 공개적으로 신뢰받는 TLS 서버 인증서의 최대 유효 기간을 단계적으로 줄이는 안건을 통과시켰습니다. 사이트에서 흔히 SSL 인증서라고 부르는 인증서의 발급 기준이 바뀌는 거죠. 이 일정은 인터넷용 공개 인증서를 대상으로 하므로, 회사 내부에서 자체적으로 운영하는 사설 인증서까지 똑같이 적용된다고 생각하면 안 됩니다. 먼저 내가 쓰는 인증서가 어떤 발급 체계에 속하는지 구분해두세요.
2026년 8월 기준으로, 2026년 3월 15일부터 새로 발급하는 인증서의 최대 유효 기간은 200일이에요. 그전의 상한은 398일이었고요. 앞으로는 2027년 3월 15일부터 100일, 2029년 3월 15일부터 47일로 줄어들 예정입니다. 여기서 날짜를 가르는 기준은 사이트 개설일이나 상품 결제일이 아니라 인증서 발급일이에요. 또 이 숫자는 허용되는 최댓값이라 발급기관이 더 짧게 발급할 수도 있습니다. 호스팅 상품의 계약 기간과 인증서 한 장의 유효 기간을 따로 확인해야 하는 이유예요.
함께 바뀌는 항목은 도메인 확인 결과의 재사용 기간입니다. 인증기관이 예전에 확인한 ‘이 도메인을 관리할 권한이 있다’는 결과를 언제까지 다시 쓸 수 있는지 정한 기준이에요. 이 상한도 2026년 3월 15일부터 200일, 2027년 3월 15일부터 100일로 줄고, 2029년 3월 15일부터는 10일이 됩니다. 인증서가 47일간 유효하다는 것과 확인 결과를 10일간 재사용할 수 있다는 것은 서로 다른 이야기죠. 앞으로의 운영 계획에는 인증서 교체뿐 아니라 도메인 권한을 다시 증명하는 절차도 포함해두는 게 좋습니다.
발급을 막는 설정도 따로 점검하세요
자동 발급 도구가 실패했다면 인증서를 받기 전에 거치는 ‘도메인 검증’부터 확인해보세요. Let’s Encrypt는 ACME라는 표준에 따라 도메인 관리 권한을 검증합니다. 대표적인 HTTP-01 방식은 서버에 임시 확인 파일을 놓고 인증기관이 외부에서 그 파일을 읽는 구조예요. 이 검증은 80번 포트로만 진행됩니다. 사이트가 443번 포트의 HTTPS로 잘 열린다고 해서 발급 검증도 통과하는 것은 아니에요. 방화벽에서 80번 포트를 막았는지, 확인 파일을 외부에서 읽을 수 있는지 먼저 점검할 수 있습니다.
서버가 여러 대라면 어느 서버로 요청이 들어가도 확인 파일을 읽을 수 있어야 해요. Let’s Encrypt는 HTTP-01 검증에서 여러 위치로부터 파일을 가져올 수 있다고 안내합니다. 한 서버에만 파일을 두는 설정이라면 다른 서버가 요청을 받았을 때 검증을 마치지 못할 수 있는 거죠. HTTP에서 HTTPS로 보내는 리다이렉트 자체는 지원하지만, 이동 대상은 HTTP 또는 HTTPS여야 하고 포트도 80이나 443으로 제한됩니다. 발급 실패를 조사할 때는 웹서버 수와 요청이 이동하는 경로까지 함께 적어두면 원인을 좁히기 쉬워요.
와일드카드 인증서를 Let’s Encrypt로 받으려면 HTTP-01이 아닌 DNS-01 검증을 써야 합니다. 도메인의 DNS에 지정된 TXT 레코드를 넣고 인증기관이 그 값을 조회하는 방식이에요. 자동으로 처리하려면 DNS 업체가 레코드를 수정할 API를 제공하는지도 확인해야 하고요. 서버의 웹페이지 설정만 고쳐서는 이 검증을 해결할 수 없습니다. 또한 Let’s Encrypt는 웹서버에 DNS 전체 관리 권한을 두면 서버 침해 시 피해가 커질 수 있다고 경고해요. 자동화에 쓰는 API 자격 증명은 필요한 범위로 권한을 제한하거나, 별도 서버에서 검증하도록 구성하는 방법을 권장합니다.
인증서만 깔면 끝이 아닙니다
https로 접속은 되는데 자물쇠가 안 뜨는 경우가 있습니다. 페이지 안에서 이미지나 스크립트를 http로 불러오고 있어서 그래요. 브라우저는 이걸 안전하지 않은 혼합 콘텐츠로 보고 경고를 띄웁니다. 이럴 땐 페이지 소스에서 http로 시작하는 주소를 찾아 바꿔야 합니다.
그리고 http 접속을 https로 넘겨주는 설정도 함께 해두세요. 인증서를 깔아도 http로 들어오는 경로가 열려 있으면 그쪽으로 접속한 사람은 여전히 암호화 없이 통신하게 됩니다.
인증서 종류는 대부분의 사이트에서 도메인 확인만 하는 기본형으로 충분합니다. 기업 실체 확인이 들어가는 상위 등급은 금융처럼 신뢰 표시가 중요한 경우에 고려하면 돼요. 암호화 강도 자체는 등급과 무관하게 같습니다.
TIDC는 모든 요금제에 무료 SSL 인증서를 기본 제공하고 갱신까지 관리해드립니다. 인증서 오류로 시간을 쓰고 계시다면 편하게 문의해주세요.
