첫째, 키와 인증서 ( "CA 키"관련)의 구분에 대해 공개 키 인증서 (일반적으로 X.509)에 대해 이야기 할 때 사용되는 세 부분이 있습니다. 공개 키, 개인 키 및 인증서입니다. 공개 키와 개인 키는 쌍을 이룹니다. 개인 키로 서명 및 암호 해독이 가능하며, 공개 키로 확인 (서명) 및 암호화 할 수 있습니다. 공개 키는 배포 용이고 개인 키는 비공개로 유지됩니다.
공개 키 인증서는 공개 키와 다양한 정보 (대부분 개인 키를 제어하는 키 쌍 소유자의 신원에 관한 것)의 조합으로,이 조합은 발행자의 개인 키를 사용하여 서명됩니다. 증명서. X.509 인증서에는 주체 고유 이름과 발급자 고유 이름이 있습니다. 발급자 이름은 인증서를 발급하는 기관의 인증서 주체 이름입니다. 자체 서명 된 인증서는 발급자와 주체가 동일한 특수한 경우입니다. 인증서의 내용에 서명 (즉, 인증서 발급)함으로써 발급자는 해당 내용, 특히 키, ID (주체) 및 다양한 속성 간의 바인딩 (사용 의도 또는 범위를 나타낼 수 있음)을 주장합니다. 증명서).
뿐만 아니라 PKIX 사양은 인증서를 CA 인증서로 사용할 수 있는지, 즉 다른 인증서의 발급자로 사용할 수 있는지 여부를 나타내는 확장 (주어진 인증서의 일부)을 정의합니다.
이를 통해 최종 엔터티 인증서 (사용자 또는 서버에 대해 확인하려는 인증서)와 신뢰하는 CA 인증서 사이에 인증서 체인을 구축합니다. 서비스의 최종 엔터티 인증서와 신뢰할 수있는 CA 인증서 사이에 중간 CA 인증서 (다른 CA 인증서에서 발급)가있을 수 있습니다. 맨 위에 루트 CA (자체 서명 된 CA 인증서)가 꼭 필요한 것은 아니지만 종종 그런 경우입니다 (원하는 경우 직접 중간 CA 인증서를 신뢰하도록 선택할 수 있습니다).
사용 사례의 경우 특정 서비스에 대해 자체 서명 된 인증서를 생성하는 경우 CA 플래그 (기본 제약 확장)가 있는지 여부는 실제로 중요하지 않습니다. 다른 인증서를 발급하려면 CA 인증서가 필요합니다 (자신의 PKI를 구축하려는 경우). 이 서비스에 대해 생성 한 인증서가 CA 인증서 인 경우 아무런 해를 끼치 지 않아야합니다. 더 중요한 것은이 특정 서버에 대해 해당 인증서를 신뢰하도록 클라이언트를 구성 할 수있는 방법입니다 (예를 들어 브라우저는 명시적인 예외를 매우 쉽게 만들 수 있도록해야합니다). 구성 메커니즘이 특정 예외를 사용하지 않고 PKI 모델을 따르는 경우 (하나의 인증서 만 사용하여) 체인을 구축 할 필요가 없기 때문에 인증서를 신뢰 앵커의 일부로 직접 가져올 수 있어야합니다. 당신의 클라이언트, 그것이