X509 인증서에 대한 강한 이해가 있다면 손을 들어주세요. 이제 아무도 손을 들지 않는다는 것을 인정하고, 이를 바꿔 봅시다.
인증서는 복잡한 주제이며 종종 잘 이해되지 않습니다. 이 튜토리얼은 X509 인증서 예제를 보여주고 PKI 인증서를 설명하는 등 이를 바꾸기 위한 목적으로 합니다.
이 문서에서는 X509 인증서에 대한 개요를 제공합니다. 높은 수준에서 어떻게 작동하는지를 이해할 것입니다. 한 문서로 전문가가 되지는 않겠지만, 이 문서의 끝까지 가면 적어도 적절한 용어에 익숙해질 것입니다.
관련 문서: Windows 인증서 관리자와 PowerShell을 사용하여 인증서 관리하기
공개 및 개인 키: 자산 보호
X509 인증서에 대한 설명을 완전하게 하기 위해서는 먼저 키에 대한 언급이 필요합니다. 키라는 용어가 개인 및 공개 키와 같은 용어가 사용되면서 키가 정확히 무엇이며 인증서와 어떤 관련이 있는지 궁금할 수 있습니다.
연결을 쉽게 만들기 위해, 우선 잘 알려진 문을 잠그는 개념으로 키의 개념을 설명해보겠습니다.
새 문 잠금장치를 구매하면 그 잠금장치에는 문 열쇠가 함께 제공됩니다. 그 키는 그 잠금장치에만 해당되기 때문에 다른 사람은 잠금장치를 열 수 없습니다.
자물쇠 자체를 공개 키로 생각해보세요. 설치되면, 당신, 가족 또는 지나가는 사람들은 당신의 문에 있는 자물쇠를 볼 수 있습니다. 아무나 볼 수도 있고 열려고 시도할 수도 있지만 성공하지 못할 것입니다. 그를 열기 위해서는 원래 자물쇠와 함께 제공된 고유한 도어 키를 삽입해야 합니다. 자물쇠와 함께 제공된 고유한 키는 개인 키입니다.
개인 키와 공개 키가 함께 사용되면 키 쌍이라고 합니다.
키 교환
도어 키가 자물쇠에 삽입될 때, 그 행위를 키를 교환하는 것으로 생각할 수 있습니다. 개인 키 (도어 키)를 공개 키 (자물쇠)와 교환하여 문을 열어야 합니다.
암호학 세계에서는 공개 키를 자유롭게 제공하고 개인 키는 스스로만 가지고 있습니다. 결국, 누가 자물쇠를 볼지는 상관하지 않지만, 누가 그것을 열 수 있는지는 확실히 신경쓰게 됩니다 (키를 교환합니다).
키 교환 알고리즘이라고 불리는 키 교환 방법은 몇 가지가 있습니다. 키 교환 알고리즘은 고유한 공유 비밀을 유도하고 안전하게 전송하는 데 중점을 둡니다.
알려진 두 가지 키 교환 알고리즘은 디피-헬만 (DH)과 타원 곡선 디피-헬만 (ECDH)입니다.
키 신뢰
누군가가 문을 통해 들어오도록 하려면 그들에게 키를 (또는 원래 고유한 키의 사본을) 주어야 합니다. 키는 신뢰하는 사람들에게만 제공합니다. 개인 키 (도어 키)를 가지고 있는 사람은 문 자물쇠 (공개 키)를 열 수 있도록 신뢰받았습니다.
키 사용
키 사용은 X509 인증서의 목적을 정의하며, 이는 인증서에서 사용할 알고리즘과 일치합니다. 확장 키 사용(EKU)은 키 사용 이상의 공개 키의 목적을 정의합니다.
X509 Certs: 공개 키 “컨테이너”
개인 및 공개 키는 X509 인증서 개념과 어떤 관련이 있나요? 인증서를 간단히 공개 키로 생각하세요. 인증서는 공개 키와 함께 공개 키가 발급된 대상, 키를 서명한 사람 등에 대한 정보와 함께 “포장지” 역할을 합니다. 인증서는 파일 형태로 저장됩니다.
나중에 몇 가지 좋은 X509 인증서 예시를 다룰 것입니다.
PEM 또는 CER 인증서 파일 확장자를 가진 파일을 본 적이 있나요? 그것들은 인증서(공개 키)입니다. 이러한 형식에 대해 나중에 자세히 알아보겠습니다.
공개 키 자체만으로는 정의상 인증서가 아닙니다. 인증서를 정의하는 것은 공개 키와 관련된 속성 데이터의 조합입니다.
A certificate provides a standardized and secure format to communicate with specific systems along with the attributes to help validate a key pair trust. How certificates are built are defined within the X.509 standards, as you will read about later.
썸프린트: 인증서의 고유 식별자
각 X509 인증서는 단일 주체의 식별을 제공하기 위해 고안되었습니다. 인증서는 각 공개 키가 고유하게 식별 가능하도록 해야 합니다.
A certificate thumbprint or fingerprint is a way to identify a certificate, that is shorter than the entire public key. Technically, a serial number is as well but you’ll learn about that when it comes to certification authorities (CAs). The thumbprint is a hash of a DER-encoded certificate in Windows.
더 작은 고유 식별자에 의해 더 큰 데이터 집합을 식별하는 개념은 지문 추출(fingerprinting)의 일반 컴퓨팅 주제입니다. Morgan Simonson의 블로그에서 더 깊이 알아볼 수 있습니다.
주제: 중요한 X509 인증서 속성 정의
모든 X509 인증서는 고유한 식별자 뿐만 아니라 다음과 같은 질문에 대답해야 합니다. 인증서 주체는 바로 그 역할을 해야 합니다.
- 누가 이 인증서를 사용해야 합니까?
- 어느 조직이 신뢰받아야 합니까?
- 어느 사용자가 이 인증서를 제시해야 합니까?
주체는 아마도 인증서의 가장 중요한 부분입니다. 주체는 X.500에서 정의된 속성을 가지고 있으며, 인증서가 누구나 또는 무엇에게 발급되었는지를 나타냅니다. 이는 식별 이름(DN) 형식으로 표시됩니다.
A certificate subject is a string value that has a corresponding attribute type. For example, the DN for State or Province is st. This attribute type contains the full name of the state or province the subject resides in (e.g. ST=California).
이러한 속성 유형 및 값 형식은 ITU-T X.520 권고 사항에 의해 정의되어 있습니다. 속성 유형 및 값 형식에 대한 구체적인 권고 사항은 RFC 4519에서 참조할 수 있습니다.
X509 인증서 표준은 규칙이 아닌 강력한 제안일 뿐이므로, 많은 사람들이 주체를 정의할 때 자신의 판단을 사용합니다. 주체는 구체적으로 신뢰하는 최종 엔터티를 식별해야 합니다. 주체가 이를 대표하지 않는 경우, 제시된 공개 키를 사용하는 것을 어떻게 신뢰할 수 있습니까?
다른 말로 하면, 여러 사람이 동일한 사용자 이름을 사용하여 시스템에 액세스하는 것을 허용한다면, 특정 인물을 그들의 행동에 대해 책임지기 어려워집니다. 이러한 관행은 인증서가 일치해야 하는 신뢰 모델을 복잡하게 만듭니다.
Windows에서 X509 인증서를 표시하는 방법 및 특히 인증서 주체를 아래 스크린샷에서 확인할 수 있습니다.
Cryptext.dll을 사용하여 인증서의 속성을 확인할 수 있습니다.
Subject Alternative Name (SAN)
A SAN is a certificate extension that allows you to use one certificate for multiple subjects that’s typically identified with a Subject Key Identifier (SKI). The example below shows some of the SANs Google uses. Adding more domains to a certificate essentially tells the certificate to trust each subject to use the same private key.
A SAN can also have several types other than DNS names called GeneralNames. GeneralNames require the client reading the certificate to support SANs using GeneralNames. Most clients such as web browsers only focus on the DNS name SAN.
다음 X509 인증서 예시에서 SAN을 확인할 수 있습니다.
Google 인증서와 관련된 일부 SAN 속성입니다.
인코딩 이해
우리는 서로 의사 소통을 위해 여러 언어를 사용합니다. 마찬가지로 컴퓨터는 자체 언어를 가지고 있습니다. 이 언어는 이진법이며, 이진법을 다른 사람들이 이해할 수 있도록 하는 방법이 인코딩 방법입니다. 마치 우리가 영어를 다른 언어로 번역하는 것처럼요.
인코딩은 특정 목적을 위해 사용됩니다. 인코딩을 통해 인간이 읽을 수 있는 확장 값들이 컴퓨터가 사용할 수 있는 방식으로 저장됩니다. 인코딩 형식을 사용하면 컴퓨터가 X509 인증서를 저장하고 전송하는 것이 더 쉬워지며, 우리는 인증서 내용을 읽을 수 있게 됩니다.
컴퓨터는 정수 처리에 능숙하며, 인코딩을 통해 숫자 값을 알파벳 값이나 이진 덩어리로 변환할 수 있습니다. 이러한 변환은 컴퓨터와 작업하는 데 필수적이며, 인증서는 컴퓨터와 올바른 정보를 정확하게 전달하기 위해 인코딩을 의존합니다. 인코딩 형식은 이러한 변환을 수행하기 위한 표준을 정의합니다.
- ASN.1 – Abstract Syntax Notation One 표준은 인증서 내 각 필드의 직렬화 형식입니다.
- ASCII – 정보 교환을 위한 미국 표준 코드 (ASCII)는 대부분의 사람이 읽을 수 있는 통신에 사용되는 컴퓨터 제어 문자와 인쇄 가능한 문자마다 이진 값을 정의합니다.
- Base64 – Base64는 ASCII 문자 집합 내에서 이진 콘텐츠를 인코딩하기 위한 체계를 정의합니다. 이러한 인증서는 텍스트 편집기에서 열 수 있으며 “BEGIN CERTIFICATE” 또는 기타 참조 텍스트가 표시됩니다.
- DER – Distinguished Encoding Rules (DER)는 순차적인 8비트로 구성된 ASN.1 데이터를 위한 다른 인코딩 체계를 정의합니다. DER의 중요한 고려 사항은 인코딩된 출력이 ASCII로 볼 수 없다는 것입니다.
인코딩 체계 간의 차이를 아래에서 확인할 수 있습니다. 첫 번째로 표시된 certificate.crt 파일은 ——-BEGIN CERTIFICATE——-로 시작하고 무작위 문자와 숫자로 이루어진 내용이 이어지며 ——-END CERTIFICATE——-로 끝납니다. 모든 문자는 사람이 읽을 수 있습니다. 첫 번째 인증서는 Base64로 인코딩되었습니다.
이제 두 번째 예제인 certificate.cer 파일을 살펴보십시오. 이 파일의 내용은 Base64 인증서와 매우 다릅니다. 이 X509 인증서는 DER로 인코딩되었습니다.
Base64와 DER로 인코딩된 파일의 차이점.
X509 인증서 파일 유형 이해
인증서는 파일로 표현되는 메타데이터와 함께 공개 키에 불과합니다. 야생에서 많은 종류의 파일을 찾을 수 있으며 이 파일들은 다양한 유형의 인증서를 나타냅니다. 각 파일 유형은 파일 확장자에 따라 구별됩니다. 예를 들어 KEY 파일이라고 말할 때, 파일 확장자를 의미합니다.
아래에서는 파일 확장자로 정의된 일반적인 유형의 인증서와 해당 용도를 찾을 수 있습니다.
아래 목록에서는 PKCS에 대한 여러 참조가 있음을 알 수 있습니다. PKCS 또는 공개 키 암호화 표준은 다양한 인증서가 생성되는 방식을 정의하는 일련의 표준입니다. 자세한 정보는 이 유익한 위키피디아 기사를 참조하십시오.
- PFX – 이는 주로 Windows 환경에서 찾을 수 있지만 운영 체제에 관계없이 표준 형식입니다. PFX 파일에는 인증서, 공개 키 및 확장 기능, 비밀번호로 암호화된 개인 키가 포함되어 있습니다. PFX는 PKCS #12 표준에 따라 정의됩니다.
- P12 – PFX와 같이 P12도 PKCS #12 표준에 따라 정의됩니다. 공식적으로 PKCS #12는 PFX 형식의 후속입니다. 그러나 두 파일 유형은 최신 암호화 구현에서 동일한 형식을 나타냅니다.
- P7B – ASN.1 인증서의 컨테이너로, 아래에서 설명할 인증서 기관 체인의 모든 계층의 공개 키를 제공합니다. PKCS #7 파일은 여러 공개 키를 분산시키기 위한 단일 파일을 제공하며, 비공개 PKI에서 CA와의 신뢰 설정에 자주 사용됩니다.
- P7C – P7C 파일 유형은 기능적으로 P7B와 동일하지만 PKCS #7 파일을 나타내는 또 다른 일반적인 확장명입니다.
- DER – DER 파일은 DER 인코딩된 공개 키입니다.
- CER – 공개 키는 DER 또는 Base64로 인코딩될 수 있습니다. CER 파일은 일반적으로 DER로 인코딩됩니다.보통.
- CRT – CRT는 일반적으로 Base64로 인코딩되지만 보장할 수는 없습니다.
- KEY – KEY 파일은 일반적으로 암호화되었든 아니든 Base64로 인코딩된 개인 키입니다.
- PEM – Base64로 인코딩된 인증서를 참조합니다. 하나의 PEM 파일에 여러 개의 키가 있을 수 있지만, 일반적으로 PEM 파일에는 개인 키가 있다고 가정합니다. 가장 일반적으로 암호화되었든 암호화되지 않았든 PEM Base64로 인코딩된 개인 키 파일에 사용됩니다.
- CSR – 공개 키를 CA에 제출하여 서명되고 일련 번호와 같은 추가 필드가 부여되는 목적으로 사용되며 PKCS #10에 의해 정의됩니다. 대부분의 경우, CSR에는 요청에 대한 ASN.1 구조가 Base64로 인코딩되어 포함됩니다.
- REQ – Windows에서 CSR을 생성할 때 사용되는 등록 정책 설정을 지정하는 데 사용됩니다.
- CRL – CRL은 CA에 의해 폐지된 인증서, 폐지 상태 및 폐지된 이유를 명시하는 특정 파일입니다.
공개 키 인프라 (PKI): X509 Cert 에코시스템
이전에 누군가가 문을 열 수 있는 열쇠를 가지고 있던 순간을 떠올려보십시오. 그 경우에는 하나의 문만 있었습니다. 그러나 갑자기 수십 개 또는 수백 개의 아파트를 소유한 임대인이 되었을 때 어떻게 될까요? 그 모든 문 열쇠를 관리하는 것은 어려워질 것입니다!
또한 입주자는 영원히 해당 아파트에 머무르지 않을 것입니다. 일부 사람들은 열쇠를 보관하거나 무단으로 복사할 것입니다. 접근을 방지하기 위해 문 잠금 장치를 변경해야 할 것입니다. 이전 입주자를 믿을 수 없습니다.
입주자가 계속 이사를 왔다갔다하는 수백 개의 아파트를 관리해야 한다면 어떻게 관리해야 할까요? 그 답은 공개 키 인프라(PKI)입니다.
PKI는 공개 키를 관리하기 위해 구축된 역할, 정책 및 절차의 전체 생태계입니다. PKI는 X509 인증서의 배포, 사용, 관리 및 제거에 대한 많은 다양한 영역을 포괄하는 것입니다. 사실상 인증서를 적절하게 처리하고 관리하기 위해 필요한 모든 것입니다.
다음 섹션에서는 PKI의 가장 일반적인 구성 요소를 분석하고 각 구성 요소의 역할을 설명하겠습니다.
인증 기관(CAs): 당신의 부모
A PKI is primarily built around the concept of managing trust. But since it’s not economical to directly manage hundreds or thousands of trust relationships, you need a mediator.
원래 당사자로부터 이미 신뢰받은 제3자가 필요합니다. 이러한 제3자 중재인은 인증 기관 (CAs)로 불리며 주어진 인증서를 서명하는 데 사용된 공개 키에서 유래한 인증 기관 키 식별자(Authority Key Identifiers, AKI) 확장으로 식별됩니다.
당신을 어린이로 생각해보십시오. X509 인증서로. 아마도 당신은 부모님으로부터 낯선 사람들을 믿지 말라는 것을 배웠을 것입니다. 하지만 만약 당신이 믿는 사람들인 부모님이 당신을 낯선 사람에게 소개하고 그들을 믿을 수 있다고 말한다면 어떨까요? 아마도 당신은 그와 함께 가서 그 낯선 사람을 믿을 것입니다. 결국, 부모님이 그들을 믿는다면 당신도 그들을 믿을 수 있기 때문입니다.
A CA plays the role of your parents. You trust your parents (a CA) and they introduce you to strangers. They do so by signing the stranger’s public key to let you know that you can trust them.
CA의 주요 역할은 신뢰할 수 있는 중재자로서 작동하는 것입니다.
X509 인증서 발급: 신뢰성 확립
알려진 신뢰할 수 있는 기관인 CA는 간접적인 당사자들 사이의 신뢰를 가능하게 합니다. 당사자들 사이의 신뢰를 가능하게 하기 위해 CA는 “인증서”를 “발급”합니다. 우리가 CA가 발급한다고 얘기할 때, 실제로는 CA가 요청된 확장을 검증하고 CA에서 생성한 확장을 추가하여 인증서를 만드는 것을 의미합니다.
CA가 X509 인증서를 발급할 때, 자체 개인 키를 사용하여 인증서의 공개 키에 디지털 서명을 합니다. 서명 과정을 통해 CA는 모두에게 이 공개 키를 신뢰한다는 것을 알리기 위해 인증서에 표시를 합니다. DocuSign은 이 특정 개념을 좋은 다이어그램과 함께 잘 설명하고 있습니다.여기에서 좋은 개요를 제공합니다.
CA에서 생성한 확장의 또 다른 예는 각 인증서에 대한 일련 번호입니다. 각 일련 번호는 RFC 설계 사양에 따라 해당 CA에 대해 고유해야 합니다.
현대 뉴스에서 의도하지 않은 신뢰의 예는 악성 코드와 함께 PKI를 악용하는 것입니다. 개발자들은 대부분의 시스템에서 암묵적으로 신뢰되는 유효한 인증서를 받아들이기 때문에, 시스템이 악성 코드 이진 파일을 악성으로 식별하는 것이 더욱 어려워집니다.
X509 Cert 폐기: 신뢰 제거
CA는 더 이상 신뢰할 수 없는 X509 인증서를 폐기하는 것도 책임집니다. 이러한 폐기는 CA에 의해 인증서 폐기 목록 (CRL)에 공개됩니다. 폐기는 인증 기간이 만료되기를 기다리는 대신 CA가 인증서를 명시적으로 무효화하는 방법입니다.
인증서가 설계된 대로 작동하기 위해 신뢰는 중요한 구성 요소입니다. 배포 지점은 인증서 및 폐기 목록을 발급 기관에서 다운로드하고 사용 중인 인증서와 비교할 수 있는 참조 지점을 제공하여 신뢰를 보장하는 데 도움이 됩니다.
A CRL Distribution Point (CDP) supplies the protocols and locations to obtain CRLs. Updating CRLs is a passive revocation validation method, with pulling updates at scheduled intervals. Online Certificate Status Protocol (OCSP) actively requests the revocation status of a specific certificate by maintaining caches of the CRLs.
CRL 또는 OCSP를 통한 폐기 유효성 검증이 가능하지만, 클라이언트가 지원하고 강제로 적용해야 하는 것은 항상 그렇지 않을 수 있습니다.
계층화
A PKI can be made up of multiple CAs or a single CA, these are commonly referred to as tiers.
X509 인증서 체인
위에서 배운 것처럼 인증서를 사용할 때 신뢰는 주요한 초점입니다. 관련 당사자는 신뢰할 수 있는 CA에서 발급된 인증서를 신뢰하거나 검증할 수 있어야 합니다.
A great example of how this scales is the The United States Federal PKI public documents. These provide a great reference into maintaining an inter-organization trust relationship using CAs.
X509 인증서 서명
인증서 서명에 대해 자주 듣게 될 것입니다만, 정확히 무슨 의미인지 궁금할 것입니다. 이미 배운 것처럼 인증서는 모두 신뢰에 관련된 것입니다. 신뢰를 확립하기 위해 X509 인증서는 인증 기관(CA)에 의해 서명됩니다. 인증서에 서명하는 것은 고유한 암호화 해시를 인증서에 할당하여 모든 사용자가 이를 신뢰할 수 있음을 알려줍니다. 이것은 신뢰할 수 있는 CA에 의해 서명되었다는 것을 알려줍니다.
PKI 계층 구조에서 인증서는 CA에 의해 서명됩니다. 그러나 어떤 종류의 CA에 의해 서명되는지는 인증서가 사용되는 곳에 따라 다릅니다.
PKI에 단일 CA가 있는 경우 해당 CA는 루트입니다. 다른 CA가 존재하지 않으므로 해당 CA는 자체적으로 자체 서명된 인증서를 생성해야 합니다. 그런 다음 해당 CA는 자체 인증서로 서명된 인증서를 발급합니다.
PKI에 둘 이상의 CA가 있는 경우 모든 CA는 루트 CA 또는 루트 CA로 연결되는 중간 CA에 의해 서명됩니다.
일반적으로 장치가 X509 인증서를 생성할 때 개인 키와 해당하는 공개 키를 사용하는 것을 자체 서명된 인증서라고 합니다. 그러나 CA에게 자체 개인 키를 사용하여 인증서를 서명해 달라고 요청할 수도 있습니다.
서명 알고리즘
서명 알고리즘은 원격 피어로부터 메시지의 진위성을 검증하는 데 중점을 둡니다. 디지털 서명은 보내는 측의 개인 키로 암호화된 해시 함수의 메시지 다이제스트입니다. 수신자는 보내는 측의 공개 키의 사본을 사용하여 디지털 서명을 복호화합니다. 그런 다음 수신자는 수신된 메시지의 다이제스트와 디지털 서명에서 해독된 다이제스트를 비교할 수 있습니다. 다이제스트가 일치하는 경우 메시지의 진위성이 유효합니다.
비대칭 암호화는 이전에 알려진 비밀 없이 암호문을 생성하는 능력입니다. 키 교환 알고리즘과 서명 알고리즘의 조합은 비대칭 암호화의 기초입니다.
아래는 디지털 서명에 사용되는 주요 알고리즘입니다.
- RSA(Rivest-Shamir-Adleman)
- DSA(Digital Signature Algorithm)
- ECDSA(Elliptic Curve DSA)
CSR(Certificate Signing Requests)
발급 기관은 클라이언트가 발급을 위해 공개 키를 제출할 수 있는 CSR(Certificate Signing Requests)를 사용합니다. CA는 CSR을 받아 구성된 발급 정책을 기반으로 서명된 X509 인증서를 발급합니다. 즉, 신뢰하는 각 CA는 그 CA가 서명하는 공개 키에 대한 신뢰도를 의미합니다.
해싱
해싱은 복잡한 주제이며, 이 게시물에서 성의를 다하기 어렵습니다. Computerphile 팀은 그들의 YouTube 채널에서 잘 설명하고 있습니다. 해싱은 입력 개체를 가져와 해당 고유한 출력 해시를 생성하는 데 초점을 맞춥니다. 출력 해시는 다이제스트라고도 합니다. 즉, 입력 개체를 아주 작은 부분만 변경하더라도 고유하고 무관한 다이제스트가 생성됩니다.
현대적인 구현은 안전한 해시 알고리즘(SHA) 2 알고리즘에 초점을 맞출 것입니다. 참고로, SHA 256, SHA 384 및 SHA 512는 SHA 2로 알려져 있습니다.
아래는 흔히 볼 수 있는 일반적인 해싱 알고리즘 목록입니다.
- SHA 256
- SHA 384
- SHA 512
- 메시지 다이제스트 (MD) 5
인증서 정책
인증서 정책 (CP) 확장은 CA를 유지하는 조직에 대한 참조를 제공하며, 해당 PKI의 실제 정책을 문서화하고 주어진 PKI를 유지하기 위한 조직의 정책을 인증 실천 성명서 (CPS)로 정렬해야 합니다.
배포 지점
인증서 내에서 식별되는 다른 유형의 배포 지점은 권한 정보 액세스 (AIA)입니다. 이러한 AIA는 인증서 발급자 정보의 복사본을 얻을 수 있는 프로토콜과 위치를 제공하며, 일반적으로 이는 발급 CA의 공개 키를 의미합니다.
요약
이 문서의 시작 부분에서 언급된 질문을 받았을 때, 이제 당신은 손을 높이 들어 답변하는 데 보다 편안해질 것입니다. 솔직히 말해서, 이 문서는 X509 인증서의 복잡성과 Windows의 이러한 표준의 구현을 이해하는 데 도움이 되었기를 바랍니다. 또한 앞으로 인증서 작업을 할 때 도움이 될 몇 가지 기본 구성 요소를 이해하는 데도 도움이 됩니다.
적어도 이제는 누군가가 인증서의 공개 키를 요청할 때 DER 또는 Base64로 인코딩된 것을 확인할 수 있고, 그들은 이를 알지 못하기 때문에 두 가지 모두를 보내게 될 것입니다.