디지털 인증서와 공개키 기반구조(PKI) 이해하기

 

디지털 인증서의 정의와 역할

 

디지털 인증서(공개키 인증서)는 전자적인 “신분증” 역할을 하는 문서입니다.

웹사이트, 개인, 조직 등의 신원을 증명하고 해당 주체에 할당된 공개키의 유효성을 입증해주는 데이터 파일이라 볼 수 있습니다.

 

쉽게 말해, 디지털 인증서는 어떤 사람이나 서버의 공개키에 대한 신뢰할 수 있는 보증서입니다.

이를 통해 상대방이 제시하는 공개키가 정말 그 당사자의 것인지를 확인할 수 있으며, 안전하게 암호화 통신을 시작하거나 전자 서명을 검증할 수 있습니다.

 

디지털 인증서가 없다면, 공개키 암호 방식에서 공개키의 주인이 누구인지 신뢰할 방법이 없어 중간자 공격 등의 위험에 노출되기 쉽습니다.

 

따라서 디지털 인증서는 인터넷 상에서 신원 확인(Authentication)과 데이터 암호화(Encryption)의 기반을 제공하여 전자 상거래, 금융 거래, 이메일 통신 등 다양한 분야에서 보안의 핵심 역할을 담당합니다 .

 

 

 

---

 

인증서에 포함되는 주요 정보들

디지털 인증서에는 해당 인증서의 대상과 신뢰를 위해 필요한 여러 가지 정보가 담겨 있습니다. 일반적으로 다음과 같은 중요 필드들이 포함됩니다 :

 

• 소유자 정보(주체, Subject)
  • 인증서의 주체 이름(예: 개인 이름 또는 도메인 이름)과 조직 정보 등 인증서 소유자를 식별할 수 있는 정보입니다. 예를 들어 웹사이트 인증서의 경우 인증서의 주체에 도메인 이름이 명시되고, 코드 서명 인증서의 경우 개발자나 회사명이 포함됩니다.
• 발급자 정보(Issuer)
  • 인증서를 발급한 **인증기관(CA)**의 이름과 식별 정보입니다. 브라우저나 운영체제는 이 정보를 보고 어느 CA가 이 인증서를 발급했는지 알 수 있으며, 해당 CA를 신뢰할 수 있는지 판단하게 됩니다.
• 공개키(Public Key)
  • 인증서 소유자의 공개키 값이 포함됩니다. 이 공개키에 대응되는 **개인키(Private Key)**는 소유자만이 가지고 있으며 외부에 공개되지 않습니다. 공개키는 이후에 데이터 암호화나 전자서명 검증에 사용되며, 인증서는 이 공개키가 어떤 주체에게 속하는지를 보증하는 역할을 합니다 .
• 유효 기간(Validity)
  • 인증서의 **유효 시작일(발급일)**과 만료일이 명시됩니다. 모든 인증서는 일정한 기간 동안만 유효하며, 만료일이 지나면 더 이상 신뢰할 수 없게 됩니다. 또한 보안상의 이유로 인증서의 유효 기간은 제한적으로 설정되는데, 예를 들어 최신 브라우저에서는 일반적으로 1년 안팎의 기간으로 제한하고 있습니다.
• 일련번호(Serial Number) 및 버전(Version)
  • 인증서마다 부여되는 고유한 일련번호가 포함되어 있어 특정 인증서를 식별할 수 있습니다. 버전은 X.509 표준 버전을 나타내며, 현재 대부분의 인증서는 X.509 v3 형식을 따릅니다.
• 디지털 서명(Digital Signature)
  • 가장 중요한 항목 중 하나로, 인증서를 발급한 CA의 전자서명 값입니다. CA가 인증서의 내용(주체 정보, 공개키 등)에 전자서명을 해서 넣어두며, 이를 통해 인증서의 무결성과 출처를 검증할 수 있습니다 . 검증자는 이 서명을 CA의 공개키로 검증하여 인증서 내용이 위변조되지 않았고 신뢰할 수 있는 CA에서 발급된 것임을 확인합니다.

 

 

이 밖에도 전자서명 알고리즘 정보(SHA-256 with RSA 등), 키 사용 용도(Key Usage), **주체 대체 이름(Subject Alternative Name, SAN)**과 같은 X.509 v3 **확장 필드(Extensions)**들이 포함될 수 있습니다.

 

예를 들어 SAN 필드는 하나의 인증서에 여러 개의 도메인 이름이나 IP를 포함시켜, 하나의 인증서로 복수의 식별자를 커버할 수 있게 해줍니다.

 

또한 인증서에는 CRL 배포 지점(인증서 폐기 목록의 위치)이나 OCSP 응답 주소 등의 정보도 들어 있어, 인증서의 상태 검증에 활용됩니다.

 

---

 

인증서의 발급 과정 및 서명 원리

디지털 인증서는 정해진 발급 절차를 거쳐 생성됩니다. 새로운 인증서를 발급받기 위해서는 **인증기관(CA)**이 신청자의 신원을 확인하고 해당 신청자의 공개키에 서명하는 과정이 필요합니다. 일반적인 인증서 발급 과정은 다음과 같습니다 :

 

1. 키 쌍 생성(Key Generation)
   • 인증서 신청자는 우선 본인이 사용할 공개키-개인키 쌍을 생성합니다. 개인키는 본인만 알고 비밀로 유지하고, 공개키는 나중 단계에서 CA에 제출됩니다.
2. CSR 제출(Certificate Signing Request)
   • 신청자는 자신의 공개키와 식별 정보(이름, 도메인 등)를 포함한 CSR(인증서 서명 요청서)을 작성합니다. CSR에는 공개키와 함께 어떤 종류의 인증서를 원하는지, 조직 정보 등 필요한 신원 정보가 담기며, 신청자는 CSR에 자신의 개인키로 서명하여 본인이 해당 공개키의 소유자임을 증명합니다. 이렇게 서명된 CSR을 CA에 제출합니다 .
3. 신원 검증(Verification)
   • CA는 제출된 CSR을 검토하여 신청자의 신원을 확인합니다. 개인의 경우 신분증 확인이나 이메일 도메인 확인 등이 있을 수 있고, 웹사이트의 경우 도메인 소유권 확인(DNS에 지정된 토큰 등록, 이메일 인증 등)을 수행합니다. 기업 인증서의 경우 사업자 등록증 등 추가 서류 확인을 거쳐 신청 조직의 합법성까지 검증합니다. 이 단계에서 CA는 직접 신원을 확인하기도 하고, 경우에 따라 **등록기관(RA)**의 도움을 받아 신청자 정보를 심사하기도 합니다 .
4. 인증서 발급(Issuance)
   • 신청자의 신원이 확인되면, CA는 CSR에 포함된 공개키와 신청자 정보를 바탕으로 디지털 인증서를 발급합니다. 이때 CA는 자신의 개인키로 새 인증서의 내용에 서명하여 인증서를 생성합니다 . 이렇게 서명됨으로써 인증서에는 CA의 디지털 서명이 포함되고, 누구나 CA의 공개키로 해당 서명을 검증할 수 있게 됩니다. 발급된 인증서에는 앞서 말한 주체 정보, 공개키, 만료일 등의 필드가 채워져 있고, CA의 서명이 추가되어 최종 완성됩니다.
5. 인증서 설치 및 활용(Installation & Use)
   • 생성된 인증서는 신청자에게 전달됩니다. 웹 서버 인증서의 경우, 신청자는 서버에 인증서와 해당 공개키에 대응하는 개인키를 함께 설정하여 클라이언트와의 SSL/TLS 통신에 사용합니다. 클라이언트(예: 웹 브라우저)가 서버에 접속하면 이 서버 인증서를 내려받아 신뢰 검증을 수행한 후, 서버의 공개키로 안전하게 대칭키 교환 등을 진행하여 암호화 통신을 시작합니다. 이밖에도 발급된 인증서는 전자서명에 활용되거나(VPN 접속용 클라이언트 인증서 등), 코드 서명에 사용되어 소프트웨어 배포 시 출처 확인에 활용되는 등 다양한 용도로 쓰입니다.

 

이 과정의 핵심은 CA의 전자서명 원리입니다.

CA는 인증서에 포함된 정보들을 해시(Hash)한 후 자신의 개인키로 암호화하여 서명을 만듭니다.

검증자는 CA의 공개키로 해당 서명을 풀어 원본 해시를 얻고, 인증서 정보로부터 새로 계산한 해시와 일치하는지 비교합니다.

일치하면 서명이 유효한 것이며, 이 인증서를 CA가 발급했고 내용이 위조되지 않았음을 보장받습니다.

이러한 전자서명 덕분에 누구나 인증서를 신뢰하고 활용할 수 있지만, 전제 조건으로 그 CA 자체를 신뢰해야 합니다.

이를 위해 인증기관(CA)의 신뢰 체계가 따로 존재하는데, 이는 다음 절에서 살펴보겠습니다.

 

---

인증기관(CA)의 역할과 종류

 

인증기관(Certificate Authority, CA)은 신뢰할 수 있는 제3자 기관으로서 디지털 인증서를 발급하고 서명해주는 역할을 담당합니다. CA는 자신이 신원 확인을 거쳐 발급한 인증서에 서명함으로써, 해당 공개키가 특정 주체에 속함을 보증합니다 . 모두가 CA를 신뢰하기 때문에, CA가 서명한 인증서도 신뢰할 수 있게 되는 구조입니다. 오늘날 공개 웹에서 사용되는 대부분의 인증서는 잘 알려진 공개 신뢰 CA들에 의해 발급되며, 이들은 브라우저나 운영체제에 내장된 신뢰 목록(루트 인증서 저장소)에 포함되어 있습니다. 한편 기업이나 기관 내부에서 사용하는 사설 CA를 구축할 수도 있는데, 이 경우 해당 CA의 루트 인증서를 별도로 신뢰 저장소에 설치해야만 내부 인증서를 신뢰할 수 있습니다.

 

CA에는 계층적인 구조와 종류가 있습니다 :

 

• 루트 CA(Root CA)
  • 신뢰 사슬의 최상위에 있는 CA입니다. 루트 CA의 인증서는 스스로에 의해 서명된(self-signed) 것이 특징인데, 이는 그보다 상위 신뢰 주체가 없기 때문입니다. 운영체제나 브라우저는 사전에 믿을 수 있는 루트 CA들의 인증서를 내장해두고 이들을 신뢰의 시작점(Trust Anchor)으로 사용합니다 . 루트 CA는 보통 보안이 철저한 오프라인 환경에서 관리되며, 엄격한 보안 정책 하에 자신의 하위 CA들에게만 인증서를 발급합니다. 루트 인증서의 유효기간은 매우 길게(수년~수십 년) 설정되며, 루트 CA 자체가 해킹당하면 그 체계 전체가 무너질 정도로 중요한 신뢰 근간입니다.
  • 대표적인 루트 CA 기관은 아래와 같습니다.

    • 점유율 정보는 매년 달라질 수 있습니다.

      1. Let’s Encrypt
         • 비영리 단체인 Internet Security Research Group(ISRG)에서 운영하며, 무료로 SSL/TLS 인증서를 발급합니다. 현재 전 세계 웹사이트의 약 59.9%가 Let’s Encrypt의 인증서를 사용하고 있습니다.
      2. GlobalSign
         • 벨기에에 본사를 둔 글로벌 인증기관으로, 다양한 보안 솔루션을 제공합니다. 시장 점유율은 약 21.0%입니다.
      3. Sectigo (구 Comodo CA)
         • 미국 기반의 인증기관으로, 다양한 SSL/TLS 인증서를 제공합니다. 시장 점유율은 약 5.6%입니다.
      4. GoDaddy
         • 도메인 등록 서비스로 잘 알려진 GoDaddy는 자체 루트 인증서를 통해 SSL 인증서를 발급합니다. 시장 점유율은 약 3.9%입니다.
      5. DigiCert
         • 고급 보안 인증서와 기업용 솔루션을 제공하는 미국의 인증기관입니다. 시장 점유율은 약 3.1%입니다.
      6. Entrust
         • 정부 및 대기업을 위한 보안 솔루션을 제공하는 미국의 인증기관입니다. 루트 인증서는 Microsoft의 신뢰 목록에 포함되어 있습니다.
      7. IdenTrust
         • 금융기관 및 정부 기관에 특화된 인증기관으로, 다양한 보안 인증서를 제공합니다.
      8. SSL.com
         • 미국 텍사스에 본사를 둔 인증기관으로, 다양한 SSL/TLS 인증서를 제공합니다. 루트 인증서는 Microsoft의 신뢰 목록에 포함되어 있습니다.
      9. Amazon Trust Services
         • AWS 기반 서비스에 사용되는 인증서를 발급하며, 루트 인증서는 Microsoft의 신뢰 목록에 포함되어 있습니다.
      10. Google Trust Services (GTS)
          • Google이 운영하는 인증기관으로, 다양한 SSL/TLS 인증서를 제공합니다. 루트 인증서는 Microsoft의 신뢰 목록에 포함되어 있습니다.
• 중간 CA(Intermediate/Subordinate CA)
  • 하위 인증기관으로, 루트 CA가 직접 발급한 인증서이거나 더 상위의 중간 CA가 발급한 인증서를 통해 서명된 CA입니다. 즉, 중간 CA의 인증서에는 발급자로 루트 CA(또는 상위 CA)가 명시되고, 루트 CA의 서명이 들어 있습니다. 중간 CA는 최종 사용자나 서버 인증서(End-Entity Certificate)를 직접 발급하며, 필요에 따라 여러 계층의 중간 CA가 존재할 수도 있습니다. 중간 CA를 두는 이유는 루트 CA의 부담을 덜고 보안을 강화하기 위해서입니다. 루트 CA의 키를 직접 자주 사용하지 않고 중간 CA들을 통해 대리 발급하게 하면, 루트 키를 오프라인 상태로 안전하게 보관하면서도 인증서 발급 업무를 수행할 수 있습니다. 중간 CA가 발급한 인증서들은 루트 CA의 서명을 간접적으로 상속받는 효과가 있으므로, 최종적으로 루트 CA를 신뢰한다면 중간 CA가 발급한 인증서도 신뢰할 수 있게 됩니다 .
    
    

 

이처럼 루트 CA와 중간 CA들이 이루는 위계 구조를 인증서 체계 계층(Certificate Hierarchy) 또는 피라미드에 비유하기도 합니다.

일반 사용자는 여러 루트 CA들을 신뢰 목록에 가지고 있고, 각 루트 CA마다 다수의 중간 CA들이 있으며, 또 그 밑에 수많은 사이트와 사용자 인증서들이 발급되어 있다는 구조입니다.

 

참고로, 공개 웹에서는 CA/브라우저 포럼 등에서 정한 엄격한 인증 정책과 감사 기준(WebTrust 등)을 준수하는 루트 CA들만이 신뢰 저장소에 포함되고 있습니다. 이들 신뢰할 수 있는 CA 목록은 OS나 브라우저 업데이트를 통해 관리되며, 부적격하거나 해킹된 CA는 목록에서 제거되기도 합니다 (예: 과거 WoSign, StartCom 등의 루트 인증서가 불신 처리됨).

 

 

PKI(Public Key Infrastructure)의 구성 요소와 동작 방식

공개키 기반구조(PKI)는 디지털 인증서와 공개키 암호화 체계를 관리하고 운영하기 위한 전체 인프라 스트럭처를 말합니다 . 이는 하드웨어, 소프트웨어, 정책, 절차 및 인력을 모두 포함하는 포괄적인 개념으로, 안전한 전자거래와 통신을 가능케 하는 신뢰 관리 시스템입니다 . PKI를 구성하는 핵심 요소와 기관들은 다음과 같습니다 :

 

• 인증기관(CA): 신뢰받은 제3자 발급 기관으로서 디지털 인증서를 발급하고 서명합니다. PKI의 중심에 해당하며, 상위 CA일수록 더 넓은 신뢰를 부여받습니다. 공개 PKI 환경의 루트 CA들은 엄격한 기준에 따라 운영되며, 자체적으로 **인증서 폐기 목록(CRL)**도 관리하여 신뢰 유지에 책임을 집니다 .
• 등록기관(RA): 등록 담당 기관으로, 인증서 발급을 위해 신청자의 신원 확인을 담당합니다. RA는 CA로부터 일부 권한을 위임받아 인증서 요청을 접수하고 신청자의 정보를 검증하는 역할을 합니다 . RA는 검증이 끝나면 그 정보를 CA에 전달하고, 최종 발급은 CA가 수행합니다. 큰 조직이나 공개 CA에서는 RA를 별도로 두어 업무를 분산하며, RA는 일종의 등기소나 신원 확인 창구에 비유할 수 있습니다.
• 인증서 저장소(Repository): 발급된 인증서들과 폐기 목록(CRL) 등을 보관하고 배포하는 저장소입니다. 전통적으로 LDAP 등의 디렉터리가 활용되었으며, 디렉터리 서버에 인증서와 CRL을 게시해 두면 클라이언트나 운영자가 이를 다운로드하여 검증에 사용할 수 있습니다 . 현대에는 CA의 웹 서버를 통해 인증서 검색이나 OCSP 응답으로 대체되기도 하지만, 여전히 공개키 기반구조의 한 구성 요소로 논의됩니다.
• 인증서 이용자(가입자, Subscriber): 인증서를 발급받아 실제로 사용하는 최종 사용자 혹은 시스템입니다. 예를 들어 웹 서버 관리자, 개인 이메일 사용자, 개발자 등이 해당되며, 자신의 개인키와 매칭되는 인증서를 보유하게 됩니다. 가입자는 PKI를 통해 자신의 공개키에 대한 공식 신뢰를 얻어 다양한 보안 기능을 구현합니다.
• 신뢰 당사자(Relying Party): 인증서를 제시받고 그것을 신뢰하여 행동하는 주체를 말합니다. 이는 곧 인증서 검증을 수행하는 모든 주체로 볼 수 있는데, 대표적으로 웹 브라우저, 운영체제, 응용 프로그램 등이 있습니다. 이들은 PKI를 통해 배포된 루트 인증서 목록을 기반으로 인증서를 검증하고, 그 결과에 따라 사용자에게 서비스를 제공하거나 접근을 허용합니다. 신뢰 당사자는 PKI의 최종 소비자라 할 수 있으며, PKI가 돌아가는 목적이 바로 이들이 안전한 소통을 할 수 있도록 하는 데 있습니다.

이외에도 PKI 환경에는 검증 기관(VA, Validation Authority)이나 정책 인증기관(Policy Authority), 그리고 CA의 키 관리를 위한 HSM(Hardware Security Module) 등 부수적인 요소들이 존재할 수 있습니다.

예를 들어 대규모 PKI에서는 OCSP 응답과 같은 인증서 상태 검증을 전문으로 하는 VA를 두어, 클라이언트의 인증서 유효성 검증 요청을 처리하기도 합니다. 또한 각 구성원들의 행위를 규정하는 인증서 정책(Certificate Policy)과 인증 실무 진술서(CPS)가 문서로 존재하여 PKI의 신뢰 수준과 운영 절차를 정의합니다.

이러한 모든 요소들이 유기적으로 동작하여, 신규 인증서 발급부터 배포, 검증, 폐기에 이르는 인증서 수명주기 관리(Certificate Lifecycle Management)가 이루어집니다. 결국 PKI는 공개키를 누가 신뢰할 것인가에 대한 해답을 시스템으로 구현한 것으로, 인터넷과 다양한 디지털 환경에서 신뢰의 기반을 제공하고 있습니다 .

 

 

웹 브라우저, 운영체제, 모바일 환경에서의 인증서 활용 예시

 

디지털 인증서와 PKI는 일상적인 IT 환경 곳곳에서 활용되고 있습니다.

몇 가지 대표적인 사용 사례를 살펴보겠습니다.

 

• 웹 브라우저의 HTTPS 통신
  • 우리가 브라우저로 접속하는 https:// 사이트들은 모두 SSL/TLS 인증서를 사용하여 서버의 신원을 증명하고 통신을 암호화합니다.
  • 예를 들어 사용자가 인터넷 뱅킹 사이트에 접속하면, 그 사이트는 자신의 서버 인증서를 브라우저에 제시합니다. 브라우저는 앞서 설명한 대로 인증서의 서명과 체인을 검증하고, 유효하면 주소창에 자물쇠 아이콘을 표시하여 암호화된 안전 연결임을 나타냅니다. 사용자는 별다른 작업 없이도 PKI를 통해 사이트의 신뢰성을 보장받고 정보를 주고받을 수 있는 것입니다. 반대로 인증서가 유효하지 않거나 신뢰할 수 없으면 브라우저는 큰 경고를 띄워 사용자가 연결을 차단하도록 합니다. 이처럼 HTTPS의 보안은 PKI에 전적으로 의존하고 있으며, 브라우저에는 수백 개에 달하는 전세계 루트 CA 인증서들이 내장되어 있어서 자동으로 서버 인증서를 검증해주고 있습니다 . 또한 브라우저 개발사(예: 모질라, 구글 등)들은 CA/브라우저 포럼 등과 협력하여 PKI의 안정성을 지속적으로 개선하고, 인증서 투명성(CT) 로그와 같은 추가 메커니즘을 통해 잘못 발급된 인증서도 모니터링하고 있습니다.
• 운영체제의 보안 기능
  • PC나 서버 운영체제도 다양한 측면에서 인증서를 활용합니다. 예를 들어 소프트웨어 서명 검증이 그 중 하나입니다. 윈도우(OS)에서는 실행 파일(EXE)이나 드라이버가 로드될 때 코드 서명 인증서로 서명이 되어 있는지 확인하여, 신뢰할 수 있는 공급자의 소프트웨어인지를 판단합니다. 사용자가 프로그램을 설치할 때 “신뢰할 수 있는 발행자(Verified Publisher)” 라고 표시되는 것도 해당 개발자에게 발급된 코드 서명 인증서로 서명되었기 때문에 가능한 일입니다. 이러한 코드 서명 인증서 역시 공개 신뢰 CA들이 개발자나 기업의 신원을 확인한 후 발급하며, 운영체제는 CA의 서명을 검증함으로써 프로그램의 출처와 무결성을 검증합니다. 이밖에도 운영체제 업데이트 파일에 서명하여 위변조 여부를 확인하거나, 전쟁터모드 보안 부팅(Secure Boot) 시 펌웨어와 OS 로더의 서명을 PKI로 검증하는 등, 다양한 보안 기능들이 인증서에 의존하고 있습니다.
• 모바일 및 기타 환경
  • 스마트폰 환경에서도 인증서는 중요한 역할을 합니다. 모바일 OS (안드로이드, iOS 등)는 자체적으로 신뢰할 수 있는 루트 인증서 목록을 내장하고 있어, 모바일 브라우저나 앱에서 TLS 통신을 할 때 똑같이 서버 인증서를 검증합니다.
  • 예를 들어 모바일 뱅킹 앱이 서버와 통신할 때도 HTTPS를 사용하며, OS 수준에서 해당 서버 인증서의 체인을 검증하여 암호화 통신을 설정합니다. 또한 모바일 앱 자체도 배포 시 서명되어 사용자 단말에 설치되는데, 이때 사용하는 앱 서명도 일종의 인증서 기반 서명입니다. 안드로이드의 경우 각 개발자가 자체 서명한 APK를 배포하지만, iOS는 애플이 개발자에게 발급한 인증서를 통해 서명하고 앱스토어가 배포하도록 되어 있어 좀 더 PKI 중앙관리적인 특징이 있습니다. 이처럼 모바일 기기에서도 신뢰할 수 있는 코드만 실행하고 안전한 통신만 이루어지도록 하는 데 인증서와 PKI가 활용되고 있습니다. 그 밖에 기업 내부에서 스마트카드나 OTP 기반 인증, VPN 접속 등에 클라이언트 인증서를 사용하거나, 사물인터넷(IoT) 기기 인증에 PKI를 도입하는 등 활용 범위는 매우 넓습니다.