맨위로가기

공개 키 인증서

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

공개 키 인증서는 공개 키를 사용하여 개체의 신원을 확인하는 데 사용되는 전자 문서이다. 다양한 유형의 인증서가 존재하며, TLS/SSL 서버 인증서는 웹 서버와 클라이언트 간의 안전한 통신을 위해 사용된다. 이 외에도 TLS/SSL 클라이언트 인증서, 이메일 인증서, 자가 서명 인증서, 와일드카드 인증서, 코드 서명 인증서, 적격 인증서 등 다양한 용도로 사용되는 인증서들이 있다. 인증서는 일련 번호, 소유자, 서명 알고리즘, 발행자, 유효 기간, 공인 키 등의 정보를 포함하며, 인증 기관(CA)은 인증서의 서명을 담당한다. 웹사이트 보안을 위해 HTTPS 기반 웹사이트는 공개 키 인증서를 사용하며, 도메인 검증, 조직 검증, 확장 검증과 같은 인증 수준이 존재한다. 인증서는 만료 전에 폐지될 수 있으며, 웹 브라우저는 폐지 확인을 제한적으로 수행한다. NIST는 공개 키 인증서에 대한 지침을 제공하며, 가장 일반적인 인증서 규격은 ITU-T X.509이다.

2. 인증서의 종류

공개 키 인증서는 사용 목적과 검증 수준에 따라 다양한 종류로 나뉜다.

전송 계층 보안(TLS) 프로토콜(및 이전 버전인 보안 소켓 계층(SSL))은 클라이언트 컴퓨터와 서버 간의 통신을 안전하게 보장한다. 이때, 서버는 디지털 인증서를 제시하여 자신이 의도된 대상임을 증명해야 한다. 인증서의 주체(Subject) 필드는 서버의 기본 호스트 이름을 일반 이름(Common Name)으로 식별해야 하며,[3] 하나의 인증서는 여러 호스트 이름(예: 도메인 및 하위 도메인)에 대해 유효할 수 있다. 이러한 인증서를 주체 대체 이름(SAN) 인증서 또는 통합 통신 인증서(UCC)라고 한다.

S/MIME 프로토콜에서 사용되는 이메일 인증서는 메시지 무결성을 확립하고 메시지를 암호화하는 데 사용된다. 암호화된 이메일 통신을 위해서는 통신 당사자들이 사전에 디지털 인증서를 보유하고 있어야 한다.

자가 서명 인증서는 발급자와 주체가 동일하며 자체 공개 키로 확인할 수 있는 서명이 있는 인증서이다. 디지털 인증서의 신뢰 체인은 루트 인증서(신뢰 앵커 또는 신뢰 루트라고도 함)라는 자가 서명 인증서로 시작한다. 인증 기관은 루트 인증서에 자체 서명하여 다른 인증서에 서명할 수 있다.

위키미디어 재단이 소유한 도메인 이름에 대한 Subject Alternative Name 섹션의 예시


주체 대체 이름(SAN) 인증서는 `subjectAltName` 필드를 사용하여 보안 인증서와 다양한 값을 연결할 수 있다.[5] 이러한 값에는 이메일 주소, IP 주소, URI, DNS 이름 등이 포함될 수 있다.[6]

comifuro.net의 와일드카드 인증서 예시 (별표(*)에 유의)


도메인 이름의 일부에 별표(와일드카드)를 사용하는 공개 키 인증서를 와일드카드 인증서라고 한다. 와일드카드 인증서는 하나의 인증서로 여러 개의 서브도메인을 사용할 수 있게 해준다.

EMV는 결제 카드, 결제 단말기, 현금 자동 입출금기(ATM)에 대한 기술 표준을 기반으로 하는 결제 방식이며, EMV 결제 카드에는 EMV 인증 기관[25]이 서명한 카드 발급자 인증서가 미리 로드되어 있다. 코드 서명 인증서는 컴퓨터 프로그램의 유효성을 검사하는 데 사용된다.

공개 키 암호를 광범위하게 사용할 때, 사용자 간에 암호 키를 직접 주고받는 것은 매우 작은 네트워크가 아니면 실용적이지 않다. 공개 키 암호는 이 키 배송 문제를 회피하는 수단을 제공한다. 공개 키 기반 구조(PKI)에서는 인증 기관(CA)이 신뢰할 수 있는 제3자 기관(TTP) 역할을 한다.

2. 1. TLS/SSL 서버 인증서

전송 계층 보안(TLS) 프로토콜과 그 이전 버전인 보안 소켓 계층(SSL) 프로토콜은 클라이언트 컴퓨터와 서버 간의 통신을 안전하게 보장한다. 이 프로토콜은 서버가 디지털 인증서를 제시하여 의도된 대상임을 증명하도록 요구한다.

가장 일반적인 인증서 사용은 HTTPS 기반 웹사이트에 적용된다. 웹 브라우저는 HTTPS 웹 서버가 진본임을 검증하여 사용자가 웹사이트와의 상호 작용에 도청자가 없으며 웹사이트가 자신이 주장하는 존재임을 확신할 수 있도록 한다. 이러한 보안은 전자 상거래에 중요하며, 웹사이트 운영자는 인증서 서명 요청을 통해 인증 기관에 신청하여 인증서를 획득한다. 인증서 요청은 웹사이트 이름, 회사 정보 및 공개 키를 포함하는 전자 문서이다. 인증서 제공자는 요청에 서명하여 공개 인증서를 생성한다. 웹 브라우징 중 이 공개 인증서는 웹사이트에 연결하는 모든 웹 브라우저에 제공되며, 제공자가 웹사이트 소유자에게 인증서를 발급했다고 믿는다는 것을 웹 브라우저에 증명한다.

예를 들어 사용자가 브라우저를 사용하여 `https://www.example.com/`에 연결할 때 브라우저가 인증서 경고 메시지를 표시하지 않으면, 사용자는 `https://www.example.com/`과의 상호 작용이 "example.com"의 공개 등록부에 나열된 이메일 주소와 연락하는 엔티티와의 상호 작용과 동일하다고 이론적으로 확신할 수 있다. 비록 해당 이메일 주소가 웹사이트 어디에도 표시되지 않을 수 있더라도 말이다. 어떠한 종류의 다른 보증도 함축되지 않는다. 또한, 인증서 구매자, 웹사이트 운영자 및 웹사이트 콘텐츠 생성자 간의 관계는 불안정할 수 있으며 보장되지 않는다. 기껏해야, 인증서는 웹사이트 자체가 손상(해킹)되지 않았거나 인증서 발급 프로세스가 전복되지 않은 경우 웹사이트의 고유성을 보장한다.

인증서 제공자는 각각 자체적인 검증 엄격성을 요구하는 세 가지 유형의 인증서를 발급하도록 선택할 수 있다. 엄격성이 증가하는 순서(그리고 당연히 비용도 증가)대로 도메인 검증, 조직 검증 및 확장 검증이 있다. 이러한 엄격성은 CA/브라우저 포럼의 자발적 참여자들에 의해 대략적으로 합의되었다.

2. 1. 1. 한국 웹 환경에서의 TLS/SSL 인증서

전송 계층 보안(TLS) 프로토콜과 이전 버전인 보안 소켓 계층(SSL) 프로토콜은 클라이언트와 서버 간의 안전한 통신을 보장한다. 이 프로토콜은 서버가 디지털 인증서를 제시하여 자신이 의도된 대상임을 증명하도록 요구한다. 연결하는 클라이언트는 인증 경로 유효성 검사를 수행하여 다음을 확인한다.

  • 인증서의 주체(Subject)가 클라이언트가 연결하려는 호스트 이름과 일치하는지 확인한다. (도메인 이름과 혼동하지 않도록 주의)
  • 신뢰할 수 있는 인증 기관이 인증서에 서명했는지 확인한다.


인증서의 ''주체(Subject)'' 필드는 서버의 기본 호스트 이름을 ''일반 이름(Common Name)''으로 식별해야 한다.[3] 호스트 이름은 사설 IP 주소나 예약된 도메인을 사용하지 않고 공개적으로 접근 가능해야 한다.[3] 하나의 인증서는 여러 호스트 이름(예: 도메인 및 하위 도메인)에 대해 유효할 수 있다. 이러한 인증서를 일반적으로 ''주체 대체 이름(SAN) 인증서'' 또는 ''통합 통신 인증서(UCC)''라고 한다. 이러한 인증서는 주체 대체 이름 필드를 포함하지만, 많은 CA(인증 기관)는 이전 버전과의 호환성을 위해 이를 ''주체 일반 이름'' 필드에도 넣는다. 일부 호스트 이름에 별표(*)가 포함된 경우 해당 인증서를 와일드카드 인증서라고 부르기도 한다.

인증 경로 유효성 검사가 성공하면 클라이언트는 서버와 암호화된 연결을 설정할 수 있다.

공개 웹 서버와 같은 인터넷 연결 서버는 신뢰할 수 있는 공개 인증 기관(CA)으로부터 인증서를 받아야 한다.

2. 2. TLS/SSL 클라이언트 인증서

루트 인증서, 중간 인증서 및 최종 엔터티 인증서의 역할 (신뢰 사슬)


TLS/SSL 클라이언트 인증서는 서버뿐만 아니라 클라이언트의 신원도 확인하여 접근 제어를 강화하는 데 사용된다. 대부분의 서비스는 장치보다는 개인에게 접근 권한을 제공하므로, 클라이언트 인증서에는 보통 호스트 이름 대신 이메일 주소나 개인 이름이 포함된다.[4] 클라이언트 인증서를 발급하는 인증 기관은 일반적으로 클라이언트가 연결하는 서비스 제공자인데, 이는 인증을 수행해야 하는 주체가 서비스 제공자이기 때문이다. 일부 서비스 제공자는 패키지의 일부로 무료 SSL 인증서를 제공하기도 한다.[4]

대부분의 웹 브라우저는 클라이언트 인증서를 지원하지만, 인터넷에서 가장 흔한 인증 방식은 사용자 이름과 비밀번호를 함께 사용하는 방식이다. 클라이언트 인증서는 가상 사설망(VPN) 및 원격 데스크톱 서비스에서 더 자주 사용된다.

2. 3. 이메일 인증서

S/MIME 프로토콜에 따라, 이메일 인증서는 메시지 무결성을 확립하고 메시지를 암호화할 수 있다. 암호화된 이메일 통신을 설정하려면, 통신 당사자들이 디지털 인증서를 미리 가지고 있어야 한다. 각 당사자는 상대방에게 디지털 서명된 이메일을 보내고, 보낸 사람의 인증서를 가져오도록 선택해야 한다.[1]

일부 공개적으로 신뢰할 수 있는 인증 기관에서 이메일 인증서를 제공하지만, 일반적으로 S/MIME은 특정 조직 내에서 통신할 때 사용되며, 해당 조직은 자체 CA를 운영하고, 이는 해당 이메일 시스템의 참가자들에게 신뢰받는다.[1]

2. 4. 자가 서명 인증서 및 루트 인증서

자가 서명 인증서는 발급자와 주체가 일치하고, 자체 공개 키로 확인할 수 있는 서명이 있는 인증서이다. 자가 서명 인증서는 제한적인 용도로 사용된다. 발급자와 사용자가 동일한 경우 완전한 신뢰 값을 가진다. 예를 들어, Microsoft Windows의 암호화 파일 시스템은 암호화하는 사용자를 대신하여 자가 서명 인증서를 발급하고, 이를 사용하여 데이터를 투명하게 해독한다.

디지털 인증서의 신뢰 체인은 루트 인증서(신뢰 앵커 또는 신뢰 루트라고도 함)라는 자가 서명 인증서로 시작한다. 인증 기관은 다른 인증서에 서명하기 위해 루트 인증서에 자체 서명한다.

중간 인증서는 루트 인증서와 유사하게 다른 인증서에 서명하는 데 사용된다. 그러나 중간 인증서는 자가 서명되지 않으며, 루트 인증서 또는 다른 중간 인증서가 서명해야 한다.

종단 엔터티(리프 인증서)는 다른 인증서에 서명할 수 없는 인증서이다. 예를 들어 TLS/SSL 서버 및 클라이언트 인증서, 이메일 인증서, 코드 서명 인증서, 적격 인증서는 모두 종단 엔터티 인증서이다.

2. 5. 주체 대체 이름(SAN) 인증서

전송 계층 보안(TLS) 프로토콜(및 이전 버전인 보안 소켓 계층(SSL))에서 서버는 디지털 인증서를 제시하여 자신이 의도된 대상임을 증명해야 한다. 이때 인증서의 주체(Subject) 필드는 서버의 기본 호스트 이름을 일반 이름(Common Name)으로 식별해야 한다.[3] 하나의 인증서는 여러 호스트 이름(예: 도메인 및 하위 도메인)에 대해 유효할 수 있는데, 이러한 인증서를 일반적으로 주체 대체 이름(SAN) 인증서 또는 통합 통신 인증서(UCC)라고 한다. SAN 인증서는 주체 대체 이름 필드를 포함하며, 많은 인증 기관(CA)은 이전 버전과의 호환성을 위해 이를 주체 일반 이름 필드에도 넣는다. 일부 호스트 이름에 별표(*)가 포함된 경우 해당 인증서를 와일드카드 인증서라고 부르기도 한다.

주체 대체 이름(SAN) 인증서는 `subjectAltName` 필드를 사용하여 보안 인증서와 다양한 값을 연결할 수 있도록 하는 X.509의 확장이다.[5] 이러한 값을 "Subject Alternative Names"(SAN)이라고 하며, 여기에는 다음이 포함된다.[6]

  • 이메일 주소
  • IP 주소
  • URI
  • DNS 이름: 이는 일반적으로 주 인증서의 Subject 필드 내 RDN인 Common Name으로도 제공된다.
  • 디렉토리 이름: Subject에 주어진 것과 다른 Distinguished Names.
  • 기타 이름: ''General Name'' 또는 ''Universal Principal Name''으로 지정되며, 등록된 객체 식별자와 그 뒤에 오는 값으로 구성된다.


(2000년 5월)은 Subject Alternative Names를 인증서에 DNS 이름을 추가하는 선호하는 방법으로 명시하고, `commonName` 필드에 DNS 이름을 넣는 이전 방법을 사용하지 않도록 했다.[7] 구글 크롬 버전 58(2017년 3월)에서는 `commonName` 필드 검사에 대한 지원을 완전히 제거하고 대신 SAN만 확인한다.[7]

위키미디어 섹션 사진에서 볼 수 있듯이, SAN 필드는 와일드카드를 포함할 수 있다.[8] 모든 공급업체가 SAN 인증서에 와일드카드를 혼합하는 것을 지원하거나 권장하지는 않는다.[9]

2. 6. 와일드카드 인증서

와일드카드 인증서는 하나의 인증서로 특정 도메인의 모든 서브도메인을 보호할 수 있도록 하는 인증서이다. 예를 들어, `https://*.example.com`에 대한 단일 와일드카드 인증서는 `payment.example.com`, `contact.example.com`, `login-secure.example.com`, `www.example.com` 등 `*.example.com` 도메인의 모든 서브도메인을 보호한다.[10]

이러한 와일드카드 인증서는 전송 계층 보안(TLS) 프로토콜 및 이전 버전인 보안 소켓 계층(SSL) 프로토콜에서 클라이언트와 서버 간의 통신을 안전하게 보장하는 데 사용된다. 클라이언트는 서버가 제시한 인증서의 주체(Subject)가 연결하려는 호스트 이름과 일치하고, 신뢰할 수 있는 인증 기관이 서명했는지 확인하는 인증 경로 유효성 검사를 수행한다.[3]

서브도메인에 대한 개별 인증서를 받는 대신, 모든 주요 도메인과 서브도메인에 대해 단일 인증서를 사용하여 비용을 절감할 수 있다.[10] 와일드카드는 다중 도메인 인증서 또는 통합 통신 인증서(UCC)의 도메인으로 추가될 수 있다. 또한 와일드카드 자체는 다른 와일드카드를 포함하여 `subjectAltName` 확장을 가질 수 있다. 예를 들어, 와일드카드 인증서 `*.wikipedia.org`는 `*.m.wikimedia.org`를 주체 대체 이름으로 가지므로, `www.wikipedia.org`와 `meta.m.wikimedia.org`를 모두 보호한다.[17]

하지만 와일드카드는 한 단계의 서브도메인만 포함하기 때문에(별표는 마침표와 일치하지 않음),[11] `test.login.example.com`이나 `example.com`과 같은 도메인은 해당 인증서에 유효하지 않다.[12]

2. 6. 1. 와일드카드 인증서의 한계

도메인 이름의 일부에 별표(와일드카드)를 사용하는 공개 키 인증서를 와일드카드 인증서라고 한다. 와일드카드 인증서를 사용하면 단일 인증서로 여러 개의 서브도메인을 사용할 수 있어 편리하지만, 보안상의 이유로 사용에 제약이 있을 수 있다.

와일드카드는 한 단계의 서브도메인에만 적용된다. 예를 들어, `*.example.com`은 `sub1.example.com`과는 일치하지만, `example.com`과 `sub2.sub1.domain.com`과는 일치하지 않는다.[18]

또한, 다음과 같은 제약 사항이 있다.[24]

  • 이름에 여러 개의 와일드카드가 있는 인증서는 허용되지 않는다. (예: `*.*.domain.com`)
  • `*`과 최상위 도메인이 있는 인증서는 허용되지 않는다. (예: `*.com`)
  • 너무 일반적인 와일드카드 (예: `*`)는 허용되지 않는다.
  • ASCII로 인코딩되고 `xn--`으로 시작하는 A-label로 인코딩된 국제 도메인 이름에는 와일드카드를 포함할 수 없다.


확장 유효성 검사 인증서에는 와일드카드를 사용할 수 없다.[14]

2. 7. 기타 인증서

EMV는 결제 카드, 결제 단말기, 현금 자동 입출금기(ATM)에 대한 기술 표준을 기반으로 하는 결제 방식이다. EMV 결제 카드에는 EMV 인증 기관[25]이 서명한 카드 발급자 인증서가 미리 로드되어 결제 거래 시 결제 카드의 진위 여부를 확인한다. 코드 서명 인증서는 컴퓨터 프로그램의 유효성을 검사하여 전달 과정에서 변조되지 않았는지 확인할 수 있다. ''X.509 연방 브리지 인증 기관(FBCA)의 인증 정책''에 정의된 역할 기반 인증서는 "가입자의 이름이 아닌 가입자가 대신 행동할 권한이 있는 특정 역할을 식별하며, 허용된 비즈니스 관행을 지원하기 위해 발급"[26]되며, 그룹 인증서는 "여러 엔티티가 하나의 자격으로 행동하고 거래에 대한 부인이 필요하지 않은 경우"에 사용된다.[27]

2. 7. 1. 적격 인증서 (Qualified Certificate)

유럽 연합에서는 법적 문서에 대한 (고급) 전자 서명을 디지털 서명을 사용하여 수행하며, 이때 신원 증명서가 함께 제공된다. 적격 전자 서명 (적격 신뢰 서비스 제공자 및 서명 생성 장치를 사용해야 함)만이 실제 서명과 동일한 법적 효력을 가진다.[1]

3. 인증서의 일반적인 필드


  • '''일련 번호''': CA의 시스템 내에서 인증서를 고유하게 식별하는 데 사용되며, 특히 해지 정보를 추적하는 데 사용된다.
  • '''주체''': 인증서가 속한 개체(컴퓨터, 개인 또는 조직)를 나타낸다.
  • '''발급자''': 정보를 확인하고 인증서에 서명한 개체를 나타낸다.
  • '''유효 시작일''': 인증서가 유효한 가장 빠른 시간 및 날짜이다. 일반적으로 시계 오차 문제를 피하기 위해 인증서가 발급된 순간보다 몇 시간 또는 며칠 전으로 설정된다.
  • '''유효 종료일''': 인증서가 더 이상 유효하지 않은 시간 및 날짜이다.
  • '''키 사용법''': 인증서의 공개 키의 유효한 암호화 사용법을 나타낸다. 일반적인 값에는 디지털 서명 유효성 검사, 키 암호화, 인증서 서명이 포함된다.
  • '''확장 키 사용법''': 인증서를 사용할 수 있는 응용 프로그램을 나타낸다. 일반적인 값에는 TLS 서버 인증, 이메일 보호, 코드 서명이 포함된다.
  • '''공개 키''': 인증서 주체에 속하는 공개 키이다.
  • '''서명 알고리즘''': 이 필드에는 해싱 알고리즘과 디지털 서명 알고리즘이 포함된다. 예를 들어 "sha256RSA"는 sha256이 해싱 알고리즘이고 RSA가 서명 알고리즘임을 의미한다.
  • '''서명''': 인증서의 본문은 해시되고("서명 알고리즘" 필드의 해싱 알고리즘이 사용됨) 그 다음 해시는 발급자의 개인 키로 서명된다("서명 알고리즘" 필드의 서명 알고리즘이 사용됨).


SSL.com 웹사이트에서 검색된 디코딩된 SSL/TLS 인증서의 예시는 다음과 같다. 발급자의 일반 이름(CN)은 `SSL.com EV SSL Intermediate CA RSA R3`로 표시되어 있으며, 이는 이 인증서가 확장 유효성(EV) 인증서임을 나타낸다. 웹사이트 소유자(SSL Corp)에 대한 유효한 정보는 `Subject` 필드에 있다. `X509v3 Subject Alternative Name` 필드에는 인증서에서 다루는 도메인 이름 목록이 포함되어 있다. `X509v3 Extended Key Usage` 및 `X509v3 Key Usage` 필드는 모든 적절한 사용법을 보여준다.

4. 인증 기관(CA)

공개 키 인증서를 얻는 절차


X.509 신뢰 모델에서 인증 기관(CA)은 인증서 서명을 담당한다. 이러한 인증서는 두 당사자 간의 소개 역할을 하며, CA는 신뢰할 수 있는 제3자 역할을 한다는 것을 의미한다.[28] CA는 인증서를 요청하는 개인 또는 조직(가입자라고 함)의 요청을 처리하고, 정보를 확인한 다음, 해당 정보를 기반으로 최종 엔터티 인증서에 서명할 수 있다. 이 역할을 효과적으로 수행하기 위해 CA는 하나 이상의 널리 신뢰받는 루트 인증서 또는 중간 인증서와 해당 개인 키를 가지고 있어야 한다. CA는 널리 사용되는 소프트웨어에 루트 인증서를 포함시키거나, 신뢰를 위임하는 다른 CA로부터 교차 서명을 획득하여 이러한 광범위한 신뢰를 얻을 수 있다. 다른 CA는 기업과 같은 비교적 작은 커뮤니티 내에서 신뢰를 받으며, 윈도우 그룹 정책과 같은 다른 메커니즘을 통해 배포된다.

인증 기관은 또한 발급한 인증서에 대한 최신 해지 정보를 유지 관리하여 인증서가 여전히 유효한지 여부를 나타낼 책임이 있다. 인증 기관은 온라인 인증서 상태 프로토콜 (OCSP) 및/또는 인증서 해지 목록 (CRL)을 통해 이 정보를 제공한다.

시장에 있는 더 큰 인증 기관 중 일부는 아이덴트러스트(IdenTrust), 디지서트(DigiCert), 섹티고(Sectigo)가 있다.[28]

가장 일반적인 인증서의 사용은 HTTPS 기반 웹사이트에 적용된다. 웹 브라우저는 HTTPS 웹 서버가 진본임을 검증하여 사용자가 웹사이트와의 상호 작용에 도청자가 없으며 웹사이트가 자신이 주장하는 존재임을 확신할 수 있도록 한다. 이러한 보안은 전자 상거래에 중요하다. 실제로 웹사이트 운영자는 인증서 서명 요청을 통해 인증 기관에 신청하여 인증서를 획득한다. 인증서 요청은 웹사이트 이름, 회사 정보 및 공개 키를 포함하는 전자 문서이다. 인증서 제공자는 요청에 서명하여 공개 인증서를 생성한다. 웹 브라우징 중 이 공개 인증서는 웹사이트에 연결하는 모든 웹 브라우저에 제공되며 제공자가 웹사이트 소유자에게 인증서를 발급했다고 믿는다는 것을 웹 브라우저에 증명한다.

예를 들어 사용자가 브라우저를 사용하여 `https://www.example.com/`에 연결할 때 브라우저가 인증서 경고 메시지를 표시하지 않으면 사용자는 `https://www.example.com/`와의 상호 작용이 "example.com"의 공개 등록부에 나열된 이메일 주소와 연락하는 엔티티와의 상호 작용과 동일하다고 이론적으로 확신할 수 있다. 비록 해당 이메일 주소가 웹사이트 어디에도 표시되지 않을 수 있더라도 말이다. 어떠한 종류의 다른 보증도 함축되지 않는다. 또한, 인증서 구매자, 웹사이트 운영자 및 웹사이트 콘텐츠 생성자 간의 관계는 불안정할 수 있으며 보장되지 않는다. 기껏해야, 인증서는 웹사이트 자체가 손상(해킹)되지 않았거나 인증서 발급 프로세스가 전복되지 않은 경우 웹사이트의 고유성을 보장한다.

인증서 제공자는 각각 자체적인 검증 엄격성을 요구하는 세 가지 유형의 인증서를 발급하도록 선택할 수 있다. 엄격성이 증가하는 순서(그리고 당연히 비용도 증가)대로 도메인 검증, 조직 검증 및 확장 검증이 있다. 이러한 엄격성은 CA/브라우저 포럼의 자발적 참여자들에 의해 대략적으로 합의되었다.

과거에는 브라우저 호환성 문제로 인해 필요한 만큼의 고정 IP 주소를 사용해야 했고, 인증 기관(CA)이 발급하는 인증서는 1년 유효에 3만 엔 정도여서 도입 비용이 비쌌지만, 최근 렌탈 서버 사업자가 SNI SSL에 대응하거나, 대형 CA가 발급하는 인증서도 1천 엔 정도로 매우 저렴하게 발급할 수 있게 되었다. 또한, 무료로 인증서를 취득할 수 있는 서비스(Let's Encrypt)도 있어, 도입 비용이 낮아지고 있다.

5. 루트 프로그램

주요 소프트웨어는 기본적으로 신뢰할 수 있는 인증 기관 목록을 포함하고 있다.[28] 이는 최종 사용자가 인증서를 검증하는 것을 더 쉽게 만들고, 인증서를 요청하는 개인이나 조직이 광범위하게 신뢰받는 인증서를 발급할 수 있는 인증 기관을 알 수 있도록 한다. 특히 웹 사이트 운영자가 일반적으로 웹 사이트 방문자 거의 모두에게 신뢰받는 인증서를 얻고 싶어하는 HTTPS에서 중요하다.

제공자가 소프트웨어에서 신뢰해야 할 인증 기관을 결정하기 위해 사용하는 정책과 프로세스를 루트 프로그램이라고 한다. 가장 영향력 있는 루트 프로그램은 다음과 같다.



파이어폭스를 제외한 브라우저는 일반적으로 운영 체제의 기능을 사용하여 신뢰할 인증 기관을 결정한다. 예를 들어, 윈도우의 크롬은 마이크로소프트 루트 프로그램에 포함된 인증 기관을 신뢰하는 반면, macOS 또는 iOS의 크롬은 애플 루트 프로그램의 인증 기관을 신뢰한다.[29] 엣지 및 사파리도 각 운영 체제 신뢰 저장소를 사용하지만, 각각 단일 OS에서만 사용할 수 있다. 파이어폭스는 모든 플랫폼에서 모질라 루트 프로그램 신뢰 저장소를 사용한다.

모질라 루트 프로그램은 공개적으로 운영되며, 인증서 목록은 오픈 소스 파이어폭스 웹 브라우저의 일부이므로 파이어폭스 외부에서도 광범위하게 사용된다. 예를 들어, 일반적인 리눅스 루트 프로그램은 없지만, 데비안[30]과 같은 많은 리눅스 배포판은 파이어폭스 신뢰 목록의 내용을 주기적으로 복사하는 패키지를 포함하며, 이 패키지는 애플리케이션에서 사용된다.

루트 프로그램은 일반적으로 포함된 인증서와 함께 일련의 유효한 용도를 제공한다. 예를 들어, 일부 CA는 TLS 서버 인증서 발급에는 신뢰할 수 있지만, 코드 서명 인증서에는 신뢰할 수 없는 것으로 간주될 수 있다. 이는 루트 인증서 저장 시스템의 일련의 신뢰 비트로 표시된다.

6. 인증서 폐지

인증서는 만료되기 전에 폐지될 수 있으며, 이는 더 이상 유효하지 않음을 뜻한다. 폐지가 없으면 공격자는 만료될 때까지 손상되거나 잘못 발급된 인증서를 악용할 수 있다.[28] 따라서 폐지는 공개 키 기반 구조의 중요한 부분이다. 폐지는 인증서를 발급한 인증 기관에서 수행하며, 폐지에 대한 암호화 인증된 성명을 생성한다.

폐지 정보를 클라이언트에 배포하기 위해서는 폐지 발견의 적시성(공격자가 손상된 인증서를 악용할 수 있는 기간)과 폐지 상태를 쿼리하는 데 드는 리소스 사용량 및 개인 정보 보호 문제가 서로 상충된다. 폐지 정보를 사용할 수 없는 경우(사고 또는 공격으로 인해), 클라이언트는 '강력하게 실패'하여 인증서를 폐지된 것으로 처리하거나(이 경우 가용성 저하), '약하게 실패'하여 폐지되지 않은 것으로 처리하여 공격자가 폐지를 우회하도록 허용할지를 결정해야 한다.

폐지 확인 비용과 잠재적으로 신뢰할 수 없는 원격 서비스로 인한 가용성 영향 때문에, 웹 브라우저는 수행할 폐지 확인을 제한하며, 수행하는 경우 약하게 실패한다. 인증서 폐지 목록은 일상적인 사용에 너무 많은 대역폭을 소비하며, 온라인 인증서 상태 프로토콜은 연결 대기 시간 및 개인 정보 보호 문제를 야기한다. 다른 계획들이 제안되었지만, 강력한 확인을 활성화하기 위해 아직 성공적으로 배포되지 않았다. 비밀 키[43]의 신뢰성이 없어지거나, 인증서에 내장된 공개 키와 소유자 정보의 관계가 변경(개명이나 이직 등)되거나, 잘못된 사실이 발각되었을 경우, 인증서가 실효될 수 있다. 실효는 극히 드문 현상이지만, 인증서의 실효 가능성은 인증서를 신뢰할 때 사용자가 항상 그 정당성을 확인해야(할 수 있어야) 한다는 것을 의미한다. 이는 전자 인증서 실효 목록(CRL)과 비교함으로써 가능하다. CRL이 확실하게 최신이며 정확하도록 하는 것은 집중적인 PKI의 핵심 기능에 의해 이루어지며, 여기에는 인력과 예산이 모두 필요하기 때문에 때로는 적절하게 수행되지 않을 수도 있다. 이 기능을 유효하게 하기 위해서는 필요할 때마다 언제든지 누구나 즉시 이용할 수 있으며, 빈번하게 업데이트되어야 한다. 인증서의 정당성을 확인하는 또 다른 방법으로, OCSP(온라인 인증서 상태 프로토콜)를 사용하여 인증서의 상태를 인증 기관에 문의하는 방법이 있다.

7. 웹사이트 보안

HTTPS 기반 웹사이트는 공개 키 인증서를 사용하여 사용자와 웹사이트 간의 통신을 보호한다. 웹 브라우저는 HTTPS 웹 서버가 진본임을 검증하여 사용자가 웹사이트와의 상호 작용에 도청자가 없으며 웹사이트가 자신이 주장하는 존재임을 확신할 수 있도록 돕는다. 이러한 보안은 전자 상거래에 특히 중요하다.[3]

웹사이트 운영자는 인증서 서명 요청을 통해 인증 기관에 인증서를 신청한다. 인증서 요청은 웹사이트 이름, 회사 정보 및 공개 키를 포함하는 전자 문서이다. 인증 기관은 이 요청에 서명하여 공개 인증서를 생성한다. 웹 브라우징 중에 이 공개 인증서는 웹사이트에 연결하는 모든 웹 브라우저에 제공되며, 인증 기관이 웹사이트 소유자에게 인증서를 발급했음을 증명한다.

사용자가 `https://www.example.com/`에 연결할 때 브라우저가 인증서 경고 메시지를 표시하지 않으면, 사용자는 `https://www.example.com/`과의 상호 작용이 "example.com"의 공개 등록부에 나열된 이메일 주소와 연락하는 엔티티와의 상호 작용과 동일하다고 이론적으로 확신할 수 있다. 그러나 해당 이메일 주소가 웹사이트에 표시되지 않을 수 있으며, 인증서 구매자, 웹사이트 운영자 및 웹사이트 콘텐츠 생성자 간의 관계는 불안정하며 보장되지 않는다. 인증서는 웹사이트 자체가 손상(해킹)되지 않았거나 인증서 발급 프로세스가 전복되지 않은 경우에만 웹사이트의 고유성을 보장한다.

전송 계층 보안(TLS) 프로토콜(및 이전 버전인 보안 소켓 계층(SSL) 프로토콜)을 통해 클라이언트와 서버 간의 통신을 안전하게 보장하기 위해, 서버는 디지털 인증서를 제시하여 자신이 의도된 대상임을 증명해야 한다. 이때 클라이언트는 인증 경로 유효성 검사를 수행하여 인증서의 주체(Subject)가 연결하려는 호스트 이름과 일치하고, 신뢰할 수 있는 인증 기관이 인증서에 서명했는지 확인한다.[3] 인증서의 ''주체(Subject)'' 필드는 서버의 기본 호스트 이름을 ''일반 이름(Common Name)''으로 식별해야 한다. 호스트 이름은 사설 IP 주소나 예약된 도메인을 사용하지 않고 공개적으로 접근 가능해야 한다. 하나의 인증서는 여러 호스트 이름(예: 도메인 및 하위 도메인)에 대해 유효할 수 있는데, 이러한 인증서를 ''주체 대체 이름(SAN) 인증서'' 또는 ''통합 통신 인증서(UCC)''라고 한다. 이러한 인증서는 주체 대체 이름 필드를 포함하지만, 많은 CA(인증 기관)는 이전 버전과의 호환성을 위해 이를 ''주체 일반 이름'' 필드에도 넣는다. 일부 호스트 이름에 별표(*)가 포함된 경우 해당 인증서를 와일드카드 인증서라고 부르기도 한다.

7. 1. 인증 수준

인증서는 검증 수준에 따라 도메인 검증(DV), 조직 검증(OV), 확장 검증(EV) 인증서로 나뉜다. 이러한 엄격성은 CA/브라우저 포럼의 자발적 참여자들에 의해 대략적으로 합의되었다.

HTTPS 기반 웹사이트에서 웹 브라우저는 HTTPS 웹 서버가 진본임을 검증하여 사용자가 웹사이트와의 상호 작용에 도청자가 없으며 웹사이트가 자신이 주장하는 존재임을 확신할 수 있도록 한다. 이러한 보안은 전자 상거래에 중요하다. 웹사이트 운영자는 인증서 서명 요청을 통해 인증 기관에 신청하여 인증서를 획득하며, 인증서 제공자는 요청에 서명하여 공개 인증서를 생성한다.

공개 키 인증서가 위조되지 않도록 디지털 서명이 사용된다. 공개 키 기반(PKI) 체계에서는 인증 기관(CA)이 이 서명을 수행한다. 신뢰의 고리 체계에서는 자신(자기 서명 인증서) 또는 다른 사용자가 서명을 수행한다.

과거에는 브라우저 호환성 문제로 인해 필요한 만큼의 고정 IP 주소를 사용해야 했고, 인증 기관(CA)이 발급하는 인증서는 1년 유효 기간에 3만 엔 정도여서 도입 비용이 비쌌다. 그러나 최근 렌탈 서버 사업자가 SNI SSL에 대응하거나, 대형 CA가 발급하는 인증서도 1천 엔 정도로 매우 저렴하게 발급할 수 있게 되었다. 또한, 무료로 인증서를 취득할 수 있는 서비스(Let's Encrypt)도 있어, 도입 비용이 낮아지고 있다.

7. 1. 1. 도메인 검증 (DV)

전송 계층 보안(TLS) 프로토콜(및 이전 버전인 보안 소켓 계층(SSL) 프로토콜)을 통해 클라이언트와 서버 간의 통신을 안전하게 보장하기 위해 서버는 디지털 인증서를 제시하여 자신이 의도된 대상임을 증명해야 한다. 이때 클라이언트는 인증 경로 유효성 검사를 수행하여 인증서의 주체(Subject)가 연결하려는 호스트 이름과 일치하고, 신뢰할 수 있는 인증 기관이 인증서에 서명했는지 확인한다.

인증서 제공자는 구매자가 DNS 도메인(들)을 관리할 권한이 있음을 입증할 수 있는 경우 도메인 유효성 검사(DV) 인증서를 발급한다.[3] DV 인증서는 도메인 소유권만 확인하는 가장 기본적인 인증서이다.

7. 1. 2. 조직 검증 (OV)

인증서 제공자는 구매자가 다음 두 가지 기준을 충족할 경우 조직 유효성 검사(OV) 클래스 인증서를 발급한다.

  • 도메인 이름을 관리할 행정 권한
  • 법적 실체로서의 조직의 실존 여부


인증서 제공자는 인증서 정책을 통해 OV 심사 기준을 공개한다.

EV 인증서(후술)처럼 주소 표시줄이 녹색으로 표시되지는 않지만, 증명서에 법인명이 기재되어 있다.[3]

7. 1. 3. 확장 검증 (EV)

확장 유효성 검사(EV) 인증서를 얻으려면, 구매자는 인증서 제공업체에 법적 신원을 증명해야 하며, 여기에는 사람이 직접 수행하는 수동 검증 확인이 포함된다.[31][32] OV 인증서와 마찬가지로, 인증서 제공업체는 인증 정책을 통해 EV 심사 기준을 공개한다.

2019년까지, 크롬(Chrome)과 파이어폭스(Firefox)와 같은 주요 브라우저는 일반적으로 사이트가 EV 인증서를 제시할 때 사용자에게 법적 신원에 대한 시각적 표시를 제공했다. 이는 도메인 앞에 법적 이름을 표시하고 변경 사항을 강조하기 위해 밝은 녹색을 사용하는 방식으로 이루어졌다. 대부분의 브라우저는 이 기능을 사용 중단하여, 사용자에게 사용된 인증서 유형에 대한 시각적 차이를 제공하지 않았다. 이러한 변화는 법의학 전문가가 제기한 보안 우려와 유명 단체를 사칭하기 위해 EV 인증서를 구매하려는 성공적인 시도에 따른 것으로, 이러한 시각적 지표의 비효율성을 입증하고 잠재적인 악용 가능성을 강조했다.[33]

7. 2. 웹사이트 보안의 약점

전송 계층 보안(TLS) 프로토콜과 보안 소켓 계층(SSL) 프로토콜은 클라이언트와 서버 간의 안전한 통신을 보장한다. 이 프로토콜은 서버가 디지털 인증서를 제시하여 자신이 의도된 대상임을 증명하도록 요구한다. 연결하는 클라이언트는 인증 경로 유효성 검사를 수행하여 인증서의 주체(Subject)가 클라이언트가 연결하려는 호스트 이름과 일치하고, 신뢰할 수 있는 인증 기관이 인증서에 서명했는지 확인한다.

공개 웹 서버는 신뢰할 수 있는 공개 인증 기관(CA)으로부터 인증서를 받아야 한다. 가장 일반적인 인증서 사용은 HTTPS 기반 웹사이트에 적용된다. 웹 브라우저는 HTTPS 웹 서버가 진본임을 검증하여 사용자가 웹사이트와의 상호 작용에 도청자가 없으며 웹사이트가 자신이 주장하는 존재임을 확신할 수 있도록 한다. 이러한 보안은 전자 상거래에 중요하다.

하지만 이러한 공개키 인증서 시스템은 몇 가지 약점을 가지고 있다.

  • 웹 브라우저는 웹 사이트가 갑자기 다른 인증서를 제시할 경우 (해당 인증서의 키 비트 수가 더 적거나, 다른 제공업체가 있거나, 이전 인증서의 만료일이 훨씬 미래인 경우에도) 사용자에게 경고하지 않는다.
  • 인증서 제공업체가 정부의 관할 하에 있는 경우, 해당 정부는 법 집행 목적으로 인증서를 생성하도록 제공업체에 명령할 수 있다.
  • 모든 웹 브라우저에는 신뢰할 수 있는 루트 인증서의 광범위한 내장 목록이 포함되어 있으며, 그 중 상당수는 사용자에게 익숙하지 않은 조직에서 관리한다.[34] 이러한 각 조직은 모든 웹 사이트에 대해 모든 인증서를 발급할 수 있다.
  • 흔하지는 않지만, 사기 인증서가 발급된 사례가 있었다.[35][36]
  • 사용자(및 어느 정도 애플리케이션)는 회사 인트라넷과 같은 특수한 목적으로 인증서 목록을 자유롭게 확장할 수 있다.[37] 즉, 누군가 기기에 접근하여 브라우저에 새로운 루트 인증서를 설치할 수 있다면, 해당 브라우저는 삽입된 인증서를 사용하는 웹사이트를 합법적인 것으로 인식하게 된다.


증명 가능한 보안의 경우, 시스템 외부의 무언가에 의존한다는 것은 모든 공개 키 인증 방식이 인증 기관의 존재와 같은 특별한 설정 가정을 기반으로 해야 한다는 결과를 낳는다.[38]

위에서 설명한 제한 사항에도 불구하고, 웹 사이트가 기밀 정보를 호스팅하거나 중요한 거래를 수행할 때는 모든 보안 지침에서 인증서 인증 TLS를 의무적으로 간주한다. 이는 공개 키 인증서로 보호되는 웹 사이트가 보호되지 않은 HTTP 웹 사이트보다 여전히 안전하기 때문이다.[39]

8. 표준

공개 키 인증서의 가장 일반적인 표준은 X.509이다. ITU-T X.509 표준을 따르며, 인터넷에서 X.509를 사용하기 위한 표준은 2013년 10월 말에 해산된 IETF의 PKIX 워킹 그룹이 제정 작업을 진행했다.

X.509 인증서는 다음 정보를 포함한다.[40][41][42]

항목설명
일련 번호인증서를 개별 식별할 때 사용
소유자사람의 이름이나 증명자
서명 알고리즘서명을 만드는 데 쓰이는 알고리즘
발행자정보를 검증하고 인증서를 발행하는 실체
유효 기간 (시작)처음 효력을 발휘하는 기간
유효 기간 (끝)효력 만기일
키 사용 목적공인 키의 사용 목적 (예: 서명, 인증 서명 등)
공인 키SSL 목적
서명 알고리즘인증서를 서명하는 데 쓰이는 알고리즘
서명



NIST 컴퓨터 보안 부서는 공개 키 인증서에 대한 지침 문서를 제공한다.

참조

[1] 논문 SecureGuard: A Certificate Validation System in Public Key Infrastructure https://ieeexplore.i[...] 2022-08-26
[2] 논문 Evaluating Trust in a Public Key Certification Authority https://www.scienced[...] 2022-02-26
[3] 웹사이트 Internal names https://docs.digicer[...] DigiCert Documentation
[4] 웹사이트 Free SSL Certificate https://www.ionos.co[...] 2022-07-15
[5] 웹사이트 x509v3_config - X509 V3 certificate extension configuration format https://www.openssl.[...] OpenSSL 2020-01-16
[6] 간행물 "IETF RFC 5280: 4.2.1.6. Subject Alternative Name"
[7] 웹사이트 Deprecations and Removals in Chrome 58 https://developers.g[...] Google Inc. 2022-01-04
[8] 웹사이트 Common Name (CN) for a wildcard certificate https://docs.digicer[...] DigiCert Documentation
[9] 웹사이트 Wildcard and SAN: Understanding Multi-Use SSL Certificates https://www.thawte.c[...] Thawte 2013
[10] 웹사이트 Wildcard Certificate Explained in Simpler Terms http://searchsecurit[...] 2016-05-23
[11] 웹사이트 RFC 2818 - HTTP Over TLS http://tools.ietf.or[...] Internet Engineering Task Force 2014-12-15
[12] IETF RFC 2595 - Using TLS with IMAP, POP3 and ACAP https://tools.ietf.o[...] Internet Engineering Task Force 2014-12-15
[13] 웹사이트 Wildcard SSL certificate limitation on QuovadisGlobal.com https://support.quov[...]
[14] 웹사이트 Guidelines For The Issuance And Management Of Extended Validation Certificates, Version 1.5.2 https://cabforum.org[...] CA/Browser Forum 2014-12-15
[15] 웹사이트 x509v3_config Subject Alternative Name https://www.openssl.[...]
[16] 웹사이트 The SAN option is available for EV SSL Certificates on Symantec.com https://web.archive.[...]
[17] 웹사이트 "SSLTools Certificate Lookup of Wikipedia.org's wildcard ssl certificate" http://www.ssltools.[...]
[18] IETF RFC 6125 - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) https://tools.ietf.o[...] Internet Engineering Task Force 2014-12-10
[19] IETF RFC 2818 - HTTP Over TLS https://tools.ietf.o[...] 2019-04-20
[20] IETF RFC 6125 - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) https://tools.ietf.o[...] 2019-04-20
[21] 웹사이트 Disallow support for a*.example.net, *a.example.net, and a*b.example.net in certificate wildcard handling https://codereview.c[...] The Chromium Projects, Google Inc. 2020-10-21
[22] 웹사이트 Limit wildcard DNS ID support to names of the form *.example.com (not foo*.example.com) https://bugzilla.moz[...] The Mozilla Foundation 2020-10-21
[23] 웹사이트 Disallow support for a*.example.net, *a.example.net, and a*b.example.net in certificate wildcard handling https://bugs.python.[...] The Python Software Foundation 2020-10-21
[24] 웹사이트 Restrictions on data entries for public certificates https://docs.digicer[...] DigiCert Documentation
[25] 웹사이트 EMV CA https://emvca.com/in[...] EMV Certificate Authority Worldwide 2020-01-20
[26] 웹사이트 X.509 Certificate Policy For The Federal Bridge Certification Authority (FBCA) https://www.idmanage[...] 2021-05-07
[27] 웹사이트 X.509 Certificate Policy For The Federal Bridge Certification Authority (FBCA) https://www.idmanage[...] 2021-05-07
[28] 웹사이트 Usage Statistics and Market Share of SSL Certificate Authorities for Websites, May 2020 https://w3techs.com/[...] 2020-05-01
[29] 웹사이트 Root Certificate Policy – The Chromium Projects https://www.chromium[...] 2017-03-19
[30] 웹사이트 ca-certificates in Launchpad https://launchpad.ne[...] 2017-03-19
[31] 웹사이트 Firefox-dev Google group - Intent to Ship: Move Extended Validation Information out of the URL bar https://groups.googl[...] 2020-08-03
[32] 웹사이트 Chrome Security-dev Google group - Upcoming Change to Chrome's Identity Indicators https://groups.googl[...] 2020-08-03
[33] 웹사이트 Extended Validation Certificates are (Really, Really) Dead https://www.troyhunt[...] 2020-08-03
[34] 웹사이트 List of certificates included by Mozilla https://www.mozilla.[...] Mozilla.org 2012-07-30
[35] 웹사이트 DigiNotar removal by Mozilla https://blog.mozilla[...] Mozilla.org 2012-07-30
[36] 웹사이트 DigitNotar removal by Google http://googleonlines[...] 2012-07-30
[37] 웹사이트 Using certificates article at Mozilla.org https://www.mozilla.[...] Mozilla.org 2012-07-30
[38] 간행물 Universally Composable Signature, Certification, and Authentication. CSFW 2004 http://eprint.iacr.o[...] 2009-08-28
[39] 논문 Replacing passwords on the Internet AKA post-Snowden Opportunistic Encryption https://www.w3.org/2[...] 2014-01-18
[40] 웹사이트 NIST Computer Security Publications – NIST Special Publications (SPs) http://csrc.nist.gov[...] 2016-06-19
[41] 웹사이트 SP 800-32 Introduction to Public Key Technology and the Federal PKI Infrastructure http://nvlpubs.nist.[...] National Institute of Standards and Technology 2016-06-19
[42] 웹사이트 SP 800-25 Federal Agency Use of Public Key Technology for Digital Signatures and Authentication http://nvlpubs.nist.[...] National Institute of Standards and Technology 2016-06-19
[43] 문서 ここで秘密鍵とは、対称鍵のことではなく、公開鍵に対する私有鍵のこと。
[44] 웹사이트 Public-Key Infrastructure (X.509) (pkix) - History http://datatracker.i[...] 2014-03-07


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com