JayP가 공용 인터넷을 통해 youtube.com에 연결하려고 한다고 가정해 보겠습니다. 의사소통이 이루어지기 전에 다음과 같은 몇 가지 우려 사항이 발생합니다.  그가 실제로 YouTube와 통신하고 있는지 어떻게 확인할 수 있나요? (입증)  JayP는 자신의 메시지를 가로채는 사람이 아무도 없다는 것을 어떻게 알 수 있습니까? (비밀유지)  또한 메시지를 변경한 사람이 아무도 없다는 것을 어떻게 확신할 수 있습니까? (진실성)  글쎄, 각 문제를 개별적으로 해결해 봅시다. 우선 JayP가   의 신원을 확인해야 합니다. 이를 위해서는 Youtube의 공개 키가 필요합니다. 공개 키는 YouTube의 ID를 나타냅니다. 유튜브  문제  문제는 공격자가 인터넷상의 한 컴퓨터에서 다른 컴퓨터로의 요청을 가로채서   시작하는 방법을 생각해냈다는 것입니다. 이런 종류의 공격을 통해 공격자 Chady는 자신의 공개 키를 주입하고 JayP가 자신이 Youtube와 통신하고 있다고 생각하게 만들지만 실제로는 Chady와 통신하고 있습니다.  중간자 공격을  Chady가 몰래 들어와 자신의 공개 키를 보냅니다.  이제 당신은 무섭다고 생각할 수도 있습니다. 그렇지 않습니까? 로그인 자격 증명이나 신용 카드 정보와 같은 개인 정보를 훔치는 것부터 맬웨어 배포 또는 기타 악의적인 목표에 이르기까지 이러한 종류의 공격으로 무엇이 가능할 수 있는지 상상해 보십시오. 그렇다면 JayP는 자신이 받은 공개 키가 실제로 Youtube에서 온 것인지 어떻게 확신할 수 있습니까? 이것이 바로 디지털 인증서가 들어오는 곳입니다. (TADAAA)   그들은 공개 키가 실제로 악의적인 Chady가 아닌 Youtube에서 오는지 확인합니다. 실제로 디지털 인증서는 HTTPS 뿐만 아니라 메일, IOT, VPN 등에도 사용할 수 있는데…  TLS 인증서 내부 정보  디지털 인증서에는 꽤 많은 정보가 포함되어 있습니다. 가장 중요한 정보를 살펴보겠습니다.     이 인증서에 서명한 제3자입니다. 이에 대해 잠시 후에 살펴보겠습니다. 일부 기본 정보에는 일반 이름, 조직 및 국가가 포함됩니다. 발급자는  물론 디지털 인증서에는 이전과 이후가 아닌 두 개의 중요한 필드가 있는   도 포함됩니다. 유효성    는 인증서의 소유자이며 우리의 경우 Youtube가 됩니다. 제목에는 일반 이름, 주소 및 가장 중요한 공개 키와 같은 정보가 포함됩니다. 주체  마지막으로 디지털 인증서에는   이 포함됩니다. 이는 이 인증서가 진짜임을 증명하는 발급자가 서명한 서명입니다.  서명  누가 디지털 인증서에 서명합니까?  디지털 인증서는 인증 기관(예: DigiCert, Comodo, Symantec, Google Trust Services)이라는 기관에서 서명합니다.  그런데 인증 기관이란 무엇입니까?  간단히 말해서 인증 기관은 디지털 인증서 발급을 담당하는 신뢰할 수 있는 제3자 조직입니다.   인증 기관에는 자체 공개 키와 개인 키가 있습니다. 그럼 이제 서명이 어떻게 만들어지는지 설명하겠습니다.  예를 들어 디지털 인증서에 포함된 이전에 언급된 정보는   사용하여 해시됩니다. 해시가 생성된 후 인증 기관은 RSA 비대칭 키 암호화를 사용하는 개인 키를 사용하여 해시를 암호화합니다. 이 암호화된 해시는 인증서의 서명이며 인증 기관의 공개 키를 통해서만 해독될 수 있습니다. 이 인증서에 서명한 인증 기관의 공개 키를 가진 사람은 누구나 인증서가 진짜이고 변조되지 않았는지 암호를 해독하고 확인할 수 있습니다.  SHA-256 알고리즘을  브라우저가 인증서를 받으면 동일한 해시 알고리즘(이 예에서는 SHA-256)을 사용하여 브라우저 측의 모든 정보를 해시합니다. 그런 다음 인증 기관의 공개 키를 사용하여 서명을 해독하여 인증 기관으로부터 해시를 받습니다. 두 해시가 모두 일치하면 브라우저는 이 인증서가 실제로 청구된 인증 기관에서 나온 것인지 확인할 수 있습니다.   인증 기관의 계층 구조  인증 기관(루트 인증 기관 및 중간 인증 기관)에 대한 계층 구조가 존재합니다.   이러한 루트 CA는 실제로 서버에 대한 디지털 인증서를 직접 발급하지 않습니다. 자신을 대신하는 중간 CA에 대해서만 디지털 인증서를 발급합니다. 중간 CA는 다른 중간 CA 또는 서버에 대한 디지털 인증서를 직접 발급할 수 있습니다.   따라서 루트 CA에서 서버까지 신뢰 체인이 있습니다.  운영 체제는 신뢰할 수 있는 루트 인증 기관 목록인 신뢰 저장소와 함께 번들로 제공됩니다. 이 목록은 Apple 및 Microsoft와 같은 운영 체제를 만드는 회사에서 관리합니다. 이들 모두는 신뢰성과 유효성을 입증하는 하나 이상의 감사를 받기 위해 루트 인증 기관이 필요합니다.  이 모든 것이 그림에 어떻게 들어맞나요?  처음부터 전체 과정을 시각화해 보겠습니다.  먼저 youtube.com이 신생 스타트업이라고 가정해 보겠습니다. 공개적으로 사용 가능한 인터넷에서 보안을 유지해야 하는 필요성을 이해하는 Youtube는 신뢰할 수 있는 디지털 인증서를 소유하고 방문자에게 제시해야 합니다.   1단계: YouTube에서 디지털 인증서를 구매합니다.  우선 유튜브는 중간 인증기관을 찾아 나선다. 중간 인증 기관은 서버와 루트 인증 기관 사이의 중개자라는 점을 기억하십시오. Youtube의 경우 Google에는 Google Trust Services라는 자체 인증 기관이 있습니다.   중간 CA를 선택한 후 Youtube는 인증서 서명을 요청합니다. 인증서 서명 요청에는 일반 이름, 조직, 가장 중요하게는 Youtube의 공개 키 등 Youtube의 디지털 인증서에 포함될 정보가 포함됩니다. YouTube는 인증서 서명 요청을 중간 CA에 보냅니다.   중간 인증 기관은 주체라고도 하는 소유자에 대한 정보가 포함된 CSR을 확인합니다. 그런 다음 중간 인증서에 대한 정보인 발급자 정보 및 유효성과 같은 필드를 추가한 다음 서명 프로세스에서 이전에 설명한 대로 이 모든 정보에 서명합니다. 서명 후 중간 인증 기관은 YouTube용 디지털 인증서를 다시 보냅니다.   이제 Youtube는 새로 구입한 디지털 인증서를 웹 서버에 연결할 수 있습니다.  2단계: JayP는 youtube.com에 연결하여 피트니스 동영상을 시청합니다.   유튜브에 접속하면 유튜브 자체 인증서와 중개 인증기관의 인증서를 보내준다. 루트 인증 기관은 JayP 운영 체제에서 사용할 수 있으므로 전송되지 않습니다. 유튜브 인증서에는 중간 인증기관인 발급자 정보가 포함됩니다. 따라서 브라우저는 이 인증서가 Google Trust Services 중간 인증 기관에서 서명되었음을 알게 되며 해당 인증서를 갖게 됩니다. 모든 디지털 인증서에는 앞서 설명한 대로 정보와 서명이 포함됩니다. 브라우저는 해시 값을 얻기 위해 모든 정보를 해시합니다. 그런 다음 발급자의 공개 키, 즉 중간 인증 기관의 공개 키를 사용하여 서명을 해독합니다. 다시 말하지만 서명은 발급자의 공개 키를 통해서만 해독될 수 있다는 점을 기억하세요. 그 후 브라우저는 두 해시 값을 비교하여 동일할 경우 체인의 이 부분을 확인하고 설명된 대로 중간 인증 기관을 직접 신뢰하지 않기 때문에 브라우저는 중간 인증 기관을 확인하는 단계로 넘어갑니다. 운영 체제.   좋습니다. 이제 브라우저는 Google Trust Intermediate Certificate Authority의 인증서를 확인합니다. 이 중간 인증서는 Google Trust Services 루트 인증 기관에서 서명합니다. 이 단계 전에 최종 인증서와 루트 인증서 사이에 많은 중간 인증 기관이 있을 수 있으며 체인의 각 부분에 대해 동일한 확인 프로세스가 수행됩니다.   이 예에서는 하나만 고수하겠습니다. 앞서 설명한 대로 중간 인증 기관의 인증서 서명은 루트 인증 기관의 공개 키로 확인됩니다. 루트 인증 기관에 도달하면 체인이 끝나는 곳입니다. 자체 서명된 루트 인증 기관은 JayPee 운영 체제의 신뢰 저장소에서 사용할 수 있습니다.   그게 다야! 이 확인 후 브라우저에는 브라우저에 있는 것과 같은 멋진 자물쇠 아이콘이 표시됩니다. 이제 정말 유튜브로 소통이 되고 안전하다는 보장이 되네요(호레이)  세 가지 유형의 도메인 인증서  마무리하기 전에 TLS 인증서의 세 가지 주요 유형에 대해 간단히 설명하겠습니다.  1) 단일 도메인 인증서   단일 도메인 인증서는 단일 정규화된 도메인 이름을 보호하도록 설계되었습니다. 이는 인증서가 하나의 특정 도메인에만 유효하며 하위 도메인이나 추가 도메인에는 적용되지 않음을 의미합니다. 예를 들어, "www.youtube.com" 도메인의 경우 단일 도메인 인증서는 해당 도메인만 보호하며 "academy.youtube.com" 또는 "blog.youtube.com"과 같은 다른 변형은 보호하지 않습니다.  사용 사례: 단일 도메인 인증서는 추가 하위 도메인이 필요하지 않은 단일 웹 사이트 또는 웹 애플리케이션이 있는 경우에 이상적입니다. 이는 특정 도메인을 보호하기 위한 가장 간단하고 비용 효율적인 옵션입니다.  2) 와일드카드 인증서   다음으로 단일 인증서를 사용하여 기본 도메인과 모든 하위 도메인에 대해 발급되는 TLS 인증서 유형인 와일드카드 인증서가 있습니다. 와일드카드 문자 별표는 CN(일반 이름) 필드 또는 SAN(주체 대체 이름) 필드에 사용되어 지정된 도메인 아래의 모든 하위 도메인이 포함됨을 나타냅니다. 예를 들어, "   . .youtube.com"에 대한 와일드카드 인증서가 있는 경우 "youtube.com", "academy.youtube.com," blog.youtube.com" 등을 보호합니다    와일드카드 인증서를 사용하면 각 하위 도메인에 대한 개별 인증서를 관리하고 갱신할 필요가 없습니다. 그러나 와일드카드 인증서는 한 수준의 하위 도메인에만 적용된다는 점에 유의해야 합니다. 예를 들어, "*.youtube.com"에 대한 와일드카드 인증서는 "academy.blog.youtube.com"을 포함하지 않습니다. 사용 사례:  3) 다중 도메인(SAN) 인증서   주체 대체 이름 인증서라고도 하는 다중 도메인 인증서를 사용하면 단일 인증서 내에서 관련되지 않은 여러 도메인을 보호할 수 있습니다. 보호할 각 도메인 또는 하위 도메인은 인증서의 SAN(주체 대체 이름) 확장에 나열됩니다.  예를 들어 Google 및 기타 대기업에서는 이러한 다중 도메인 인증서를 사용합니다. 주요 이점 중 하나는 단순화된 인증서 관리입니다. Google은 각각 자체 도메인 또는 하위 도메인이 있는 많은 웹 서비스와 애플리케이션을 운영합니다. 다중 도메인 인증서를 사용하면 여러 도메인 또는 하위 도메인에 대한 인증서 관리를 단일 인증서로 통합할 수 있습니다. 이를 통해 인증서 발급, 갱신 및 모니터링 프로세스가 간소화됩니다.  그리고 그게 다야. 잠시 시간을 내어 애니메이션 강의를 시청해 보세요.   https://youtu.be/OU-e_Qz-v4U?embedable=true  다음 기사에서는 TLS를 사용한 암호화에 대해 설명하겠습니다.   여기에도 게시되었습니다.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Check out my content !

Read My Stories

이 오디오는 이야기의 원래 언어로 제작되었습니다!

TLS 인증서에 대한 단순화된 가이드 📝

About Author

코멘트

태그 걸기

이 기사는 다음에서 발표되었습니다.

Related Stories

바다 항해: 데이터 레이크를 사용하여 프로덕션 등급 RAG 애플리케이션 개발

AI/ML 데이터레이크용 참조 아키텍처 구축을 위한 설계자 가이드

독특한 생태계를 강화하는 비트코인 UTXO 모델

볼츠만 뇌 이론에 대한 간략한 소개

바다 항해: 데이터 레이크를 사용하여 프로덕션 등급 RAG 애플리케이션 개발

AI/ML 데이터레이크용 참조 아키텍처 구축을 위한 설계자 가이드

독특한 생태계를 강화하는 비트코인 UTXO 모델

볼츠만 뇌 이론에 대한 간략한 소개

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps