SSL 인증서와 HTTPS에 대한 설명

IPAddress-Lookup.com · June 25, 2025

웹사이트를 방문할 때마다 주소 옆에 작은 자물쇠 아이콘이 보이거나, URL이 http:// 대신 https://로 시작하는 것을 확인한다면, 여러분은 현대 인터넷에서 가장 중요한 기술 중 하나인 SSL/TLS 암호화와 이를 가능하게 하는 디지털 인증서에 의존하고 있는 것입니다. 이러한 인증서는 사용자와 서버 사이의 네트워크를 도청할지도 모르는 누구로부터도 사용자의 비밀번호, 신용카드 번호, 비공개 메시지, 그리고 브라우징 습관을 조용히 보호해 줍니다. 하지만 이처럼 근본적인 요소임에도 불구하고, SSL 인증서와 HTTPS의 작동 원리는 대다수의 사람들에게 여전히 수수께끼로 남아 있습니다. 이 가이드는 그 베일을 걷어내고, SSL/TLS가 정확히 무엇인지, 암호화가 어떻게 작동하는지, 인증서가 실제로 무엇을 증명하는지, 그리고 브라우저가 사이트를 신뢰할지 여부를 어떻게 결정하는지 등을 쉬운 말로 설명합니다.

SSL과 TLS의 실제 정의

SSL은 Secure Sockets Layer의 약자로, 1990년대 중반 넷스케이프(Netscape)가 웹 브라우저와 서버 간의 통신을 보호하기 위해 처음 설계한 프로토콜입니다. 이 프로토콜이 해결한 문제는 설명하기는 간단했지만 해결하기는 어려웠습니다. 초기 웹(HTTP)은 모든 데이터를 평문, 즉 읽을 수 있는 텍스트 형태로 전송했기 때문입니다. 사용자와 웹사이트 사이에 위치한 누구든지 — 악의적인 Wi-Fi 핫스팟, 인터넷 서비스 제공업체, 보안이 침해된 라우터 등 — 오가는 데이터를 읽거나 심지어 변조할 수도 있었습니다. SSL은 해당 트래픽을 암호화 계층으로 감싸, 도청자에게는 무의미한 데이터가 되도록 했습니다.

SSL 자체는 이제 구식이 되었습니다. SSL 2.0과 SSL 3.0에는 심각한 보안 결함이 발견되어 수년 전부터 사용이 중단되었습니다. 오늘날 웹을 실제로 보호하는 프로토콜은 TLS(Transport Layer Security)라고 합니다. TLS는 SSL의 직접적인 후속 버전이며, 사람들이 “SSL 인증서”라고 말할 때 거의 항상 TLS와 함께 사용되는 인증서를 의미합니다. 그 이름이 익숙했기 때문에 그대로 굳어진 것입니다. 그 진화 과정은 다음과 같습니다:

• SSL 1.0 — 보안 결함으로 인해 공개되지 않았습니다.
• SSL 2.0(1995) 및 SSL 3.0(1996) — 현재 모두 사용 중단되었으며 모든 곳에서 비활성화되었습니다.
• TLS 1.0 (1999) — TLS라는 이름으로 출시된 첫 번째 버전이며, 현재 역시 사용이 권장되지 않습니다.
• TLS 1.1 (2006) — 1.0과 함께 단종되었습니다.
• TLS 1.2 (2008) — 여전히 널리 사용되며, 올바르게 구성될 경우 안전한 것으로 간주됩니다.
• TLS 1.3 (2018) — 현재 표준으로, 속도가 더 빠르며 구식 취약한 알고리즘이 제거되었습니다.

TLS 1.3은 대대적인 재설계 과정을 거쳤습니다. 취약점을 유발했던 수십 가지의 구식 암호 옵션을 제거했으며, 연결 설정 과정을 간소화하여 보안 세션이 더 빠르게 수립되도록 했습니다. 최신 브라우저는 양측이 모두 지원하는 가장 높은 버전을 협상하며, 실제로는 TLS 1.2 또는 1.3을 의미합니다.

SSL 인증서의 실제 역할

SSL/TLS 인증서는 두 가지 별개의 역할을 수행하며, 이 두 가지가 서로 분리되어 있다는 점을 이해하는 것이 중요합니다. 첫 번째는 암호화입니다. 즉, 전송 중인 데이터를 읽을 수 없도록 뒤섞는 것입니다. 두 번째는 인증, 즉 신원 확인입니다. 이는 통신 중인 서버가 주소 표시줄에 표시된 도메인에 실제로 속하는 것이며, 연결을 가로챈 사칭자가 아니라는 것을 증명하는 것입니다.

인증 없는 암호화는 위험할 수 있습니다. 공격자가 단순히 트래픽을 중계하면서 모든 내용을 엿보는 상황에서도 완벽하게 암호화된 연결이 성립될 수 있기 때문입니다. 인증서는 검증된 신원에 암호화 키를 연결함으로써 이 문제를 해결합니다. 브라우저가 인증서를 수락하면, 연결이 비공개로 유지될 뿐만 아니라 상대방이 주장하는 바로 그 주체임을 동시에 확인하는 것입니다. 이 두 가지 보장이 결합되어 온라인 뱅킹, 쇼핑, 로그인 등을 안전하게 만들어 줍니다.

비대칭 암호화와 대칭 암호화

HTTPS가 어떻게 작동하는지 이해하려면 암호학에서 두 가지 개념을 알아야 하는데, 이 개념들은 생각보다 간단합니다.

대칭 암호화는 데이터를 암호화하고 복호화하는 데 하나의 공유 비밀 키를 사용합니다. 이 방식은 매우 빠르고 효율적이어서 실제 브라우징 세션에서 대량의 데이터를 암호화하는 데 이상적입니다. 단점은 명백합니다. 양측이 동일한 키를 가져야 하는데, 보안이 취약한 네트워크를 통해 해당 키를 전송하면 도청자가 이를 가로챌 수 있습니다.

비대칭 암호화는 누구나 볼 수 있는 공개 키와 소유자가 비밀로 유지하는 개인 키라는 한 쌍의 키를 사용하여 키 공유 문제를 해결합니다. 공개 키로 암호화된 데이터는 개인 키로만 복호화할 수 있으며, 그 반대의 경우도 마찬가지입니다. 이를 통해 서로 모르는 두 사람이 공개 채널을 통해 비밀을 공유할 수 있습니다. 그러나 비대칭 암호화는 속도가 느리기 때문에 전체 통신에 사용되지는 않습니다.

HTTPS는 두 방식의 장점을 결합합니다. 처음에는 느린 비대칭 암호화를 잠시 사용하여 공유 비밀을 안전하게 설정한 다음, 세션의 나머지 기간 동안은 빠른 대칭 암호화로 전환합니다. 이러한 협상 과정을 TLS 핸드셰이크라고 합니다.

HTTPS의 작동 원리: TLS 핸드셰이크 살펴보기

웹 주소를 입력하면, 브라우저는 먼저 도메인 이름을 IP 주소로 변환합니다(이 과정은 DNS 작동 방식과 밀접하게 연관되어 있습니다). 그런 다음 해당 서버와의 연결을 열게 됩니다. 웹 페이지가 전송되기 전에 TLS 핸드셰이크가 이루어집니다. 그 과정을 단계별로 살펴보겠습니다.

1. ClientHello. 브라우저가 첫 번째 메시지를 보냅니다. 이 메시지에는 브라우저가 지원하는 TLS 버전, 사용할 수 있는 암호 모음(암호화 알고리즘의 조합), 그리고 키 생성에 사용될 난수 값이 포함됩니다. 이를 “저는 이런 사람이고, 이런 언어를 구사할 수 있습니다”라고 말하는 것으로 생각하면 됩니다.
2. ServerHello. 서버는 브라우저가 제공한 목록에서 사용할 TLS 버전과 암호 모음을 선택하여 응답하고, 자체적으로 생성한 난수 값을 전송합니다. 이제 양측은 통신 규칙에 대해 합의하게 됩니다.
3. 인증서. 서버는 공개 키와 인증 기관(CA)이 서명한 신원 정보가 포함된 SSL/TLS 인증서를 제시합니다. 이때 브라우저는 해당 인증서가 유효하고 신뢰할 수 있으며, 방문 중인 도메인을 위해 발급된 것인지 확인합니다.
4. 키 교환. 양측은 인증서의 공개 키(또는 타원 곡선 디피-헬만(Elliptic Curve Diffie-Hellman)과 같은 최신 키 합의 알고리즘)를 사용하여 공유 비밀 키를 안전하게 도출합니다. 중요한 점은, 모든 메시지를 엿듣는 도청자라도 이 비밀 키를 계산할 수 없다는 것입니다. 왜냐하면 개인 키는 서버를 절대 벗어나지 않기 때문입니다.
5. 세션 키 및 완료. 양측은 교환된 자료와 두 개의 난수 값을 사용하여 동일한 대칭 세션 키 세트를 생성합니다. 양측은 핸드셰이크가 성공했음을 증명하기 위해 이 키들로 암호화된 “완료” 메시지를 각각 전송합니다. 이 시점부터 전체 통신은 대칭 방식으로 암호화되며, 이는 빠르고, 비공개적이며, 변조 방지 기능을 갖추고 있습니다.

이 모든 과정은 대개 1초도 채 걸리지 않습니다. TLS 1.3에서는 핸드셰이크가 단 한 번의 왕복 통신으로 단축되었으며, 재방문자의 경우 때로는 더 빠르게 연결을 재개할 수도 있습니다. 그 결과, 실제 HTTPS 요청과 응답이 전송되는 안전한 채널이 구축됩니다.

인증 기관(CA)과 신뢰 체인

인증서의 신뢰도는 이를 보증하는 주체의 신뢰도에 달려 있습니다. 이 역할은 인증 기관(CA)이 담당하며, 이는 사용자의 브라우저와 운영 체제가 사전에 신뢰하기로 결정한 조직입니다. 웹사이트 소유자가 인증서를 요청하면, CA는 해당 소유자가 도메인을 관리하고 있음을(때로는 사업체 신원도) 확인한 후, CA의 자체 키로 인증서에 서명합니다. 브라우저는 바로 이 서명을 검증합니다.

신뢰는 다음 세 가지 연결고리로 구성된 체인 형태로 이루어집니다.

• 루트 인증서. 체인의 최상위입니다. 루트 인증서는 브라우저와 운영 체제의 “신뢰 저장소(trust store)”에 미리 설치되어 있습니다. 루트 인증서의 개인 키는 한 개라도 유출되면 전체 시스템이 훼손될 수 있으므로, 엄격한 보안 하에 오프라인 상태로 보관됩니다.
• 중간 인증서. 루트 인증서는 웹사이트 인증서에 직접 서명하지 않습니다. 대신 하나 이상의 중간 인증서에 서명하며, 이 중간 인증서들이 실제 사이트 인증서에 서명합니다. 이를 통해 귀중한 루트 키를 격리된 상태로 유지하고, 중간 인증서가 유출되더라도 루트 인증서에 영향을 주지 않고 해당 인증서만 취소할 수 있습니다.
• 리프 인증서. 최종 엔티티 인증서라고도 하며, 웹사이트 자체에 설치된 인증서입니다. 이 인증서는 중간 인증서에 의해 서명됩니다.

브라우저가 사이트를 검증할 때, 이 체인을 따라 올라갑니다. 즉, 리프 인증서는 중간 인증서에 의해 서명되고, 중간 인증서는 다른 중간 인증서나 루트 인증서에 의해 서명되며, 루트 인증서는 브라우저가 이미 신뢰하는 인증서입니다. 모든 연결이 정상이고 루트 인증서가 신뢰 저장소에 포함되어 있다면, 해당 인증서는 승인됩니다. 이를 ‘체인 구축’이라고 하며, “신뢰할 수 없음” 오류가 발생하는 일반적인 원인은 서버가 중간 인증서를 전송하는 것을 잊어 체인이 끊어지는 경우입니다.

인증서 유형

모든 인증서가 동일한 것은 아닙니다. 인증서 유형은 CA가 신청자를 검증하는 엄격한 정도와 해당 인증서가 적용되는 도메인의 수에 따라 다릅니다. 아래 표는 주요 유형을 요약한 것입니다.

일반 사용자를 위한 핵심 사항: 암호화 관점에서 볼 때 DV, OV, EV 인증서는 모두 동일합니다. 이들 모두 사용자의 데이터에 대해 동일한 수준의 강력한 보호 기능을 제공합니다. 차이점은 오로지 신원 보증에 있습니다. 예전에는 EV 인증서가 주소 표시줄에 회사 이름을 녹색으로 표시했지만, 브라우저에서 이러한 구분을 대부분 제거함에 따라 오늘날 대부분의 사이트는 저렴하거나 무료인 DV 인증서를 사용합니다.

와일드카드 및 다중 도메인 인증서

와일드카드 인증서는 별표(*)를 사용하여 기본 도메인의 모든 하위 도메인을 포괄합니다. 예를 들어, *.example.com에 대한 단일 인증서로 www.example.com, shop.example.com, login.example.com을 한 번에 보호할 수 있습니다. 다중 도메인 인증서(때로는 SAN 또는 UCC 인증서라고도 함)는 하나의 인증서에 완전히 서로 다른 여러 도메인 이름을 나열합니다. 두 가지 방식 모두 관리자가 관리해야 하는 인증서의 수를 줄여줍니다.

인증서의 구성 요소

인증서는 구조화된 문서이며, 모든 필드를 확인할 수 있습니다. 가장 중요한 필드는 다음과 같습니다.

• 주체(Subject). 인증서가 발급된 대상의 신원 정보로, 주로 도메인 이름(일반명, Common Name)을 의미합니다.
• 발급자(Issuer). 인증서에 서명하고 발급한 인증 기관(CA)입니다.
• 유효 기간. 인증서가 유효한 기간을 나타내는 “최소 유효 시작일”과 “최대 유효 종료일”입니다.
• 주체 대체 이름(Subject Alternative Names, SAN). 해당 인증서가 적용되는 도메인 이름의 전체 목록입니다. 최신 브라우저는 사이트를 식별할 때 기존의 ‘일반 이름(Common Name)’이 아닌 SAN 필드를 사용합니다.
• 공개 키. 핸드셰이크 과정에서 사용되는 키 쌍의 공개 부분입니다.
• 서명 알고리즘. CA가 서명하는 데 사용하는 암호화 방식입니다(예: RSA를 사용한 SHA-256 또는 ECDSA).
• 지문(Fingerprint). 인증서 전체에 대한 고유한 해시 값으로, 인증서를 정확히 식별하는 데 유용합니다.
• 일련 번호. 발급 CA가 할당한 고유 식별자입니다.

브라우저가 사이트를 검증할 때, 오늘 날짜가 유효 기간 내에 포함되는지, SAN 항목 중 하나가 도메인과 일치하는지, 서명이 손상되지 않았는지, 그리고 인증서 체인이 신뢰할 수 있는 루트 인증서로 연결되는지 확인합니다.

인증서 만료 및 유효 기간이 짧은 이유

모든 인증서에는 만료일이 있으며, 유효 기간은 수년에 걸쳐 급격히 단축되어 왔습니다. 한때 수년 동안 유효했던 인증서는 이제 1년 내외로 제한되며, 업계는 주 단위로 측정되는 더 짧은 유효 기간으로 나아가고 있습니다. 이러한 추세에는 타당한 이유가 있습니다.

유효 기간을 짧게 설정하면 개인 키가 도난당했을 때의 피해를 제한할 수 있습니다. 보안이 침해된 인증서는 단순히 더 빨리 만료되므로, 공격자가 이를 악용할 수 있는 시간이 줄어듭니다. 또한, 구식 암호화 알고리즘과 취소되었거나 실수로 발급된 인증서가 생태계에서 신속하게 제거되도록 보장합니다. 대신 관리자는 훨씬 더 자주 인증서를 갱신해야 하므로, 자동화는 선택 사항이 아닌 필수 요소가 되었습니다.

인증서가 무효화되면 어떻게 되나요?

검증 과정 중 어느 단계에서든 오류가 발생하면, 브라우저는 작은 아이콘 대신 전체 화면을 덮는 경고 메시지를 표시하며 연결을 차단합니다. 일반적인 오류 사례는 다음과 같습니다.

• 인증서 만료. 현재 날짜가 “만료일”을 초과한 경우입니다. 이는 가장 흔한 원인이며, 대개 갱신을 잊은 것을 의미합니다.
• 자체 서명된 인증서. 인증서가 신뢰할 수 있는 CA가 아닌 자체 키로 서명되었으므로 신뢰 체인이 존재하지 않습니다. 내부 테스트용으로는 괜찮지만, 브라우저는 공개 사이트에서는 이를 거부합니다.
• 이름 불일치. 방문한 도메인이 인증서의 SAN 목록에 나타나지 않습니다. 예를 들어, 한 도메인용 인증서가 다른 도메인에서 사용되고 있는 경우입니다.
• 신뢰할 수 없는 발급자. 인증서 체인이 사용자의 신뢰 저장소에 없는 루트 인증서로 연결되는 경우로, 대개 중간 인증서가 누락되었거나 CA가 인식되지 않기 때문입니다.
• 인증서 해지. CA가 만료 전에 인증서를 무효화했습니다. 이는 주로 키 유출로 인해 발생합니다.

각 경우에 브라우저는 "연결이 비공개가 아닙니다"와 같은 경고를 표시하고 기본적으로 해당 페이지를 차단합니다. 이러한 경고는 사용자를 보호하기 위한 것입니다. 일치하지 않거나 신뢰할 수 없는 인증서는 실제 중간자 공격의 징후일 수 있으므로, 민감한 데이터를 다루는 사이트에서는 절대 무심코 경고 메시지를 무시하고 넘어가서는 안 됩니다.

무료 인증서 및 자동 갱신

웹 보안 분야에서 가장 중요한 발전 중 하나는 무료 자동 인증서의 등장입니다. 비영리 인증 기관인 Let’s Encrypt는 DV 인증서를 무료로 제공할 뿐만 아니라, ACME(Automated Certificate Management Environment)라는 프로토콜을 통해 완전히 자동화할 수 있게 했습니다.

ACME를 통해 서버는 사람의 개입 없이 도메인에 대한 관리 권한을 증명하고, 인증서를 요청하며, 설치하고, 만료 전에 갱신할 수 있습니다. 이것이 바로 인증서 유효 기간을 짧게 설정하는 것이 실용적인 이유입니다. 몇 달마다 자동으로 갱신되는 인증서는 운영상의 부담을 주지 않기 때문입니다. 무료 발급과 자동화의 결합은 HTTPS가 소수의 기능에서 웹 전반에 걸쳐 거의 보편적인 기본 설정으로 자리 잡은 주요 이유입니다.

사이트의 인증서를 확인하는 방법

인증서를 확인하는 데 특별한 소프트웨어는 필요하지 않습니다. 최신 브라우저라면 주소 표시줄의 자물쇠 아이콘을 클릭하고 인증서 세부 정보를 확인하는 옵션을 선택하기만 하면 됩니다. 여기에는 피인증자, 발급자, 유효 기간, SAN 목록, 지문 등이 표시됩니다. 이는 현재 접속 중인 사이트가 정품인지 확인하고 인증서 만료일을 파악할 수 있는 빠른 방법입니다.

전체 인증서 체인, 서명 알고리즘, 만료까지 남은 일수 등을 포함하여 더 빠르고 상세하게 확인하려면 온라인 도구를 사용할 수 있습니다. 당사의 SSL 인증서 확인 도구를 사용하면 어떤 도메인이든 입력하여 해당 인증서가 유효한지, 신뢰할 수 있는 루트 인증서와 올바르게 연결되어 있는지, 갱신까지 남은 기간이 얼마나 되는지 즉시 확인할 수 있습니다. 이는 방문자에게 브라우저 경고가 표시되기 전에 곧 만료될 인증서를 미리 파악할 수 있는 간편한 방법입니다.

자주 묻는 질문

SSL과 TLS는 같은 것입니까?

정확히는 아닙니다. SSL은 오래된 프로토콜로 현재는 더 이상 사용되지 않는 반면, TLS는 이를 대체한 최신 프로토콜이며 오늘날 웹사이트 보안을 실제로 담당하고 있습니다. 하지만 “SSL 인증서”라는 용어가 관습적으로 굳어져, 실제 기술이 TLS인 경우에도 일상에서는 “SSL”과 “TLS”를 종종 같은 의미로 혼용합니다.

자물쇠 아이콘은 웹사이트가 안전하다는 뜻인가요?

자물쇠 아이콘은 해당 사이트와의 연결이 암호화되어 있으며, 해당 도메인에 대한 인증서가 유효함을 의미합니다. 이는 사이트 자체가 신뢰할 수 있거나 사기가 없다는 것을 보장하지는 않습니다. 심지어 사기 사이트도 무료 DV 인증서를 발급받을 수 있습니다. 자물쇠 아이콘은 전반적인 신뢰성을 보증하는 표식이 아니라, 비공개 연결이 이루어지고 있음을 나타내는 신호로만 받아들이시기 바랍니다.

무료 SSL 인증서는 유료 인증서만큼 안전한가요?

네, 암호화 측면에서는 그렇습니다. Let's Encrypt와 같은 인증 기관(CA)에서 발급하는 무료 DV 인증서는 고가의 인증서와 정확히 동일한 수준의 암호화 강도를 제공합니다. 유료 OV 및 EV 인증서는 조직에 대한 추가적인 신원 확인 절차를 거치지만, 암호화된 연결의 보안성을 더 강화하지는 않습니다.

왜 일부 사이트에서는 인증서 경고가 표시되나요?

인증서 경고는 유효성 검증이 실패했을 때 나타납니다. 가장 흔한 원인은 인증서 유효 기간이 만료되었거나, 도메인 이름과 일치하지 않거나, 자체 서명된 인증서이거나, 신뢰할 수 없는 인증 기관으로 연결되는 경우입니다. 이 경고는 브라우저가 사용자를 보호하기 위한 조치이므로, 비밀번호나 결제를 처리하는 사이트에서는 경고가 나타난 이유를 파악하지 않고 이를 무시해서는 안 됩니다.

SSL 인증서의 유효 기간은 얼마나 됩니까?

최신 공개 인증서의 유효 기간은 일반적으로 1년 이내이며, 업계에서는 점차 유효 기간을 훨씬 더 짧게 설정하는 추세입니다. 유효 기간을 짧게 설정하면 키 도난으로 인한 위험을 줄이고, 구식 암호화 방식의 사용을 자연스럽게 중단시킬 수 있습니다. ACME와 같은 프로토콜을 통한 자동 갱신 기능 덕분에 잦은 갱신도 번거로움 없이 처리할 수 있습니다.

브라우저에서 해당 사이트를 방문하지 않고도 인증서를 확인할 수 있나요?

네. 온라인 도구를 사용하면 도메인 이름을 입력하여 자물쇠 아이콘을 수동으로 확인하지 않고도 발급자, 유효 기간, 전체 신뢰 체인, 만료일까지 남은 일수 등 인증서 세부 정보를 확인할 수 있습니다. 이는 자신의 사이트를 모니터링하거나 방문하기 전에 도메인을 확인하는 데 유용합니다.