도메인을 연결하고 설레는 마음으로 사이트에 접속했는데, 주소창에 자물쇠 대신 ‘주의 요함’ 표시가 뜨면 운영자로서 참 당황스럽습니다. 저 역시 처음 SSL 인증서를 적용할 때 단순히 인증서 파일만 복사하면 끝인 줄 알았다가, 매번 자동 갱신 실패로 곤욕을 치르거나 리디렉션 루프에 빠져 고생했던 기억이 있습니다. 단순히 ‘자물쇠’를 다는 것이 아니라, 방문자에게 신뢰를 주고 검색 엔진에 최적화된 환경을 구축하는 것은 운영자의 첫 번째 과제입니다. 이 글에서는 FreeBSD 서버 환경에서 Let’s Encrypt를 통해 인증서를 발급받고, Nginx와 Apache에 이를 안정적으로 정착시키는 전체 과정을 제 경험을 담아 정리합니다.
1. SSL 설치 전 반드시 확인해야 할 사전 조건
인증서 발급이 실패하는 가장 흔한 이유는 명령어가 아니라 사전 준비 부족입니다. 특히 DNS가 완전히 반영되지 않은 상태에서 진행하면 처음부터 막히기 쉽습니다.
먼저 도메인이 서버 IP를 정확히 가리키는지 확인해야 합니다. A 레코드 또는 CNAME 설정이 잘못되어 있으면 Let’s Encrypt가 도메인 검증을 통과하지 못합니다. 또한 80번과 443번 포트가 외부에서 접근 가능한 상태여야 합니다.
Cloudflare 같은 CDN을 사용하는 경우 프록시 상태 때문에 검증이 실패하는 경우도 있습니다. 이때는 잠시 DNS only 상태로 바꿔 확인하는 방식이 더 빠를 수 있습니다.
생각보다 많은 분이 “사이트는 열리니까 괜찮다”라고 판단하지만, www와 non-www가 서로 다르게 연결된 경우 여기서 바로 문제가 발생합니다.
놓치기 쉬운 포인트
SSL 발급 전에는 반드시 example.com과 www.example.com 이 모두 어디로 연결되는지 먼저 확인해야 합니다.
2. Let’s Encrypt Certbot 설치 및 인증서 발급
FreeBSD에서는 pkg를 통해 Certbot을 설치하는 방식이 가장 일반적입니다. 여기서 중요한 것은 발급 자체보다 어떤 방식으로 인증할 것인가입니다.
웹루트 방식과 standalone 방식이 대표적입니다. 이미 nginx나 Apache가 운영 중이라면 webroot 방식이 관리하기 편하고, 아직 웹서버 설정 전이라면 standalone 방식이 간단할 수 있습니다.
예를 들어 블로그 운영 중이라면 서비스 중단 없이 발급 가능한 webroot 방식이 더 현실적입니다. 반대로 초기 구축 단계라면 standalone이 빠르게 끝나는 경우도 있습니다.
또한 fullchain.pem과 privkey.pem의 역할을 혼동하는 경우가 많습니다. fullchain은 인증서 체인 전체, privkey는 개인키 파일입니다. 둘 중 하나라도 잘못 연결되면 브라우저 경고가 발생합니다.
인증서 발급보다 실제 적용 단계에서 더 자주 막히는 이유가 바로 이 파일 구분입니다.
여기서 갈리는 핵심
인증서가 발급되었다고 끝이 아닙니다. 어떤 파일을 웹서버 설정에 연결하는지가 더 중요합니다.
3. nginx SSL 적용 방법
nginx에서는 server 블록 안에서 인증서 경로를 정확히 지정해야 합니다. 이 단계에서 경로 오타 하나로 재시작이 실패하는 경우가 많습니다.
ssl_certificate에는 fullchain.pem, ssl_certificate_key에는 privkey.pem을 연결합니다. 그리고 listen 443 ssl; 설정과 함께 server_name도 정확히 맞춰야 합니다.
HTTP 접속을 HTTPS로 자동 전환하려면 80 포트용 server 블록에서 301 리디렉션을 추가합니다. 이 부분이 빠지면 SSL은 적용됐지만 검색엔진이 중복 URL로 인식할 수 있습니다.
특히 www와 non-www 중 하나를 기준으로 정하지 않으면 SEO 측면에서 불필요한 분산이 생깁니다. SSL 설정은 보안만의 문제가 아니라 URL 구조 정리이기도 합니다.
헷갈리기 쉬운 부분
HTTPS 적용 후에도 http 주소가 그대로 열리면 설정이 끝난 것이 아닙니다. 반드시 리디렉션까지 확인해야 합니다.
4. Apache SSL 적용 방법
Apache는 모듈 활성화 여부부터 확인해야 합니다. 인증서 파일은 있는데 SSL이 동작하지 않는 경우 대부분 여기서 막힙니다.
mod_ssl이 활성화되어 있어야 하며, VirtualHost *:443 설정 안에 SSLCertificateFile과 SSLCertificateKeyFile을 지정합니다. 필요에 따라 SSLCertificateChainFile 구성이 필요한 환경도 있습니다.
특히 기존 VirtualHost 설정이 복잡한 경우 80 포트와 443 포트 구성이 서로 충돌할 수 있습니다. 접속은 되는데 리디렉션이 반복되는 현상도 여기서 자주 발생합니다.
Apache는 오래 운영된 서버일수록 과거 설정이 남아 있는 경우가 많습니다. 새 설정보다 예전 설정이 우선 적용되는 상황이 생각보다 흔합니다.
놓치기 쉬운 포인트
설정 파일 수정 후에는 문법 검사와 재시작을 반드시 함께 해야 합니다. 저장만으로는 적용되지 않습니다.
5. 자동 갱신 설정과 만료 방지 방법
실제로 가장 큰 문제는 발급이 아니라 만료입니다. 사이트를 오래 운영할수록 이 부분이 더 중요해집니다.
Let’s Encrypt 인증서는 유효기간이 짧기 때문에 자동 갱신이 사실상 필수입니다. cron에 certbot renew를 등록하고, 갱신 후 nginx 또는 Apache reload까지 함께 처리하는 구성이 안정적입니다.
특히 갱신은 성공했는데 웹서버가 이전 인증서를 계속 사용하는 경우가 있습니다. 이때는 reload가 빠졌는지 먼저 확인해야 합니다.
운영 초반에는 잘 보이지만 몇 달 뒤 잊어버리기 쉬운 부분이 바로 여기입니다. 승인 이후 방문자가 늘어난 뒤 인증서 만료를 발견하는 경우가 실제로 많습니다.
여기서 갈리는 핵심
자동 갱신은 등록보다 테스트가 중요합니다. 실제로 renew가 동작하는지 한 번 직접 확인해야 합니다.
6. 실제 운영자가 자주 놓치는 주의사항
SSL 설정은 “됐다”와 “안 됐다”가 명확해 보여도, 실제 운영에서는 중간 상태가 자주 발생합니다. 브라우저에서는 정상인데 외부 검사에서는 경고가 뜨는 식입니다.
혼합 콘텐츠(mixed content) 문제도 대표적입니다. 사이트는 HTTPS인데 이미지나 스크립트가 HTTP로 불러와지면 자물쇠 표시가 깨집니다. 특히 오래된 테마나 플러그인에서 자주 발생합니다.
또한 인증서 재발급을 반복하다 보면 오래된 설정 파일이 남아 충돌하는 경우도 있습니다. 단순히 “새 인증서를 넣었다”가 아니라 어떤 파일을 실제로 참조하는지 확인해야 합니다.
겉으로는 SSL 문제처럼 보여도 실제로는 CDN 캐시나 브라우저 캐시 때문인 경우도 있습니다. 그래서 테스트는 반드시 시크릿 모드나 외부 SSL 검사 도구로 확인하는 편이 안전합니다.
헷갈리기 쉬운 부분
브라우저에 자물쇠가 보여도 끝이 아닙니다. 리디렉션, mixed content, 자동 갱신까지 확인해야 진짜 안정적인 운영이 가능합니다.
FAQ
Q1. 무료 SSL 인증서도 애드센스 승인에 문제없나요?
일반적으로 Let’s Encrypt 같은 무료 SSL 인증서도 충분히 사용됩니다. 중요한 것은 유료 여부보다 HTTPS가 정상적으로 적용되고 안정적으로 유지되는지입니다.
Q2. www와 non-www 중 무엇을 써야 하나요?
둘 중 무엇이 더 좋다고 단정하기보다는 하나로 통일하는 것이 중요합니다. 검색엔진은 일관성을 더 중요하게 봅니다.
Q3. 인증서 발급은 됐는데 브라우저 경고가 뜹니다.
대부분 fullchain.pem 연결 오류, mixed content, 또는 오래된 캐시 때문입니다. 인증서 자체보다 실제 적용 상태를 먼저 확인해야 합니다.
Q4. Cloudflare를 쓰면 서버에 SSL 설치가 필요 없나요?
상황에 따라 다릅니다. Full 또는 Full (strict) 모드를 사용하려면 원본 서버에도 SSL 구성이 필요합니다. 프록시만으로 완전히 끝나는 것은 아닙니다.
Q5. 자동 갱신이 설정됐는지 어떻게 확인하나요?
certbot renew –dry-run 같은 테스트 방식으로 확인할 수 있습니다. 등록만 보고 안심하기보다 실제 동작 여부를 점검하는 것이 더 중요합니다.
마무리
SSL 인증서 설치는 발급 그 자체보다, 만료되지 않고 돌아가는 ‘자동 갱신 환경’을 만드는 것이 핵심입니다. 3개월마다 수동으로 갱신하다 보면 반드시 한 번은 놓치게 되고, 그때마다 사이트 방문자들은 불안감을 느끼게 됩니다. SEO와 애드센스 승인처럼 신뢰도가 중요한 환경에서 HTTPS는 옵션이 아니라 기본 전제입니다. 지금 번거롭더라도 certbot 등을 활용해 완벽히 자동화된 구조를 세워두시면, 앞으로 몇 년간 SSL 문제로 서버를 다시 건드리는 일은 없을 것입니다. 기술적 안정성은 이런 사소한 자동화의 디테일에서 완성된다는 점을 잊지 마세요.
면책 문구
SSL 인증서 설정 방법은 FreeBSD 버전, 사용 중인 웹서버 환경, DNS 구성, CDN 사용 여부에 따라 달라질 수 있습니다. 실제 적용 전에는 공식 문서와 현재 서버 설정을 함께 확인하고, 운영 중인 서비스라면 백업 후 단계적으로 적용하시기 바랍니다.