공용 키 인증서

Public key certificate
"ID 인증서"는 여기서 리디렉션다른 용도는 ID 인증서(동음이의)를 참조하십시오.
Let's Encryption에서 발급한 *.comifuro.net의 공용 키 인증서

암호학에서, 디지털 인증서 또는 신원 인증서로도 알려진 공개 키 인증서는 공개 키의 유효성을 증명하기 위해 사용되는 전자 문서다.[1]인증서는 키에 관한 정보, 소유자의 신원에 관한 정보(주체라고 부름), 인증서의 내용을 검증한 법인(발급자로 부름)의 디지털 서명이 포함되어 있다.서명이 유효하고 인증서를 검사하는 소프트웨어가 발급자를 신뢰하는 경우, 인증서의 제목과 안전하게 통신하기 위해 이 키를 사용할 수 있다.전자 메일 암호화, 코드 서명 및 전자 서명 시스템에서 인증서의 주체는 일반적으로 개인 또는 조직이다.그러나 TLS(Transport Layer Security)에서 인증서의 주체는 일반적으로 컴퓨터 또는 기타 장치인데, TLS 인증서는 기기 식별에 있어 핵심 역할 외에 조직이나 개인을 식별할 수 있다.때로는 이전 이름인 SSL(Secure Sockets Layer)으로 불리기도 하는 TLS는 웹을 안전하게 탐색하기 위한 프로토콜인 HTTPS의 일부로 주목받는다.

일반적인 PKI(Public-Key Infrastructure) 체계에서 인증서 발급자는 인증기관(CA)으로,[2] 대개 고객에게 인증서 발급을 청구하는 기업이다.이와는 대조적으로, 신뢰의 거미줄에서는 개인이 공개키 인증서와 유사한 기능을 수행하는 형식으로 서로의 키를 직접 서명한다.

공용 키 인증서의 가장 일반적인 형식은 X.509에 의해 정의된다.[3]X.509는 매우 일반적이기 때문에, 형식은 에서 정의한 것과 같은 특정 사용 사례에 대해 정의된 프로파일에 의해 더욱 제약된다. RFC5280.

인증서 유형

신뢰 체인과 같은 루트 인증서, 중간 인증서 및 엔드엔티 인증서의 역할.

TLS/SSL 서버 인증서

TLS(Transport Layer Security) 프로토콜뿐만 아니라 오래된 이전 버전인 SSL(Secure Sockets Layer) 프로토콜도 클라이언트 컴퓨터와 서버 간의 통신을 안전하게 보호한다.프로토콜은 서버가 디지털 인증서를 제시하도록 요구하여, 그것이 의도된 목적지임을 증명한다.연결 클라이언트는 인증 경로 검증을 수행하여 다음을 보장한다.

  1. 인증서의 제목은 클라이언트가 연결하려고 하는 호스트 이름과 일치한다(도메인 이름과 혼동되지 않음).
  2. 신뢰할 수 있는 인증 기관이 인증서에 서명했다.

인증서의 제목 필드는 서버의 기본 호스트 이름을 공용 이름으로 식별해야 한다.인증서는 여러 호스트 이름(예: 도메인 및 해당 하위 도메인)에 대해 유효할 수 있다.이러한 인증서는 일반적으로 SAN(주체 대체 이름) 인증서 또는 UCC(Unified Communications Certificate)라고 불린다.이러한 인증서는 주체 대체 이름 필드를 포함하지만, 많은 CA는 이전 버전과의 호환성을 위해 주체 공통 이름 필드에 인증서를 넣기도 한다.호스트 이름 중 일부가 별표(*)를 포함하는 경우 인증서를 와일드카드 인증서라고도 할 수 있다.

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

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

TLS/SSL 클라이언트 인증서

클라이언트 인증서는 예를 들어 액세스 제어를 제공하기 위해 TLS 서비스에 연결하는 클라이언트를 인증한다.[4]대부분의 서비스는 디바이스가 아닌 개인에게 액세스를 제공하기 때문에 대부분의 클라이언트 인증서는 호스트 이름보다는 이메일 주소나 개인 이름을 포함하고 있다.또한 클라이언트 인증서를 발급하는 인증기관은 대개 인증을 수행해야 하는 제공자이기 때문에 클라이언트가 연결하는 서비스 제공업체다.

대부분의 웹 브라우저가 클라이언트 인증서를 지원하는 반면, 인터넷에서 가장 일반적인 인증 형식은 사용자 이름과 비밀번호 쌍이다.클라이언트 인증서는 디바이스를 인증하는 VPN(가상 사설망)과 원격 데스크톱 서비스에서 더 흔하다.

이메일 인증서

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

공개적으로 신뢰받는 일부 인증기관에서는 전자우편 인증서를 제공하지만, S/MIME은 특정 조직 내에서 통신할 때 더 일반적으로 사용되며, 해당 조직은 전자우편 시스템의 참여자들이 신뢰하는 자체 CA를 운영한다.

자체 서명 및 루트 인증서

주요 기사:루트 인증서 및 자체 서명된 인증서

자체 서명 인증서는 발급자와 일치하는 주체가 있는 인증서와 자체 공개 키로 확인할 수 있는 서명을 말한다.

대부분의 경우 이러한 자체 서명된 인증서는 가치가 없다.그러나 디지털 인증서 신뢰 체인은 "루트 인증서", "신뢰 앵커" 또는 "신뢰 루트"라고 불리는 자체 서명된 인증서로 시작한다.인증 기관은 루트 인증서에 자체 서명하여 다른 인증서에 서명할 수 있도록 한다.

중간 인증서는 루트 인증서와 유사한 목적을 가지고 있다. 다른 인증서에 서명하는 것만이 유일한 용도다.그러나 중간 인증서는 자체 서명되지 않는다.루트 인증서 또는 다른 중간 인증서에 서명해야 한다.엔드엔티 또는 리프 인증서는 다른 인증서에 서명할 수 없는 인증이다.예를 들어 TLS/SSL 서버 및 클라이언트 인증서, 전자 메일 인증서, 코드 서명 인증서 및 인증된 인증서는 모두 엔드엔티 인증서다.

기타 인증서

  • EMV 인증서: EMV는 결제 카드, 결제 단말기 및 현금 자동 입출금기(ATM)의 기술 표준에 근거한 결제 수단이며, EMV 결제 카드에는 EMV 인증 기관에서[5] 서명한 카드 발급사 인증서가 사전에 탑재되어 결제 거래 중 결제 카드의 신뢰성을 검증한다.
  • 코드 서명 인증서:인증서는 앱(또는 바이너리)을 검증하여 앱이 전송되는 동안 변조되지 않았는지 확인할 수 있다.
  • 정규화된 인증서:일반적으로 전자서명 목적으로 개인을 식별하는 인증서.이러한 것들은 유럽에서 가장 일반적으로 사용되는데, 여기서 eIDAS 규제는 이들을 표준화하고 인정을 필요로 한다.
  • 역할 기반 인증서:연방교량인증기관(FBCA)에 대한 X.509 인증서 정책에서 정의된 역할 기반 인증서는 "가입자의 이름보다는 가입자가 행동할 권한이 있고 승인된 사업 관행을 지원하기 위해 발급되는 특정 역할을 식별한다."[6]
  • 그룹 인증서:연방교량인증기관(FBCA)에 대한 X.509 인증서 정책에서 "한 가지 역량으로 작용하는 여러 실체가 있고, 거래에 대한 거부권을 원하지 않는 경우"[7]에 대해 정의된다.

공통 필드

참고 항목: X.509 § 인증서 구조

이것들은 인증서에서 가장 일반적인 필드들 중 하나이다.대부분의 인증서는 여기에 나열되지 않은 여러 필드를 포함한다.인증서의 X.509 표시 측면에서 인증서는 "평면"이 아니라 인증서 내의 다양한 구조에 중첩된 이러한 필드를 포함한다는 점에 유의하십시오.

  • 일련 번호:CA의 시스템 내에서 인증서를 고유하게 식별하는 데 사용된다.특히 이것은 취소 정보를 추적하는 데 사용된다.
  • 제목:인증서가 컴퓨터, 개인 또는 조직에 속한 엔터티.
  • 발급자: 정보를 확인하고 인증서에 서명한 기업.
  • 이전이 아님:인증서가 유효한 가장 빠른 시간 및 날짜.일반적으로 클럭 스큐 문제를 방지하기 위해 인증서를 발급한 시점 이전의 몇 시간 또는 며칠로 설정.
  • 다음 이후가 아님:인증서가 더 이상 유효하지 않은 시간 및 날짜.
  • 키 사용:인증서의 공용 키에 대한 유효한 암호화 사용.공통 값으로는 디지털 서명 검증, 키 암호화, 인증서 서명 등이 있다.
  • 확장 키 사용:인증서를 사용할 수 있는 응용 프로그램.공통 값으로는 TLS 서버 인증, 전자 메일 보호, 코드 서명 등이 있다.
  • 공용 키: 인증서 주체에 속하는 공용 키.
  • 서명 알고리즘:여기에는 해싱 알고리즘과 암호화 알고리즘이 포함된다.예를 들어 sha256은 해싱 알고리즘이고 RSA는 암호화 알고리즘인 "sha256RSA"가 여기에 해당한다.
  • 서명:인증서의 본문을 해시("Signature Algorithm" 필드의 해시 알고리즘이 사용됨)한 다음, 발행자의 개인 키로 해시("Signature Algorithm" 필드의 암호화 알고리즘이 사용됨)를 암호화한다.

예

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필드는 모든 적절한 용도를 보여준다. 

인증서:Data:         Version: 3 (0x2)         Serial Number:             72:14:11:d3:d7:e0:fd:02:aa:b0:4e:90:09:d4:db:31         Signature Algorithm: sha256WithRSAEncryption         Issuer: C=US, ST=Texas, L=Houston, O=SSL Corp, CN=SSL.com EV SSL Intermediate CA RSA R3         Validity             Not Before: Apr 18 22:15:06 2019 GMT             Not후 : 4월 17일 22:15:06 2021 GMT 제목 : C=US, ST=텍사스, L=Houston, O=SSL Corp/serialNumber=NV20081614243, CN=www.ssl.com/postalCode=77098/businessCategory=Private 조직/거리=3100 Richmond Ave/jurisdationST=네바다/jurisdictionC=US Subject Public Key Info: Public Key 알고리즘: rsaEncryption RSA Public-Key: (2048비트) Modulus: 00:ad:0f:ef:c1:97:5a:9b:d8:1e ...지수: 65537 (0x10001) X509v3 확장: X509v3 Authority 키 식별자: keyid:BF:C1:5A:87:FF:28:FA:41:3D:FD:B7:4F:E4:1D:AF:A0:61:58:29:BD 기관 정보 액세스: CA 발급자 - URI:http://www.ssl.com/repository/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crt OCSP - URI:http://ocsps.ssl.com X509v3 주체 대체 이름: DNS:www.ssl.com, DNS:answers.ssl.com, DNS:faq.ssl.com, DNS:info.ssl.com, DNS:links.ssl.com, DNS:links.ssl.com, DNS:reseller.ssl.com, DNS:secure.ssl.com, DNS:ssl.com, DNS:support.ssl.com, DNS:sws.ssl.com, DNS:tools.ssl.com X509v3 인증서 정책:Policy: 2.23.140.1.1                 Policy: 1.2.616.1.113527.2.5.1.1                 Policy: 1.3.6.1.4.1.38064.1.1.1.5                   CPS: https://www.ssl.com/repository              X509v3 Extended Key Usage:                  TLS Web Client Authentication, TLS Web Server Authentication             X509v3 CRL Distribution Points: 전체 이름: URI:http://crls.ssl.com/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crl X509v3 주체 키 식별자: E7:37:48:DE:7D:C2:E1:9D:D0:11:25:21:B8:00:00:33:63:06:27:C1:5B X509v3 키 사용: 중요 디지털 서명, 키 암호화 CT 사전 인증: 서명된 인증서 타임스탬프:버전: v1(0x0) 로그 ID: 87:75:BF:E7:59:7C:F8:8C:43:99 ...타임스탬프 : 4월 18일 22:25:08.574 2019 GMT Extensions: 없음 서명 : ecdsa-with-SHA256 30:44:02:20:40:51:53:90:90:C6:A2 ...서명된 인증서 타임스탬프:버전 : v1(0x0) 로그 ID : A4:B9:09:90:B4:18:58:14:87:BB ...타임스탬프 : 4월 18일 22:25:08.461 2019 GMT Extensions: 없음 서명 : ecdsa-with-SHA256 30:45:02:20:43:80:9E:90:90:FD ... 서명된 인증서 타임스탬프:버전 : v1(0x0) 로그 ID : 55:81:D4:C2:16:90:36:01:4A:EA ... 타임스탬프 : 4월 18일 22:25:08.769 2019 GMT Extensions: 없음 서명 : ecdsa-with-SHA256 30:45:02:21:00:C1:3E:9F:F0:40...시그니처 알고리즘: sah256WithRSAEncryption 36:07:e7:3b:b7:45:97:ca:4d:6c ...

유럽 연합의 사용

유럽연합(EU)에서는 법률문서에 기재된 (고급) 전자서명은 일반적으로 신분증명서가 첨부된 디지털서명을 사용하여 수행된다.단, 적격의 전자서명(자격의 신탁서비스 제공자와 서명 생성 장치를 사용해야 함)만 물리적 서명과 동일한 권한을 부여받는다.

인증기관

주요 기사:인증 기관
공개 키 인증서 획득 절차

X.509 트러스트 모델에서는 인증 기관(CA)이 인증서에 서명할 책임이 있다.이러한 인증서는 양 당사자 간의 소개로 작용하며, 이는 CA가 신뢰할 수 있는 제3자 역할을 한다는 것을 의미한다.CA는 인증서를 요청하는 사람 또는 조직(가입자라 함)의 요청을 처리하고, 정보를 검증하며, 그 정보를 기반으로 최종 자격증서에 서명할 가능성이 있다.이 역할을 효과적으로 수행하기 위해 CA는 하나 이상의 광범위하게 신뢰할 수 있는 루트 인증서 또는 중간 인증서 및 해당 개인 키를 보유해야 한다.CA는 그들의 루트 인증서를 인기 있는 소프트웨어에 포함시키거나 신뢰를 위임하는 다른 CA로부터 교차 서명을 얻음으로써 이러한 광범위한 신뢰를 얻을 수 있다.다른 CA는 기업처럼 비교적 작은 커뮤니티 내에서 신뢰받고 있으며, Windows Group Policy와 같은 다른 메커니즘에 의해 배포된다.

인증기관도 자신이 발급한 인증서에 대한 최신 해지 정보를 유지할 책임이 있어 인증서의 유효 여부를 알 수 있다.그들은 이 정보를 온라인 인증서 상태 프로토콜(OCSP) 및/또는 인증서 해지 목록(CRL)을 통해 제공한다.시중에 유통되는 대형 인증기관으로는 아이덴트러스트, 디지커트, 파피고 등이 있다.[8]

루트 프로그램

일부 주요 소프트웨어에는 기본적으로 신뢰할 수 있는 인증 기관 목록이 포함되어 있다.이를 통해 최종 사용자가 인증서의 유효성을 쉽게 확인할 수 있으며, 인증서를 요청하는 사용자나 조직은 광범위하게 신뢰할 수 있는 인증서를 발급할 수 있는 인증 기관을 쉽게 알 수 있다.이것은 HTTPS에서 특히 중요한데, 일반적으로 웹 사이트 운영자는 거의 모든 잠재 방문자가 신뢰할 수 있는 인증서를 얻기를 원한다.

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

Firefox 이외의 브라우저는 일반적으로 운영 체제의 기능을 사용하여 신뢰할 수 있는 인증 기관을 결정한다.그래서 예를 들어, 윈도우의 크롬은 마이크로소프트 루트 프로그램에 포함된 인증 기관을 신뢰하는 반면, 맥OS나 iOS에서는 크롬이 애플 루트 프로그램에 있는 인증 기관을 신뢰한다.[9]Edge와 Safari는 각각의 운영 체제 신뢰 저장소도 사용하지만 각각은 단일 OS에서만 사용할 수 있다.Firefox는 모든 플랫폼에서 Mozilla Root Program 트러스트 스토어를 사용한다.

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

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

웹사이트 보안

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

예를 들어 사용자가 연결할 때https://www.example.com/브라우저가 인증서 경고 메시지를 제공하지 않으면 사용자는 이론적으로 상호 작용하는 것을 확신할 수 있다.https://www.example.com/비록 그 이메일 주소가 웹 사이트의 어느 곳에도 표시되지 않을 수 있지만, "example.com"에 따라 공공 등록기관에 나열된 이메일 주소와 접촉하는 기업과 상호 작용하는 것과 같다.어떤 종류의 보증도 암시되어 있지 않다.또한, 인증서의 구매자, 웹 사이트의 운영자, 웹 사이트 컨텐츠의 생성자 사이의 관계는 경미한 것일 수 있으며, 보장되지 않는다.기껏해야 웹 사이트 자체가 손상(해킹)되지 않았거나 인증서 발급 프로세스가 역행되지 않았다면 인증서는 웹 사이트의 고유성을 보장한다.

인증서 제공자는 세 가지 유형의 인증서를 발급하는 것을 선택할 수 있으며, 각 인증서는 자체적인 엄격한 검증이 필요하다.엄격성(그리고 자연스럽게 비용)을 높이기 위해 도메인 검증, 조직 검증 및 확장 검증이 그것이다.이러한 고정관념은 CA/Browser Forum의 자발적인 참여자에 의해 느슨하게 합의된다.

유효성 검사 수준

도메인 유효성 검사

주요 기사:도메인 인증 인증서

구매자가 영향을 받는 DNS 도메인을 관리적으로 관리할 수 있는 권리라는 하나의 검증 기준을 제시할 수 있는 경우, 인증 제공자는 구매자에게 DV(도메인 검증) 인증서를 발급한다.

조직 유효성 검사

구매자가 문제의 도메인 이름을 행정적으로 관리할 수 있는 권한과 아마도 법률적 실체로서 조직의 실존 여부라는 두 가지 기준을 충족할 수 있는 경우, 인증 제공자는 구매자에게 조직 유효성 검사(OV) 등급 인증서를 발급한다.인증서 공급자는 인증서 정책을 통해 OV 검사 기준을 게시한다.

확장 유효성 검사

주요 기사:확장 유효성 검사 인증서

EV(확장 유효성 검사) 인증서를 취득하려면 구매자가 인증 제공자에게 사람의 수동 확인 검사를 포함한 법적 정체성을 설득해야 한다.OV 인증서와 마찬가지로, 인증서 공급자는 인증서 정책을 통해 EV 검사 기준을 공개한다.

2019년까지 크롬, 파이어폭스 등 주요 브라우저는 일반적으로 사이트가 EV 인증서를 제시하면 사용자에게 법적 정체성을 시각적으로 표시하도록 했다.이는 도메인 앞에 법명을 표시하고, 변화를 강조하기 위한 밝은 초록색을 보여줌으로써 이루어졌다.대부분의 브라우저는 사용하는 인증서 종류에 대해 사용자에게 시각적 차이를 제공하지 않고 이 기능을[11][12] 사용하지 않았다.이런 변화는 법의학 전문가들이 제기한 보안 우려와 유명 조직을 사칭하기 위해 EV 인증서를 구매하려는 성공적 시도에 이은 것으로, 이러한 시각적 지표의 비효율성을 입증하고 잠재적인 남용 가능성을 부각시켰다.[13]

약점

웹브라우저는 웹 사이트가 갑자기 다른 인증서를 제시하는 경우, 인증서의 키 비트 수가 적더라도, 다른 제공자가 있더라도, 그리고 이전 인증서의 만료 날짜가 먼 미래에도 사용자에게 경고를 주지 않는다.[citation needed]인증 제공자가 정부의 관할 하에 있는 경우, 그러한 정부는 제공자에게 법 집행 목적과 같은 어떤 인증서의 생성을 명령할 수 있는 자유를 가질 수 있다.자회사 도매 인증서 제공업체도 인증서를 생성할 자유가 있다.

모든 웹 브라우저에는 신뢰할 수 있는 루트 인증서의 광범위한 목록이 내장되어 있으며, 그 중 상당수는 사용자에게 생소할 수 있는 조직에 의해 제어된다.[1]이러한 각 조직은 어떤 웹 사이트에 대해서도 자유롭게 인증서를 발급할 수 있으며 루트 인증서를 포함하는 웹 브라우저가 이를 정품으로 받아들일 것이라는 보증을 가지고 있다.이 경우 최종 사용자는 내장된 인증서 목록을 관리하고 인증서 제공자가 올바르게 동작하고 브라우저 개발자에게 문제가 있는 인증서를 알리기 위해 브라우저 소프트웨어의 개발자에게 의존해야 한다.드물지만, 사기성 인증서가 발급된 사건도 있었다. 어떤 경우에는 브라우저가 부정 행위를 탐지했고, 다른 경우에는 브라우저 개발자들이 소프트웨어에서 이러한 인증서를 제거하기까지 어느 정도의 시간이 흘렀다.[14][15]

빌트인 인증서의 목록은 브라우저 개발자가 제공하는 인증서에 한정되지 않는다: 사용자(및 학위 애플리케이션까지)는 회사 인트라넷과 같은 특별한 목적을 위해 자유롭게 목록을 확장할 수 있다.[16]이는 누군가가 컴퓨터에 대한 액세스 권한을 얻고 브라우저에 새 루트 인증서를 설치할 수 있는 경우 해당 브라우저는 삽입된 인증서를 사용하는 웹 사이트를 합법적인 것으로 인식한다는 것을 의미한다.

입증 가능한 보안을 위해, 시스템 외부의 무언가에 대한 이러한 의존은 어떤 공개 키 인증 체계가 인증 기관의 존재와 같은 특별한 설정 가정에 의존해야 하는 결과를 가져온다.[17]

유용성 대 보안되지 않은 웹 사이트

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

표준

국립표준기술원(NIST) 컴퓨터보안과에서는[19] 공용 키 인증서에 대한 지침 문서를 제공한다.

  • SP 800-32 공공 키 기술 및 연방 PKI 인프라[20] 소개
  • SP 800-25 연방정부 디지털 서명 및 인증에[21] 공용 키 기술 사용

참고 항목

참조

  1. ^ a b "List of certificates included by Mozilla". Mozilla.org. Retrieved 30 July 2012.
  2. ^ Chadwick, David W; Basden, Andrew (2001-10-31). "Evaluating Trust in a Public Key Certification Authority". Computers & Security. 20 (7): 592–611. doi:10.1016/S0167-4048(01)00710-6. ISSN 0167-4048.
  3. ^ "Using Client-Certificate based authentication with NGINX on Ubuntu - SSLTrust". SSLTrust. Retrieved 26 March 2019.
  4. ^ "Client Certificate vs Server Certificate: Simplifying the Difference". Savvy Security. 2017-11-28. Retrieved 2021-09-05.
  5. ^ "EMV CA". EMV Certificate Authority Worldwide. 2 December 2010. Retrieved January 20, 2020.
  6. ^ X.509 연방교량인증기관(FBCA) 인증서 정책
  7. ^ X.509 연방교량인증기관(FBCA) 인증서 정책
  8. ^ "Usage Statistics and Market Share of SSL Certificate Authorities for Websites, May 2020". w3techs.com. Retrieved 2020-05-01.
  9. ^ "Root Certificate Policy – The Chromium Projects". www.chromium.org. Retrieved 2017-03-19.
  10. ^ "ca-certificates in Launchpad". launchpad.net. Retrieved 2017-03-19.
  11. ^ "Firefox-dev Google group - Intent to Ship: Move Extended Validation Information out of the URL bar". groups.google.com. Retrieved 2020-08-03.
  12. ^ "Chrome Security-dev Google group - Upcoming Change to Chrome's Identity Indicators". groups.google.com. Retrieved 2020-08-03.
  13. ^ "Extended Validation Certificates are (Really, Really) Dead". troyhunt.com. 12 August 2019. Retrieved 2020-08-03.
  14. ^ "DigiNotar removal by Mozilla". Mozilla.org. Retrieved 30 July 2012.
  15. ^ "DigitNotar removal by Google". Retrieved 30 July 2012.
  16. ^ "Using certificates article at Mozilla.org". Mozilla.org. Retrieved 30 July 2012.
  17. ^ 란 카네티:Universally Composite Signature, Certificate 및 Authentication.CSFW 2004, http://eprint.iacr.org/2003/239
  18. ^ Ben Laurie, Ian Goldberg (18 January 2014). "Replacing passwords on the Internet AKA post-Snowden Opportunistic Encryption" (PDF). {{cite journal}}:Cite 저널은 필요로 한다. journal=(도움말)
  19. ^ "NIST Computer Security Publications – NIST Special Publications (SPs)". csrc.nist.gov. Retrieved 2016-06-19.
  20. ^ "SP 800-32 Introduction to Public Key Technology and the Federal PKI Infrastructure" (PDF). National Institute of Standards and Technology.
  21. ^ "SP 800-25 Federal Agency Use of Public Key Technology for Digital Signatures and Authentication" (PDF). National Institute of Standards and Technology.