SSL 인증서는 남았는데 HTTPS가 안 되는 이유

Table of Contents

SSL 인증서는 있는데 왜 HTTPS가 적용이 안 될까요

웹사이트를 운영하는 분들이라면 ‘SSL 인증서’와 ‘HTTPS’라는 용어를 한 번쯤 들어보셨을 겁니다. 특히 요즘에는 검색 엔진 최적화(SEO)와 사용자 보안을 위해 HTTPS 적용이 필수적인 요소로 자리 잡았습니다. 그런데 간혹 SSL 인증서를 구매하고 설치했는데도 웹사이트 주소가 여전히 ‘http://’로 시작하거나 브라우저에 ‘안전하지 않음’이라는 경고가 뜨는 경우가 있습니다. 이 글에서는 이런 문제가 발생하는 이유와 해결 방법에 대해 자세히 알아보겠습니다.

SSL과 HTTPS의 기본 개념 이해하기

본격적인 문제 해결에 앞서 SSL과 HTTPS가 무엇인지 정확히 이해하는 것이 중요합니다.

  • SSL/TLS: Secure Sockets Layer 또는 Transport Layer Security의 약자입니다. 웹 서버와 사용자 브라우저 사이에 주고받는 데이터를 암호화하여 보안 연결을 설정하는 기술 표준입니다. 웹사이트의 신원을 확인하고 데이터의 무결성을 보장합니다.
  • SSL 인증서: 웹사이트의 신원을 증명하고 SSL/TLS 암호화를 가능하게 하는 디지털 파일입니다. 이 인증서에는 웹사이트의 공개 키, 도메인 정보, 발급 기관 정보 등이 포함되어 있습니다.
  • HTTPS: Hypertext Transfer Protocol Secure의 약자입니다. 일반적인 HTTP 프로토콜에 SSL/TLS 보안 계층이 추가된 것입니다. 즉, SSL/TLS를 통해 암호화된 통신을 하는 HTTP를 의미합니다. 브라우저 주소창에 자물쇠 모양과 함께 ‘https://’로 표시됩니다.

간단히 말해, SSL 인증서는 보안 통신을 위한 ‘신분증’ 같은 것이고, HTTPS는 이 신분증을 활용하여 ‘안전하게 대화하는 방법’이라고 할 수 있습니다. SSL 인증서가 있다고 해서 자동으로 HTTPS가 되는 것이 아니라, 이 인증서를 웹 서버에 올바르게 설치하고 설정해야 비로소 HTTPS가 작동하는 것입니다.

SSL 인증서는 있는데 HTTPS가 안 되는 흔한 이유

SSL 인증서를 구매하고 설치했는데도 HTTPS가 적용되지 않는 데에는 여러 가지 복합적인 원인이 있을 수 있습니다. 다음은 가장 흔한 문제점들입니다.

인증서 설치 또는 설정 오류

가장 기본적인 원인입니다. SSL 인증서 파일이 웹 서버에 제대로 설치되지 않았거나, 서버 설정 파일에서 인증서 경로를 잘못 지정했을 수 있습니다.

  • 인증서 파일 누락 또는 경로 오류: 웹 서버(Apache, Nginx, IIS 등) 설정 파일에 SSL 인증서 파일(.crt), 개인 키 파일(.key), 그리고 체인 파일(.ca-bundle 또는 .crt)의 경로가 정확하게 지정되어 있어야 합니다. 이 중 하나라도 누락되거나 경로가 틀리면 HTTPS 연결이 실패합니다.
  • 중간 인증서 미설치: 대부분의 SSL 인증서는 최종 인증서, 중간 인증서, 루트 인증서의 ‘체인’으로 구성됩니다. 이 중간 인증서(Intermediate Certificate)가 서버에 설치되지 않으면 브라우저가 웹사이트의 신뢰성을 완전히 검증할 수 없어 오류가 발생합니다.
  • 도메인 불일치: SSL 인증서는 특정 도메인(예: example.com 또는 www.example.com)에 대해 발급됩니다. 인증서가 발급된 도메인과 웹사이트에 접속하는 도메인이 다르면 인증서 오류가 발생합니다. 예를 들어, example.com으로 인증서를 받았는데 www.example.com으로 접속하면 문제가 생길 수 있습니다.
  • 인증서 만료: SSL 인증서는 유효 기간이 있습니다. 만료된 인증서를 사용하면 당연히 HTTPS가 작동하지 않습니다. 웹사이트에 접속했을 때 ‘인증서 만료’와 같은 오류 메시지가 뜨는지 확인해보세요.

웹 서버 설정 문제

SSL 인증서가 올바르게 설치되었더라도 웹 서버 자체의 설정이 미흡하면 HTTPS가 작동하지 않습니다.

  • HTTPS 포트 443 미개방: HTTPS는 기본적으로 443번 포트를 사용합니다. 웹 서버가 이 443번 포트에서 HTTPS 요청을 수신하도록 설정되어 있지 않으면 접속이 불가능합니다. 방화벽에서 443번 포트를 차단했을 수도 있습니다.
  • 가상 호스트 또는 서버 블록 설정 오류: Apache의 VirtualHost 또는 Nginx의 server 블록 설정에서 SSL/TLS 관련 지시어(SSLEngine On, ssl_certificate, ssl_certificate_key 등)가 올바르게 적용되지 않았을 수 있습니다.
  • HTTP/2 미설정: HTTP/2는 HTTPS를 통해 제공될 때 성능 이점을 제공합니다. 서버가 HTTP/2를 지원하도록 설정되지 않은 경우, HTTPS는 작동하지만 최적의 성능을 내지 못할 수 있습니다.

HTTP에서 HTTPS로 리디렉션 미설정

사용자가 ‘http://’로 접속했을 때 자동으로 ‘https://’로 전환되도록 설정하는 것을 ‘리디렉션’이라고 합니다. 이 설정이 없으면 사용자는 여전히 HTTP로 접속하게 됩니다.

  • 301 리디렉션 누락: 웹 서버 설정 파일(.htaccess, Apache httpd.conf, Nginx nginx.conf 등)에 HTTP 요청을 HTTPS로 영구적으로 리디렉션하는 설정(301 Permanent Redirect)이 빠져있을 수 있습니다.
  • 리디렉션 루프: 잘못된 리디렉션 설정으로 인해 HTTP에서 HTTPS로, 다시 HTTPS에서 HTTP로 무한히 반복되는 리디렉션 루프가 발생할 수도 있습니다.

혼합 콘텐츠 Mixed Content 문제

이것은 가장 흔하고 발견하기 어려운 문제 중 하나입니다. 웹사이트 자체는 HTTPS로 로드되지만, 페이지 내에서 불러오는 특정 리소스(이미지, 스크립트, CSS 파일, 폰트 등)가 여전히 HTTP 주소를 사용하고 있을 때 발생합니다.

  • 문제 발생 원인: HTML 코드, CSS 파일, JavaScript 파일 또는 데이터베이스에 저장된 콘텐츠 내에서 http://로 시작하는 URL이 포함되어 있을 때 발생합니다.
  • 결과: 브라우저는 안전한 HTTPS 페이지 내에 안전하지 않은 HTTP 콘텐츠가 섞여 있다고 판단하여 주소창에 ‘안전하지 않음’ 경고를 표시하거나, 심한 경우 해당 콘텐츠를 로드하지 않아 페이지 레이아웃이 깨지거나 기능이 작동하지 않을 수 있습니다.

방화벽 또는 CDN 설정 문제

서버 자체의 문제 외에 외부적인 요인도 있을 수 있습니다.

  • 서버 방화벽: 웹 서버나 네트워크 장비의 방화벽이 443번 포트를 차단하고 있을 수 있습니다.
  • CDN (콘텐츠 전송 네트워크): Cloudflare와 같은 CDN 서비스를 사용하고 있다면, CDN과 원본 서버 간의 SSL/TLS 설정이 올바르게 되어 있는지 확인해야 합니다. CDN의 SSL/TLS 모드(예: Flexible, Full, Full Strict)에 따라 문제가 발생할 수 있습니다.

실생활에서의 활용 방법과 유용한 팁

이제 문제를 해결하기 위한 구체적인 방법과 유용한 팁을 알아보겠습니다.

문제 진단 도구 활용하기

문제를 해결하기 전에 정확한 원인을 파악하는 것이 중요합니다. 다음 도구들을 활용해보세요.

  • SSL Checker 도구: SSL Labs SSL Server Test와 같은 도구는 웹사이트의 SSL/TLS 설정 상태를 심층적으로 분석하여 인증서 체인 문제, 프로토콜 지원, 취약점 등을 상세하게 알려줍니다.
  • 브라우저 개발자 도구: 웹사이트에 접속한 후 F12 키를 눌러 개발자 도구를 엽니다. ‘Console’ 탭에서 혼합 콘텐츠(Mixed Content) 경고나 다른 보안 관련 오류 메시지를 확인할 수 있습니다. ‘Network’ 탭에서는 각 리소스가 HTTP로 로드되는지 HTTPS로 로드되는지 확인할 수 있습니다.

SSL 인증서 설치 및 서버 설정 확인

  • 인증서 파일 확인: 웹 호스팅 업체나 SSL 발급 기관에서 제공하는 가이드에 따라 인증서 파일(.crt), 개인 키(.key), 중간 인증서(.ca-bundle)가 서버의 올바른 위치에 있는지 확인합니다.
  • 웹 서버 설정 파일 수정:
    • Apache: httpd.conf 또는 ssl.conf 파일에서 <VirtualHost :443> 블록 내에 SSLEngine On, SSLCertificateFile, SSLCertificateKeyFile, SSLCertificateChainFile(또는 SSLCACertificateFile) 지시어가 올바르게 설정되어 있는지 확인합니다.
    • Nginx: nginx.conf 파일 내의 해당 server 블록에서 listen 443 ssl;, ssl_certificate, ssl_certificate_key, ssl_trusted_certificate(또는 ssl_client_certificate) 지시어가 올바르게 설정되어 있는지 확인합니다.
    • IIS: IIS 관리자에서 웹사이트를 선택하고 ‘바인딩’을 편집하여 443번 포트에 SSL 인증서가 올바르게 연결되어 있는지 확인합니다.
  • 서버 재시작: 설정 파일을 수정한 후에는 반드시 웹 서버를 재시작해야 변경 사항이 적용됩니다. (예: Apache의 경우 sudo systemctl restart apache2 또는 sudo service httpd restart, Nginx의 경우 sudo systemctl restart nginx)

HTTP에서 HTTPS로 리디렉션 설정

모든 HTTP 요청을 HTTPS로 자동 전환하도록 설정해야 합니다.

  • Apache (.htaccess 파일):
    RewriteEngine On
    
    RewriteCond %{HTTPS} off
    
    RewriteRule ^(.)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
  • Nginx (nginx.conf 파일):
    server {
    
        listen 80;
    
        server_name your_domain.com www.your_domain.com;
    
        return 301 https://$host$request_uri;
    
    }
  • CMS (WordPress 등): 워드프레스의 경우 ‘설정 > 일반’에서 ‘WordPress 주소(URL)’와 ‘사이트 주소(URL)’를 https://로 변경하고, Really Simple SSL과 같은 플러그인을 사용하여 쉽게 리디렉션 및 혼합 콘텐츠 문제를 해결할 수 있습니다.

혼합 콘텐츠 문제 해결

혼합 콘텐츠는 수동으로 찾아서 고치거나, 자동화 도구를 사용할 수 있습니다.

  • 수동 해결: 브라우저 개발자 도구의 콘솔 탭에서 혼합 콘텐츠 오류를 확인하고, 해당 리소스의 URL을 http://에서 https://로 변경합니다. 또는 프로토콜에 의존하지 않도록 //example.com/image.jpg와 같이 상대 경로를 사용하는 것이 좋습니다. 데이터베이스에 저장된 URL은 SQL 쿼리를 통해 일괄 변경할 수 있습니다.
  • 플러그인/도구 활용: 워드프레스의 Really Simple SSL 플러그인처럼 자동으로 혼합 콘텐츠를 수정해주는 도구를 활용하면 편리합니다.
  • HSTS (HTTP Strict Transport Security): HSTS는 브라우저에게 해당 웹사이트는 항상 HTTPS로만 접속해야 한다고 알려주는 보안 메커니즘입니다. 한 번 HSTS 헤더를 받으면 브라우저는 일정 기간 동안 해당 웹사이트에 HTTP로 접속하려는 시도를 모두 HTTPS로 자동 전환합니다. 이는 보안을 강화하고 리디렉션 오버헤드를 줄이는 데 도움이 됩니다. 웹 서버 설정 파일에 Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"와 같은 헤더를 추가하여 활성화할 수 있습니다.

SSL 인증서 종류별 특성 설명

SSL 인증서의 종류는 HTTPS 작동 여부와 직접적인 관련은 없지만, 웹사이트의 신뢰도와 사용 목적에 따라 선택이 달라질 수 있습니다.

  • DV (Domain Validated): 도메인 소유권만 확인하는 가장 기본적인 인증서입니다. 발급이 빠르고 저렴하며, Let’s Encrypt처럼 무료로 제공되는 경우도 많습니다. 개인 블로그나 소규모 웹사이트에 적합합니다.
  • OV (Organization Validated): 도메인 소유권과 함께 기업/조직의 실제 존재 여부를 확인합니다. DV보다 신뢰도가 높으며, 기업 웹사이트나 내부 시스템에 주로 사용됩니다.
  • EV (Extended Validation): 가장 엄격한 심사를 거쳐 발급되는 인증서입니다. 브라우저 주소창에 회사명이 초록색으로 표시되어 사용자에게 높은 신뢰감을 줍니다. 주로 금융 기관이나 대기업 웹사이트에서 사용됩니다.
  • 와일드카드 (Wildcard): 단일 도메인의 모든 서브도메인(예: blog.example.com, shop.example.com)에 대해 하나의 인증서로 HTTPS를 적용할 수 있습니다. 여러 서브도메인을 운영하는 경우 비용 효율적입니다.
  • SAN/멀티 도메인 (Subject Alternative Name/Multi-Domain): 여러 개의 서로 다른 도메인(예: example.com, anotherexample.com, thirdexample.net)을 하나의 인증서로 보호할 수 있습니다.

어떤 종류의 인증서를 사용하든, 중요한 것은 올바른 설치와 설정입니다.

흔한 오해와 사실 관계

  • 오해: SSL 인증서만 구매하면 자동으로 HTTPS가 적용된다.
    • 사실: SSL 인증서는 HTTPS를 위한 필수 요소일 뿐, 웹 서버에 정확하게 설치하고, 서버 설정을 변경하며, HTTP에서 HTTPS로의 리디렉션을 설정해야 비로소 HTTPS가 작동합니다.
  • 오해: HTTPS는 온라인 쇼핑몰처럼 결제 정보가 오가는 사이트에만 필요하다.
    • 사실: 사용자 이름, 비밀번호, 개인 정보 등 어떤 형태의 데이터라도 교환되는 모든 웹사이트에는 HTTPS가 필수적입니다. 데이터 탈취 위험을 줄이고, 사용자의 신뢰를 얻으며, 검색 엔진 최적화(SEO)에도 긍정적인 영향을 미칩니다.
  • 오해: 무료 SSL 인증서는 보안성이 떨어진다.
    • 사실: Let’s Encrypt와 같은 무료 SSL 인증서는 유료 인증서와 동일한 수준의 암호화 강도를 제공합니다. 다만, 발급 과정이 자동화되어 있어 조직 검증(OV, EV)과 같은 추가적인 신원 확인 절차가 없으며, 기술 지원이나 보증 범위에서 차이가 있을 수 있습니다. 대부분의 개인 및 중소기업 웹사이트에는 무료 SSL로도 충분합니다.

전문가의 조언

웹사이트 보안은 한 번 설정했다고 끝나는 것이 아닙니다. 지속적인 관리와 관심이 필요합니다.

  • 정기적인 점검: SSL 인증서 만료일을 달력에 표시하거나 알림 서비스를 활용하여 미리 갱신하세요. SSL Labs와 같은 도구를 사용하여 주기적으로 웹사이트의 SSL/TLS 상태를 점검하는 것이 좋습니다.
  • 백업의 중요성: 웹 서버 설정 파일을 수정하기 전에는 반드시 원본 파일을 백업해두세요. 문제가 발생했을 때 빠르게 복구할 수 있습니다.
  • 호스팅 업체 또는 전문가에게 문의: 만약 위의 방법들을 시도해도 문제가 해결되지 않거나, 서버 설정에 대한 지식이 부족하다면, 웹 호스팅 업체 기술 지원팀이나 전문 웹 개발자에게 도움을 요청하는 것이 가장 현명한 방법입니다.

자주 묻는 질문

Q1: SSL 인증서를 설치했는데도 브라우저에 ‘안전하지 않음’이라고 표시됩니다. 왜 그런가요?

A1: 가장 흔한 원인은 ‘혼합 콘텐츠’ 문제입니다. 웹사이트가 HTTPS로 로드되지만, 페이지 내의 이미지, 스크립트, CSS 등 일부 리소스가 여전히 HTTP로 로드되고 있을 때 발생합니다. 브라우저 개발자 도구(F12)의 ‘Console’ 탭을 확인하여 혼합 콘텐츠 오류를 찾아 해결해야 합니다. 또한, SSL 인증서 자체의 문제(만료, 도메인 불일치, 중간 인증서 누락)일 수도 있으니 SSL Checker 도구로 확인해보세요.

Q2: 무료 SSL 인증서(Let’s Encrypt)를 사용해도 충분한가요?

A2: 네, 대부분의 개인 블로그, 포트폴리오 사이트, 소규모 비즈니스 웹사이트에서는 Let’s Encrypt와 같은 무료 SSL 인증서로 충분합니다. 무료 인증서는 유료 인증서와 동일한 수준의 암호화 강도를 제공하여 데이터 보안을 보장합니다. 다만, 조직 검증이나 확장 검증이 필요하거나, 전문적인 기술 지원 및 보증을 원한다면 유료 인증서를 고려할 수 있습니다.

Q3: HTTPS를 적용하면 웹사이트 속도가 느려지나요?

A3: 과거에는 SSL/TLS 암호화 및 복호화 과정 때문에 약간의 성능 저하가 발생할 수 있다고 여겨졌습니다. 하지만 현대의 웹 서버와 브라우저는 이러한 오버헤드를 최소화하도록 최적화되어 있으며, HTTP/2와 같은 최신 프로토콜은 오히려 HTTPS 환경에서 더 나은 성능을 제공합니다. 따라서 대부분의 경우 HTTPS 적용으로 인한 속도 저하는 미미하며, 보안 및 SEO 이점이 훨씬 큽니다.

비용 효율적인 활용 방법

SSL 인증서와 HTTPS를 비용 효율적으로 활용하는 방법은 다음과 같습니다.

  • 무료 SSL 인증서 활용: Let’s Encrypt는 무료로 SSL 인증서를 발급해주며, 대부분의 호스팅 서비스에서 쉽게 통합할 수 있습니다. 자동 갱신 기능을 지원하여 관리가 편리합니다.
  • 호스팅 서비스의 기본 SSL 활용: 많은 웹 호스팅 업체는 자체적으로 무료 SSL 인증서를 제공하거나, Let’s Encrypt를 기본으로 통합하여 제공합니다. 호스팅 서비스 가이드를 확인하여 이를 활용하는 것이 가장 간편하고 비용이 들지 않습니다.
  • CDN 서비스 활용: Cloudflare와 같은 CDN 서비스는 무료 플랜에서도 SSL/TLS 기능을 제공합니다. 이를 통해 웹사이트의 보안을 강화하고 성능을 향상시킬 수 있습니다. 단, CDN과 원본 서버 간의 SSL 설정을 ‘Full Strict’로 설정하여 엔드 투 엔드 보안을 확보하는 것이 중요합니다.
  • 필요에 따른 인증서 선택: 웹사이트의 목적과 규모에 따라 적절한 인증서를 선택하세요. 개인 블로그나 정보 제공 사이트라면 DV 인증서로 충분하며, 굳이 비싼 EV 인증서를 구매할 필요는 없습니다. 여러 서브도메인을 운영한다면 와일드카드 인증서가 개별 인증서 구매보다 비용 효율적일 수 있습니다.

이 포스팅이 도움이 되었나요?

별을 클릭하여 평점을 남겨주세요!

평균 평점: 0 / 5. 투표 수: 0

아직 투표가 없습니다. 첫 번째로 이 글을 평가해 보세요!

error: Content is protected !!

광고 차단 알림

광고 클릭 제한을 초과하여 광고가 차단되었습니다.

단시간에 반복적인 광고 클릭은 시스템에 의해 감지되며, IP가 수집되어 사이트 관리자가 확인 가능합니다.